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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
