|
osdir.com mailing list archive |
|
Subject: Re: Exim's handling of Bcc lines (was Re: [BUG] mutt - msg#00003List: mail.exim.devel----------------------------------------------------------------------------- The issue of who handles Bcc: header lines has again been raised, and I am seeking opinions as widely as I can. The requirement is straightforward: non-Bcc recipients of a message should not see the addresses of any Bcc recipients, that is, their copies of the message should not contain Bcc: header lines. The dispute is over who achieves this end by removing Bcc: lines when they should not be present. Is it the MUA or the MTA? This is what I know about current behaviour: 1. Exim (which I maintain) removes Bcc: lines if, and only if, it is called with the -t option. In that case, it is constructing an envelope from the header data, and IMHO in doing so it is fulfilling an MUA function. In all other cases it leaves Bcc: lines alone. 2. It has been reported to me that OpenWave InterMail, MS SMTP, MS Exchange, and qmail behave in the same way as Exim for incoming SMTP messages (i.e. they leave Bcc: lines alone). 3. I have also been told that Sendmail, at least in some configurations, always removes any Bcc: lines from any message that it handles. The same is apparently true of Postfix and Lotus Notes 5. 4. Among the MUAs, I think that Pine never sends Bcc: lines, but Mutt by default does, assuming that the MTA will deal with them (Mutt does not use the -t option). The (re-)discussion of this issue arose because the combination of (default configured) Mutt and Exim does not behave the way people expect. Mutt sends Bcc: lines, and Exim lets them through to all recipients. The RFC permits several different behaviours in connection with Bcc recipients. For copies of the message that are sent to Bcc recipients, the Bcc: line may be absent, or contain just the address of the single recipient, or contain the addresses of all the Bcc recipients. For copies sent to non-Bcc recipients, there should be no Bcc: header line. If the MUA handles this, it is possible for it to allow any of the alternative behaviours, as the sender of the message wishes. An MTA has no means of distinguishing what the sender wanted. If it is to handle the Bcc: header at all, the only choice is always to remove it. Thus, an MTA that always removes Bcc: header lines will frustrate the wishes of someone who wants them included in copies to Bcc recipients. (I found one posting on the www that complained of exactly this problem.) Of course, it is possible for MTAs to have configuration options to change their behaviour. (It is easy to configure Exim always to remove Bcc: lines, for instance.) However, only clueful sysadmins who are aware of the issue will investigate such options. Thus, it is important for the default behaviour to be "correct" in the sense that it is what the RFCs and the community experts generally agree on. So .... please vent your opinions and I will try to pull together a summary in due course. I am posting this separately to the three list mentioned above because the Exim lists are subscriber-posting only, and a cross-post might cause problems with replies. Philip -- Philip Hazel University of Cambridge Computing Service, ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714. Thread at a glance:
Previous Message by Date: click to view message previewRe: Exim's handling of Bcc lines (was Re: [BUG] muttEdgar Lovecraft wrote: The two sendmail and one Lotus Notes 5 server either removed or striped the BCC header, while Exim, OpenWave InterMail, MS SMTP, MS Exchange, and qmail (I did not test postfix that I remember) all left the BCC header intact and unmodified. Postfix also removes it. But when I understood the source, that's more by accident, because the cleanup daemon does not know where the mail originates from. Nico Next Message by Date: click to view message previewRe: Exim's handling of Bcc lines (was Re: [BUG] muttSummary of the Bcc discussion: posted to exim-users, exim-dev, & ietf-822 There were a few responses on the exim-users mailing list. There was a longer discussion on the ietf-822 mailing list, to which a number of people who have worked in email protocol development for many years contributed. These included Keith Moore (author of several RFCs), Dave Crocker (author of RFC 822), and Tony Hansen (another RFC author). Some more data points were posted: Smail-3 behaves like Exim; Elm and Mulberry behave like Pine (they do their own Bcc: processing). 1. The substantive point With one possible exception, everybody's opinion was that an MTA has no business messing with Bcc: header lines. Here is a quote from Tony Hansen: "The MUA, however it is constituted, should handle all BCC processing, and the cloning of messages with and without the Bcc: header." This confirms my belief that Exim's default behaviour is the correct one. I hope this particular issue is now laid to rest once and for all. I have saved all the responses just in case it arises again in the future. The possible exception was a post containing this paragraph: The /usr/[s]bin/sendmail interface is a proprietary interface introduced by Sendmail. So all other applications providing this interface should be as close to Sendmail's behaviour as possible, i.e. they should remove Bcc headers. This is the "my country, right or wrong" argument. There was one response that added "... when -t is specified", and that is also my feeling. A call to /usr/sbin/sendmail without -t is not guaranteed to be a submission. Indeed, the post continued: Philosophically, the mailers are still doing the MUA's job by sanitizing the message and (finally) handling it over to the message router (MTA). It just happens that that part of Unix MUAs is usually shipped along with the MTA. and I would argue that without -t, you cannot, and indeed should not, assume that the sending entity is an MUA that is submitting a new message (see further discussion below). 2. Other discussion Some interesting points of clarification came up in the discussion. The functions of mail handling are now seen as split into four distinct parts, as follows: MUA -> MSA -> MTA -> MDA -> MUA (user agent, submission agent, transfer agent, delivery agent). There is nothing to say that each of these functional distinctions has to be implemented by a different program. Thus, it is generally agreed that a program handling a local incoming message using the "-t" command line option is acting partly as an MUA (constructing the envelope) and partly as an MSA (accepting a new message submission). If it goes on to deliver the message over SMTP it is performing an MTA function. If it delivers into a local mailbox it is performing an MDA function. There was some opinion expressed that an MSA might be somewhere that Bcc: header lines could be processed. As this is not sanctioned by RFC 2476 (for MUA->MSA delivery over a network), it would be necessary to define an extension to the SUBMIT protocol so that the MUA could request the MSA to do that processing. In the case of a submission via the command line, the -t option is already available for this purpose. When -t is not used, a general-purpose MTA such as Exim cannot guess that it is being called as an MSA. It has to be configured as such, for example by testing conditions such as "submitted from a host on the local LAN" or "submitted via port 587". If an extension to SUBMIT were defined, another test could be "requested by the SUBMIT protocol". (It is quite easy to implement such tests in Exim and (for example) remove Bcc: lines based on the result, but this has to be an explicit configuration setting; it cannot be defaulted.) Note that "submitted via the command line" (in the absence of -t) is not good enough as a test for an MSA. Such messages may have come from another email regime (e.g. UUCP - some people do still use it) or from a virus scanner or a mailing list exploder. 3. Uses of Bcc As part of the discussion, a list of uses of bcc was enumerated. There are at least four major ones: (a) As an instruction from the end user to the MUA to send a copy of the message to one or more addresses, without telling the To: and Cc: recipients. (b) When present in a copies sent to bcc recipients, to inform them why they received the message (and, if more than one bcc recipient is listed, to inform them about additional bcc addressees). This should alert bcc recipients to take care when replying. (c) To prevent unwanted group replies where the sender wants to send a copy of a message to someone (whether or not the other recipients should know about this), but not subject that person to lots of replies from the other recipients who blindly "reply-to-all". (d) When saved in the sender's sent-mail folder, a Bcc: header acts as a record of who the message was sent to. Is that overloaded or is that overloaded? :-) Regards, Philip -- Philip Hazel University of Cambridge Computing Service, ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714. Previous Message by Thread: click to view message previewRe: Exim's handling of Bcc lines (was Re: [BUG] muttEdgar Lovecraft wrote: The two sendmail and one Lotus Notes 5 server either removed or striped the BCC header, while Exim, OpenWave InterMail, MS SMTP, MS Exchange, and qmail (I did not test postfix that I remember) all left the BCC header intact and unmodified. Postfix also removes it. But when I understood the source, that's more by accident, because the cleanup daemon does not know where the mail originates from. Nico Next Message by Thread: click to view message previewRe: Exim's handling of Bcc lines (was Re: [BUG] muttSummary of the Bcc discussion: posted to exim-users, exim-dev, & ietf-822 There were a few responses on the exim-users mailing list. There was a longer discussion on the ietf-822 mailing list, to which a number of people who have worked in email protocol development for many years contributed. These included Keith Moore (author of several RFCs), Dave Crocker (author of RFC 822), and Tony Hansen (another RFC author). Some more data points were posted: Smail-3 behaves like Exim; Elm and Mulberry behave like Pine (they do their own Bcc: processing). 1. The substantive point With one possible exception, everybody's opinion was that an MTA has no business messing with Bcc: header lines. Here is a quote from Tony Hansen: "The MUA, however it is constituted, should handle all BCC processing, and the cloning of messages with and without the Bcc: header." This confirms my belief that Exim's default behaviour is the correct one. I hope this particular issue is now laid to rest once and for all. I have saved all the responses just in case it arises again in the future. The possible exception was a post containing this paragraph: The /usr/[s]bin/sendmail interface is a proprietary interface introduced by Sendmail. So all other applications providing this interface should be as close to Sendmail's behaviour as possible, i.e. they should remove Bcc headers. This is the "my country, right or wrong" argument. There was one response that added "... when -t is specified", and that is also my feeling. A call to /usr/sbin/sendmail without -t is not guaranteed to be a submission. Indeed, the post continued: Philosophically, the mailers are still doing the MUA's job by sanitizing the message and (finally) handling it over to the message router (MTA). It just happens that that part of Unix MUAs is usually shipped along with the MTA. and I would argue that without -t, you cannot, and indeed should not, assume that the sending entity is an MUA that is submitting a new message (see further discussion below). 2. Other discussion Some interesting points of clarification came up in the discussion. The functions of mail handling are now seen as split into four distinct parts, as follows: MUA -> MSA -> MTA -> MDA -> MUA (user agent, submission agent, transfer agent, delivery agent). There is nothing to say that each of these functional distinctions has to be implemented by a different program. Thus, it is generally agreed that a program handling a local incoming message using the "-t" command line option is acting partly as an MUA (constructing the envelope) and partly as an MSA (accepting a new message submission). If it goes on to deliver the message over SMTP it is performing an MTA function. If it delivers into a local mailbox it is performing an MDA function. There was some opinion expressed that an MSA might be somewhere that Bcc: header lines could be processed. As this is not sanctioned by RFC 2476 (for MUA->MSA delivery over a network), it would be necessary to define an extension to the SUBMIT protocol so that the MUA could request the MSA to do that processing. In the case of a submission via the command line, the -t option is already available for this purpose. When -t is not used, a general-purpose MTA such as Exim cannot guess that it is being called as an MSA. It has to be configured as such, for example by testing conditions such as "submitted from a host on the local LAN" or "submitted via port 587". If an extension to SUBMIT were defined, another test could be "requested by the SUBMIT protocol". (It is quite easy to implement such tests in Exim and (for example) remove Bcc: lines based on the result, but this has to be an explicit configuration setting; it cannot be defaulted.) Note that "submitted via the command line" (in the absence of -t) is not good enough as a test for an MSA. Such messages may have come from another email regime (e.g. UUCP - some people do still use it) or from a virus scanner or a mailing list exploder. 3. Uses of Bcc As part of the discussion, a list of uses of bcc was enumerated. There are at least four major ones: (a) As an instruction from the end user to the MUA to send a copy of the message to one or more addresses, without telling the To: and Cc: recipients. (b) When present in a copies sent to bcc recipients, to inform them why they received the message (and, if more than one bcc recipient is listed, to inform them about additional bcc addressees). This should alert bcc recipients to take care when replying. (c) To prevent unwanted group replies where the sender wants to send a copy of a message to someone (whether or not the other recipients should know about this), but not subject that person to lots of replies from the other recipients who blindly "reply-to-all". (d) When saved in the sender's sent-mail folder, a Bcc: header acts as a record of who the message was sent to. Is that overloaded or is that overloaded? :-) Regards, Philip -- Philip Hazel University of Cambridge Computing Service, ph10@xxxxxxxxxxxxx Cambridge, England. Phone: +44 1223 334714. Loading Comments...
|
|
