>>
>> >> Yes, I see that. I suppose I'm asking if the forwarder
>> >> (alias-expander) is
>> >> correct to preserve <>, or whether it should supply a
>>new,
>> >> valid, non-null
>> >> reverse-path.
>>
>> David Woodhouse <dwmw2@???> wrote:
>>
>> >$DEITY yes it's correct to leave it as <>. Turning bounces
>>into
>> >non-bounces would be _BAD_.
>>
>> Why?
Peter Bowyer <peeebeee@???> wrote:
>Bounces have null senders to avoid mail loops - if a bounce is
>undeliverable, it is simply dropped. If it has a non-null sender then
>the MTA responsible for the non-delivery of the bounce would have to
>bounce the bounce.... much badness.
Yes, but this doesn't apply in the case in question, on a number of counts:
1. A "null sender" at the start of the chain of aliasing/forwarding is
sufficient to break the loop (unless we're so clueless that we alias to
the original recipient - which would be a misconfiguration in anyone's book
- and probably *should* provoke some kind of terrible error :-) ).
2. Messages which use the null sender but are not going to the address
given in the return-path of a previous message don't seem to comply with
2821 ( 4.5.5 , 6.1 )
3. We shouldn't hope to disclaim 'responsibility' for messages injected
into
the MTS by plonking a null sender on them.
It's worth remembering that a BCP is just that, Best Current Practice;
on the day of publication. In the case of RFC2505 this is 5 years ago.
I don't see that I can be required to accept messages which don't seem to
be conformant with RFC2821 so as to support a convenience enjoyed by
forwarder/aliasing entities. This form of cost-shifting is no longer
tolerable.
Either:
(a) messages with a null sender should not be forwarded to
multiple recipients (if at all).
(b) DSNs (etc) which must be forwarded like this, should have the
null sender replaced with a valid, non-null reverse-path
(perhaps postmaster@???)
And whatever:
I don't believe there is any requirement to accept messages with the null
sender but with recipients which were never in the return-path of a
previous message.
Corollary: There is no requirement to accept multiple recipients for a
message with a null sender.
Regards,
Jon Kyme
