I wrote:
> What I would like to see clarified is that it is not appropriate to use
> a null reverse-path merely because the sender does not want to be
> bothered with non-delivery notifications.
Philip Hazel <[EMAIL PROTECTED]> replied:
> That would leave no simple mechanism for a sender to achieve that
> effect.
I am not convinced that there are any situations where this effect is
really appropriate except when sending some kind of notification to the
return path of a previously-received message.
However _if_ you really want to send a message so that you won't see any
notifications about it (and I'm assuming that you have a legitimate
reason for this, i.e. you're not a spammer), you can always set your
envelope sender to a 'nobody' alias at the originating host which
forwards to /dev/null or the equivalent.
> (DSN is not simple, nor widely deployed.) The increasing use of
> autoresponders means that is it important to have such a mechanism, as
> otherwise the chance of autoresponder<=>autoresponder loops is
> increased.
If you're talking about an autoresponder which sends its response to the
envelope sender of the incoming message, the text which I'm proposing
does not forbid the autoresponder to use a null return path. (The
"SHOULD NOT" in the proposed addition to section 4.1.1.2 does not apply
because in this case the intention is to prevent loops and not just that
someone does not want to be bothered. The "SHOULD NOT" in the proposed
new section 6.4 does not apply either.
If you're talking about an autoresponder which sends its response to the
header From: address of the incoming message, then the appropriate
action will _not_ be to use a null reverse path, but to use a non-null
reverse-path that is a valid e-mail address at the host with the
autoresponder, but which is guaranteed not to lead to such an
autoresponder, e.g. something like <[EMAIL PROTECTED]>.
In my opinion the appropriate way to handle mail to this address would
be a little perl script which checks incoming messages with null return
path if there is a large number of such notifications from the same host
(in which case postmaster would be alerted about the potential problem)
and discards notifications otherwise, while messages with non-null
return path would be forwarded to a human who is responsible for the
autoresponder. However if you do not agree with this opinion and you
prefer to handle all <[EMAIL PROTECTED]> mail manually,
or discard it all unread, there is nothing in my proposed text which
would forbid either of those two options.
Note that from the perspective of debugging obscure problems, an
e-mail robot which sends messages with a reverse path like
<[EMAIL PROTECTED]> is better than one which uses a null
reverse path not only because the <[EMAIL PROTECTED]> reverse
path helps avoiding unneccessary double bounces, but also because
the reverse path helps with distinguishing between maillog entries
from bounces and those from messages sent by an e-mail robot. The only
reason why I have not included this point in my proposed text is that
I don't think that a <[EMAIL PROTECTED]> reverse path (which
forwards to /dev/null and nowhere else) will ever be really
appropriate.
Loops between various e-mail rebots (not only autoresponders) should be
fought with methods that do not make it impossible for the e-mail robot
to look at bounces of messages which they send.
It is true that the methods which are currently employed for preventing
loops between various e-mail rebots are somewhat ad-hoc and unsatisfying.
They could be greatly improved by a new, standardized Robots: header
which would specify what kind of action an e-mail robot should take
if the message is processed by one. The possible actions could be
"discard", "bounce" or "process", with a default of "process" if the
header is not there.
> > : For messages where the recipient address has been obtained from any
> > : source other than the reverse-path of a previous message, a null
> > : reverse path SHOULD NOT be used, so that the mail administrator of the
> > : destination host will not be needlessly alerted if the message is
> > : undeliverable.
>
> In many cases it is the mail administrator of the sending host who would
> be alerted,
True. I will need to revise my proposed text a little. If there is a
rough consensus in the DRUMS working group to include something similar
in meaning to the "SHOULD NOT" which I'm proposing, I will be willing to
work a little more on the explanatory text, at least to correct the
minor error which you pointed out. (I currently feel that trying to
discuss e-mail robots, or spam, automated bounce-handling in any detail
would be outside of the intended scope of the document, though.)
> but it does depend on the way the destination's MTA is
> configured.
Yes.
> When the volume of mail on any system gets at all
> substantial, mail administrators tend simply to ignore undeliverable
> messages whose senders are "<>". 99% of those I see are the result of
> spam.
However if you take precautions not to expose most of the email
addresses of your network on the Web or Usenet or in unprotected mailing
list archives (i.e. those places where spammers go to harvest e-mail
adresses) and you make sure that the addresses which you need to expose
will never become invalid, you will not have this problem. (Of course
another, and probably much more important, benefit of such a policy is
that you can then install a spam filter on those addresses which you
expose).
-- NB.
