Closed Bug 359426 Opened 15 years ago Closed 13 years ago

Attachments: Option to CC without attachments

Categories

(Thunderbird :: Message Compose Window, enhancement, P5)

enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 411275

People

(Reporter: mdudziak, Unassigned)

Details

(Whiteboard: [penelope_wants])

From the Wiki:
The ability to cc: without Attachment (e.g. ccw/oA: ) so one can send the primary recipient an attachment but not saddle the cc recipients with the attachment. I've been requesting this for years and would probably switch to whatever mailer implemented it (except Outlook of course). john coleman

If you think Penelope should have the ability to CC without attachments, vote for this bug.
Definitely a good idea - I get fed up with receiving unwanted attachments from colleagues.
Summary: Request: Option to CC without attachments → Attachments: Option to CC without attachments
Is there any UA that implements this atm?
Status: NEW → ASSIGNED
Not high priority, but I would like an improved editor, perhaps by incorporating code from a public domain text editor
I don't see how this would be technically feasible (at least for any general case, not going into proprietary sending server). Using a normal smtp server it certainly isn't possible, without sending it as different mails of course.
Not a big issue for me. Just send a new msg. 
Well, that would also cause you not to know who received the mail (for real) and seriously mess up replying...
(In reply to comment #6)
> Well, that would also cause you not to know who received the mail (for real)
> and seriously mess up replying...
> 
'
What do you mean by 'that would also cause you not to know who received the mail'?

The replying issue could be solved by treating both messages as if they are the same (like a thread)....


Matt
I was replying to the "just send a new msg". AFAICT it's not technically feasible to send one mail and skip the attachments for some CCs. If one need to send "a new mail" (automatically) to those receivers, obviously the To: etc headers for that message can't be the same, since To: users already got their copy and don't want another one. If you are on the CC you don't know who it was To:. 

So if someone CCd replies to all, it will just go to From and other CC:s. Don't know what you mean by treating both messages the same. Which two messages? Each user gets one.
The trick with this is that Penelope would need to send two messages "behind the scenes", and take advantage of the difference between the "To:", "Cc:", "Bcc:" fields which mailers recognise and the "RCPT TO" SMTP instructions.  Let's say you have a message A with attachment B to be sent "To: main@recipient.org" and "Cc: copy1@other.com, copy2@yetanother.net".  You would address the message To: and Cc: as normal, and use Penelope's clever "CC without attachments" checkbox.  When it came time to send, Penelope would send TWO messages using the following SMTP session:

HELO
MAIL FROM: me@home.info
RCPT TO: main@recipient.org
DATA
To: main@recipient.org
Cc: copy1@other.com, copy2@yetanother.net
Subject: whatever

A
attachment B
.

MAIL FROM: me@home.info
RCPT TO: copy1@other.com
RCPT TO: copy2@yetanother.net
DATA
To: main@recipient.org
Cc: copy1@other.com, copy2@yetanother.net
Subject: Whatever

A
.

QUIT

As a result, each recipient gets only one copy (because only the To: recipient is included in the RCPT TO instruction of the first copy, and only the Cc: recipients in the RCPT TO instructions of the second copy), but each gets the complete To: and Cc: headers, so everyone sees the whole recipient list.  Bear in mind, this is nothing new - this is exactly how Bcc: works (i.e. do not include anything after the DATA instruction with the Bcc list, but send RCPT TO instructions to the SMTP server).

Is there a reason I've missed why this approach wouldn't work?
(In reply to comment #9)
> The trick with this is that Penelope would need to send two messages "behind
> the scenes", and take advantage of the difference between the "To:", "Cc:",
> "Bcc:" fields which mailers recognise and the "RCPT TO" SMTP instructions. 
> Let's say you have a message A with attachment B to be sent "To:
> main@recipient.org" and "Cc: copy1@other.com, copy2@yetanother.net".  You would
> address the message To: and Cc: as normal, and use Penelope's clever "CC
> without attachments" checkbox.  When it came time to send, Penelope would send
> TWO messages using the following SMTP session:
> 
> HELO
> MAIL FROM: me@home.info
> RCPT TO: main@recipient.org
> DATA
> To: main@recipient.org
> Cc: copy1@other.com, copy2@yetanother.net
> Subject: whatever
> 
> A
> attachment B
> .
> 
> MAIL FROM: me@home.info
> RCPT TO: copy1@other.com
> RCPT TO: copy2@yetanother.net
> DATA
> To: main@recipient.org
> Cc: copy1@other.com, copy2@yetanother.net
> Subject: Whatever
> 
> A
> .
> 
> QUIT
> 
> As a result, each recipient gets only one copy (because only the To: recipient
> is included in the RCPT TO instruction of the first copy, and only the Cc:
> recipients in the RCPT TO instructions of the second copy), but each gets the
> complete To: and Cc: headers, so everyone sees the whole recipient list.  Bear
> in mind, this is nothing new - this is exactly how Bcc: works (i.e. do not
> include anything after the DATA instruction with the Bcc list, but send RCPT TO
> instructions to the SMTP server).
> 
> Is there a reason I've missed why this approach wouldn't work?
> 



Exactly!

The contents of the To: and Cc: field (of the message delivered to the SMTP server) are independent of the actual recipients. As you indicated, it is up to the client to tell the SMTP server all the recipients, and ALSO up to the client to 'create' the To: and Cc: headers for a message. The two need not be the same, with a caveat:


I've seen some cases where the SMTP server feels it is its job to override the clients wishes and create the To: field itself. This is a very unusual case, however. Most SMTP servers don't check/care that the To:/Cc: match the RCPT TO addresses

In most cases, Penelope could simply send two messages, filling out identical To: and Cc: headers when delivering the messages to the SMTP server. Behind the scenes, Penelope would use different RCPT TO addresses to handle sending the attachments to one group and not to the other.

Matt
(In reply to comment #9)
> The trick with this is that Penelope would need to send two messages "behind
> the scenes", and take advantage of the difference between the "To:", "Cc:",
> "Bcc:" fields which mailers recognise and the "RCPT TO" SMTP instructions. 
> Let's say you have a message A with attachment B to be sent "To:
> main@recipient.org" and "Cc: copy1@other.com, copy2@yetanother.net".  You would
> address the message To: and Cc: as normal, and use Penelope's clever "CC
> without attachments" checkbox.

BZZZT ! I see a problem here (or am I missing something somewhere... it's happened before).
The tecnique as described forces the CC: line in the user interface to be all one mode.
As I understand the sysem it would require 2 CC: lines to get the full flexibility of having presenting one CC line that gets the message with all the attachments and a second one that would get the message without them. 

If the attachmentless line is blank then only one message is sent behind the scenes, otherwise two messages are sent as described in the rest of comment #9.

Fair comment - the interface I described may not be the best (a "Cc-no-attachments:" field is more flexible than a checkbox affecting all Cc recipients, and by the same logic we could include a "Bcc-no-attachments:" field), but the technical implementation behind-the-scenes is still OK.  Alternatively, you could include everyone you want to receive the attachment in the "To:" field, and everyone you don't want to receive the attachment in the "Cc:" field.

While we're talking user interface, I would suggest that these fields/options be hidden by default - this is an advanced technique that relatively few users will ever want... and which Joe Average is likely to mess up more often than not.
maybe add also a message in subject of body telling to CC/without attachement that they are not receving the attachement due to this option ...

For example at the end of the mail, if the original message has 2 attachement fileA and FileB, the mail to the CC's will have a footer describing the non-send attachement: "file A (xxx bytes) was not sent to CC's but received by To ... file B (yyy bytes) was not sent to CC's but received by To ...)
Depends on: 411275
Priority: -- → P5
Matt,

are you still working on this - or should we set this to NEW again?
I'm asking, because I would also be interested in this functionality...

Would it be possible to have an Add-On for that?
(In reply to comment #14)
> Matt,
> 
> are you still working on this - or should we set this to NEW again?
> I'm asking, because I would also be interested in this functionality...
> 
> Would it be possible to have an Add-On for that?


I am not working on it, no. I guess I am not using Bugzilla the way it is intended to be used. I set bugs to 'Assigned' to keep them from sitting in 'New' forever. I am assigning to either the developer who I think will ultimately do the work, or to myself as an indicator that I need to look into it again in the future and assign it.

Feel free to move it back to 'New' if you think that will help to get others to fix it.

Matt
Assigning to Thunderbird as this is not unique to Penelope.
Assignee: mozilla-bugs → nobody
Status: ASSIGNED → NEW
Keywords: 4xp
Product: Penelope → Thunderbird
QA Contact: general → general
Whiteboard: [penelope_wants]
Version: 0.1 → Trunk
Component: General → Message Compose Window
QA Contact: general → message-compose
(In reply to comment #16)
> Assigning to Thunderbird as this is not unique to Penelope.

but then it becomes a DUP of 411275
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 411275
No longer depends on: 411275
You need to log in before you can comment on or make changes to this bug.