Re: [Exim] conditionally rejecting <> sender

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Philip Hazel
Data:  
Para: Exim Users Mailing List
CC: Nico Erfurth
Asunto: 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.

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). Indeed, here is a quote from section 4.1.1.2, which
discusses the MAIL command:

The reverse-path consists of the sender mailbox. Historically, that
mailbox might optionally have been preceded by a list of hosts, but
that behavior is now deprecated (see appendix C). In some types of
reporting messages for which a reply is likely to cause a mail loop
(for example, mail delivery and nondelivery notifications), the
reverse-path may be null (see section 3.7).

> Empty sender addresses have a very specific and singular purpose in the
> SMTP protoco and they should not ever be abused in this way.


There are at least two purposes mentioned as examples in that quote,
which doesn't agree with your "singular purpose". And I think you could
argue that autoreplies are "reporting messages". A message such as
"Message was delivered into mailbox, but owner is on vacation" would
seem to fit well into the category of "delivery notification", which is
explicitly mentioned in that quote.

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.

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.