RE: sender, from, returnPath
Joszef, Another idea for AbstractRedirect: Currently the envelope sender and the from address come from a single config parameter. Two examples which show that a separate config parameter would be better: 1. bounce letter: envelope sender is , from address is [EMAIL PROTECTED] 2. checked bounce letter: envelope sender is [EMAIL PROTECTED], from address is [EMAIL PROTECTED] I don't know much about returnPath, but it may be related. It is related, although is a different thing. In RFC 2821: snippet The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent. /snippet In RFC 2822: snippet 3.6.2. Originator fields The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name From and a comma-separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox-list, then the sender field, containing the field name Sender and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field MAY also be included, which contains the field name Reply-To and a comma-separated list of one or more addresses. from= From: mailbox-list CRLF sender = Sender: mailbox CRLF reply-to= Reply-To: address-list CRLF The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the Sender: field SHOULD NOT be used. Otherwise, both fields SHOULD appear. /snippet It seems that adding a way to handle a from different from sender could be useful more for applications (showing an apparent from more complex than a single simple address as supported currently) than for administrator needs (config.xml); we can think at it later on for completeness, but I suggest for the moment to consolidate AbstractRedirect subclasses. Reading the RFC it comes to my mind the fact that, if we implement a from parameter, we would need to choose whether to keep it independent from sender, i.e. leaving up to the coder of the configuration file the responsibility to follow the rules specified in the RFC, or do it automatically (handling defaults): same discussion we had about recipients vs to in Redirect, that made us end up creating a new Resend mailet. In fact, to this respect, I started to deprecate myself Redirect; I'm now considering Resend as the fully controllable redirection mailet, and Redirect as the one with smart defaults: IMO we should keep this distinction consistent (and well documented). (A further enhancement, would be to add a fromName parameter in addition to the fromAddress. The resulting from header is something like John [EMAIL PROTECTED]. But fromName is more difficult, it may require charset information. So I don't say that we should add it immediately, but it may affect the naming of config parameters) I too was thinking at this possibility; but based on the previous point I would use a from parameter to hold any sender information that differs from a single simple address ([EMAIL PROTECTED]), so your point would fall into the from support, that allows also for using multiple senders. But again defaults would be critical. BTW, have you had the time to try my last commit (this morning) to AbstractRedirect subclasses, that includes your patch among other things? Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sender, from, returnPath
Vincenzo, BTW, have you had the time to try my last commit (this morning) to AbstractRedirect subclasses, that includes your patch among other things? I had no chance to try it yet, tomorrow I'll set it up. Currently I am running the yesterday CVS version + my patch. - Original Message - From: Vincenzo Gianferrari Pini [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Monday, June 30, 2003 3:05 PM Subject: RE: sender, from, returnPath Joszef, Another idea for AbstractRedirect: Currently the envelope sender and the from address come from a single config parameter. Two examples which show that a separate config parameter would be better: 1. bounce letter: envelope sender is , from address is [EMAIL PROTECTED] 2. checked bounce letter: envelope sender is [EMAIL PROTECTED], from address is [EMAIL PROTECTED] I don't know much about returnPath, but it may be related. It is related, although is a different thing. In RFC 2821: snippet The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent. /snippet In RFC 2822: snippet 3.6.2. Originator fields The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name From and a comma-separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox-list, then the sender field, containing the field name Sender and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field MAY also be included, which contains the field name Reply-To and a comma-separated list of one or more addresses. from= From: mailbox-list CRLF sender = Sender: mailbox CRLF reply-to= Reply-To: address-list CRLF The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the Sender: field SHOULD NOT be used. Otherwise, both fields SHOULD appear. /snippet It seems that adding a way to handle a from different from sender could be useful more for applications (showing an apparent from more complex than a single simple address as supported currently) than for administrator needs (config.xml); we can think at it later on for completeness, but I suggest for the moment to consolidate AbstractRedirect subclasses. Reading the RFC it comes to my mind the fact that, if we implement a from parameter, we would need to choose whether to keep it independent from sender, i.e. leaving up to the coder of the configuration file the responsibility to follow the rules specified in the RFC, or do it automatically (handling defaults): same discussion we had about recipients vs to in Redirect, that made us end up creating a new Resend mailet. In fact, to this respect, I started to deprecate myself Redirect; I'm now considering Resend as the fully controllable redirection mailet, and Redirect as the one with smart defaults: IMO we should keep this distinction consistent (and well documented). (A further enhancement, would be to add a fromName parameter in addition to the fromAddress. The resulting from header is something like John [EMAIL PROTECTED]. But fromName is more difficult, it may require charset information. So I don't say that we should add it immediately, but it may affect the naming of config parameters) I too was thinking at this possibility; but based on the previous point I would use a from parameter to hold any sender information that differs from a single simple address ([EMAIL PROTECTED]), so your point would fall into the from support, that allows also for using multiple senders. But again defaults would be critical. BTW, have you had the time to try my last commit (this morning) to AbstractRedirect subclasses, that includes your patch among other things? Vincenzo
RE: sender, from, returnPath
These are different things. The confusion is that the term sender is overloaded in common parlance and some APIs, but the RFCs use unambiguous terms. The Return-Path header (aka envelope-from, Mail.set|getSender, mail.smtp.from) comes from what the RFC calls the reverse-path. Consider the headers for the message I am replying to: Return-Path: [EMAIL PROTECTED] Received: from apache.org (daedalus.apache.org [208.185.179.12]) by ziggy.conterra.com (8.12.8/8.12.8) with SMTP id h5UD5RWq046011 for [EMAIL PROTECTED]; Mon, 30 Jun 2003 09:05:27 -0400 (EDT) (envelope-from [EMAIL PROTECTED]) Reply-To: James Developers List [EMAIL PROTECTED] From: Vincenzo Gianferrari Pini [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] These are described in: Return-Path: header, but records MAIL FROM reverse-path, RFC 2821 Reply-To: header, RFC 2822 3.6.2 From: header, RFC 2822 3.6.2 See also: Sender: header, RFC 2822 3.6.2] The confusion about sender often comes from using it to refer to something other than the Sender: header, which is different from the parameter given to MAIL FROM *and* different from the From: header. The Return-Path header records the reverse-path, which you can see in RFC 2821 3.3: MAIL FROM:reverse-path [SP mail-parameters ] CRLF The reverse-path portion of the first or only argument contains the source mailbox (between and brackets), which can be used to report errors (see section 4.2 for a discussion of error reporting). RFC 2821 4.1.1.2 elaborates: MAIL FROM: ( / Reverse-Path) [SP Mail-parameters] CRLF Finally, RFC 2821 4.4 introduces the Return-Path header: The return-path line preserves the information in the reverse- path from the MAIL command. The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. Also, see http://cr.yp.to/proto/verp.txt, which discusses an important use of the reverse-path. This confusion appears to still be present in the new code. Look at setSender, which sets both the From header and the reverse path to the passed value. Those are separate issues. I would suggest that we clean up this area in AbstractRedirect, and document how each element relates to the RFCs. --- Noel -Original Message- From: Vincenzo Gianferrari Pini [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2003 9:06 To: James Developers List Subject: RE: sender, from, returnPath Joszef, Another idea for AbstractRedirect: Currently the envelope sender and the from address come from a single config parameter. Two examples which show that a separate config parameter would be better: 1. bounce letter: envelope sender is , from address is [EMAIL PROTECTED] 2. checked bounce letter: envelope sender is [EMAIL PROTECTED], from address is [EMAIL PROTECTED] I don't know much about returnPath, but it may be related. It is related, although is a different thing. In RFC 2821: snippet The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC 822 syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent. /snippet In RFC 2822: snippet 3.6.2. Originator fields The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name From and a comma-separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox-list, then the sender field, containing the field name Sender and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field MAY also be included, which contains the field name Reply-To and a comma-separated list of one or more addresses. from= From: mailbox-list CRLF sender = Sender: mailbox CRLF reply-to= Reply-To: address-list CRLF The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. If the originator of the message
