> Should I change it to something like the following: use the sender,
> if null use the return path, if null leave it null (or throw an
> exception)?
RFC 2821 says:
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line). However,
if this address is null ("<>"), the receiver-SMTP MUST NOT send a
notification.
For a Bounce, it seems to me that the null (<>) means don't send a
notification message.
> I'm fixing a bug in AbstractRedirect that was causing a NPE trying
> to build a new TO using the sender, that it turned out null in some
> cases (spam or virus). I'm going to do the following in such case:
> use the sender, if null use the return path, if null set it to <>.
Bounce is clearly defined by RFC 2821. My thought is that NotifySender
should be the same as Bounce, but with a non-null return-path. That is what
we agreed upon previously (I checked the archives), is closest to the
current use, and consistent with the somewhat ambiguous use of "Sender."
Another mailet (or magic address) could follow the reply policy from RFC
2822:
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the mailbox(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
For reasons suggested in RFC 2822, the "Sender:" header would not be used to
reply.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
