[ On Wednesday, May 16, 2001 at 11:35:12 (+0300), Vadim Vygonets wrote: ]
> Subject: Re: [Exim] RFC 2821 and "headers_sender_verify"/"headers_checks_fail"
>
> Quoth Greg A. Woods on Tue, May 15, 2001:
> > Any mail that comes from outside the mail system istelf (i.e. the MTA
> > itself), be it automatically generated or not must have a valid return
> > address. The only thing that should ever generate empty sender
> > addresses is the MTA itself.
>
> Why?
it should be obvious -- the empty return address is intended to stop a
double bounce at the MTA level, not to prevent a user from getting a
bounce... Indeed most MTAs hide the empty return address construct,
which is only an SMTP layer thing, by translating it into something like
"MAILER-DAEMON".
> > The "dueling autoresponder" situation is trivially handled by other
> > simple and long proven techniques (eg. "Precedence:" headers).
>
> Precedence: headers are not mentioned in any RFC, so depending on
> these headers is Not A Good Thing[tm].
Huh? They are, in fact! (though not much good is said of them, but
that's just because of ill-concieved and prejudicial notions the authors
of those comments have....)
The reason though that most RFCs don't say anything about "Precedence"
and such fields is because these are constructs that are explicitly for
the use of e-mail applications -- the RFCs talk mostly about MTA things,
not about apps.
Indeed as you yourself also mention later (in this same thread) there's
no rule against using "home-cooked" headers, and furthermore there's no
rule that requires such field names to have a "X-" prefix. "Precedence"
is, by definition, a "home-cooked" header field! Use it if you need
it!!!!
Finally note that indeed there is lots of precedence for using the
"Precedence" field! The Unix vacation program is just one example of a
very widely used autorepsonder user agent that has used it successfully
for decades to avoid responding to autoresponders.
> Empty envelope sender
> address, OTOH, is well defined in the RFCs and is widely
> recognized as the sign of "don't send me bounces".
You're violating protocol layers!!!! You must not!!!! :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <woods@???>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
