Noel,
After going through the RFC 2821, now I agree with you:
"Unless I'm missing something, reverse-path and return path should be the same value,
but the "important one" is the reverse-path, because that is what the RFC tells MTAs
to use. The Return-Path header is more useful for the MUA."
and so IMO I should adjust AbstractRedirect & subclasses in the following way, also to
take in account the previous ambiguity of the term sender (at least from the
administrator point of view):
1. Change the getReturnPath/setReturnPath/<returnPath> group to
getReversePath/setReversePath/<reversePath> everywhere in the AbstractRedirect
hierarchy.
2. Wherever a change to the reverse-path is requested, have the Return-Path header
kept in sync, including reverse-path = null -> Return-Path = "<>".
3. Add a new getFrom/setFrom/<from> group explicitely handling the From header.
4. Add a new "magic" SpecialAddress.DELETE.
5. The Resend mailet will be the "swiss knife" (as Serge calls it) mailet with which
the administrator can control all redirection options.
6. The Redirect mailet will have the role of a "smart" equivalent of Resend, smart in
the sense that it handles defaults intelligently. This is important because it can be
boring and cumbersome to code Resend specifying all the needed options, while instead
only a few are really needed in each specific situation. All this can be done keeping
full backward compatibility.
The major "smart" defaulting behaviours are:
6.1 When <recipients> is specified and no <to> is specified, the To header is
built from <recipients>, and vice versa for compatibility: this is already implemented.
6.2 When <sender> is specified and not <from>, the From header is built from
<sender>, and the Sender header is deleted, as per RFC 2822. If <from> is specified
and not <to>, the From header is built from <from>, and the Sender header is deleted,
as per RFC 2822 section 3.6.2. If both are specified, both headers are built, as the
specification says:
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.
It's up to the administrator to code things correctly then.
6.3 The same "smart" defaulting will exist from the new <reversePath>
parameter and the <sender> and <from> above.
6.4 Whenever a parameter value is "unaltered" (as for example
<reversePath>unaltered</reversePath>), it will behave like Resend.
6.5 It will be possible to code both <from> and <to> as a "mailbox-list" (see
RFC 2822 section 3.4). As a "mailbox-list can contain a "display-name", there could be
internationalization problems, that we could ignore for the moment. Joszef can give a
help.
6.6 The logic of the "smart" defaulting will be done inside the getX() methods
and not in the getX(Mail) methods, so such behaviour is only "static".
7. The AbstractNotify subfamily will have the same "defaulting" facilities, with a
global default to postmaster as now. Those methods are just a specialization of the
recipient logic, plus the null reverse-path logic in the case of Bounce.
7.1 Bounce will bounce back to the reverse-path of the original message
(unless it is null).
____________________
Regarding the reverse-path vs Return-Path issue, shouldn't we change the logic in
SMTPHandler.processMailHeaders having Return-Path built from reverse-path
*unconditionally* instead of only when null? It has no effect in our new logic, but it
would be more consistent.
Finally, a change of Mail.get/setSender to Mail.get/setReversePath can be done
independently, later on.
I hope that all this makes sense.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
