james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincenzo Gianferrari Pini" <vincenzo.gianferrarip...@praxis.it>
Subject Changes to AbstractRedirect and subclasses
Date Wed, 02 Jul 2003 15:40:57 GMT

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

		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

	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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message