[ On Thursday, April 10, 2003 at 09:52:54 (+0100), Philip Hazel wrote: ]
> Subject: Re: [Exim] conditionally rejecting <> sender
>
> On Wed, 9 Apr 2003, Greg A. Woods wrote:
> >
> > Because an author of such a filter really doesn't have any business
> > using empty sender addresses. Exim _SHOULD_ make this impossible and
> > it's sad that it doesn't.
>
> Not only does it not make it impossible, it enforces it. I don't want
> two robots slugging it out with "I'm on vacation" messages.
What I'm talking about here is that Exim should make it impossible for
the filter author to use a null reverse path in the first place.
> I see nothing in RFC 2821 that says the use of "<>" must be restricted
> to bounce messages only (I quote below what I think is the strongest
> statement therein).
Well, depending on how you define "bounce messages", I most certainly do
think it says exactly that. I would say a "bounce message" is _only_
any kind of message sent to the reverse path address that was given in
the envelope for some other message. Since the reverse path address is
to be used strictly for message disposition and delivery notifications,
a "bounce message" must also be one regarding the transport and delivery
of some other message.
I.e. messages with a null reverse path SHOULD be those regarding the
transport or delivery of another message and which are sent to the
address given in the reverse path of some other message. Messages that
are _not_ sent to the (one) reverse path address given for some other
message, _and_ which are _not_ about the disposition or delivery of that
other message, _SHOULD_NOT_ be sent with a null reverse path. Every
other message _SHOULD_ use a valid non-null reverse path.
See section 4.5.5 regarding the purpose and use of the null reverse
path, and w.r.t. "vacation" messages please pay particularly close
attention to the last paragraph. Vacation programs/filters are
automated e-mail processors, i.e. they are mail user agents acting on
behalf of a user, and they are most definitely not delivery status
notifiers or message disposition notifiers, etc., especially since each
of these latter things really do have very specific definitions in the
RFCs and none of those definitions include "vacation" messages which are
only about the behaviour of the supposed human reader, not about the
behaviour of the mail transport and local delivery software.
> You may argue that by "delivery notification" the RFC is talking
> about the specific types of message defined by other RFCs, and is not
> referring to anything else. Lest I be accused of selective quoting, I
> will give this other extract:
>
> All other types of messages (i.e., any message which is not required
> by a standards-track RFC to have a null reverse-path) SHOULD be
> sent with with a valid, non-null reverse-path.
>
> Firstly, that is only a SHOULD, and secondly, if a new type of standard
> "delivery notification" were invented, surely it would specify a null
> reverse path? Therefore, if some non-standard similar activity is
> undertaken, I think it should do the same.
Yes, of course it is a "SHOULD". This is an RFC created by a committee
which couldn't even tie their own shoelaces for many years on end! :-)
Remember that "SHOULD" is essentially equivalent to "MUST" from the
point of view of a software implementer. One cannot violate a "SHOULD"
without an extremely important reason for doing so. A protocol
implementation that violates a "SHOULD" (i.e. forces all its users to
violate that rule) is effectively making a claim that the protocol
specification is flawed. (I know this is so because I've done it! ;-)
As for new types of delivery notifications, well there is only ever one
reverse path address and so it is literally impossible to send any kind
of delivery notification, no matter how you classify such things, to any
more than one recipient address!
See also the tail end of section 3.7 about relaying where again the idea
that only messages sent to the reverse-path address given for some other
message need to have a null reverse path themselves.
The "singular purpose" I was referring to was the fact that the sole
reason for using a null reverse path is to prevent loops that might
occur when the MTA generates a notification of some sort and sends it
back to the reverse path address that was given in some other envelope.
Anyone who thinks using the null reverse path will guarantee no loops
when sending messages to addresses found in RFC [2]822 headers is
seriously and mistakenly confusing the protocol levels. RFCs [2]821 and
RFCs [2]822 discuss entirely separate and strictly un-related protocols
(at least they are un-related from a protocol definition point of view).
Automated e-mail processors and other mail user agents generally do not
have access to the original SMTP envelope addresses and there's no such
concept of a "null reply address" in RFC 2822. Other mechanisms
entirely [*] are used by decently behaved automated e-mail processors to
prevent loops between each other, and those other mechanism _must_
always be used regardless of whether or not such processors also have
access to the original SMTP envelope.
[*] The one most commonly used mechanism is response rate limiting, and
this mechanism is generally sufficient to use alone. I.e. vacation
programs don't send a response to the same address any more often than
once every so many days or weeks. This doesn't stop a loop of course --
but it makes the loop period so long that it cannot be damaging in any
way and mere mortals might not even notice it's happening.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
