Re: [Exim] RFC 2821 and "headers_sender_verify"/"headers_che…

Top Page
Delete this message
Reply to this message
Author: Exim Users Mailing List
Date:  
To: Exim Users Mailing List
Subject: Re: [Exim] RFC 2821 and "headers_sender_verify"/"headers_checks_
[ On Thursday, May 17, 2001 at 15:43:54 (+0300), Vadim Vygonets wrote: ]
> Subject: Re: [Exim] RFC 2821 and "headers_sender_verify"/"headers_checks_
>
> Quoth Greg A. Woods on Wed, May 16, 2001:
> > First off remember that e-mail autoresponders are MUAs! They act only
> > on behalf of a user (even if it's a virtual user). They must act only
> > in the way any user agent may! For example "vacation" programs should
> > follow RFC-822 rules for choosing the reply address!
>
> But maybe they should also check the envelope sender address to
> avoid replying to MAILER-DAEMON? "if not errormessage"?


Maybe. It shouldn't really be necessary though. Any sane MTA I know
puts "MAILER-DAEMON" or "Postmaster" or whatever in the RFC-x822 "From"
field too so it's just as easy.

Besides strictly speaking there's no portable way to find out what the
SMTP envelope contained once the message has been delivered.

> I know what you're going to say: /usr/ucb/vacation doesn't reply
> to messages coming from *-REQUEST, Postmaster, UUCP, MAILER or
> MAILER-DAEMON. I'm sorry, but this is a bogus algorithm.


All E-mail autoresponders are bogus algorithms! But users want them so
we write them and try to make them reasonably safe using whatever
techniques work, no matter if you think they are bogus or not! ;-)

> I
> believe there exist mailers that send bounce messages from some
> other address.


Show me! ;-)

> Moreover, many mailing list managers nowadays
> send mail not from *-REQUEST, but from *-bounces or things like
> bsdi-users-owner-vadik-bsdi=cs.huji.ac.il@??? (but
> this is solved with a wholly different statement, "if personal").


Yeah, but those are *designed* to get autoresponder replies!

(Eg. on BUGTRAQ they want *broken* autoresponder replies so that they
can unsubscribe the luser with the broken autoresponder!)

> > Autoresponders rarely set their reply address to be themselves,
>
> What does /usr/ucb/vacation set the reply address to?


I don't have one of those programs, but my /usr/bin/vacation simply uses
whatever you put in the message it sends out, just as the current
version in the sendmail package does. I'm fairly certain the ancient
/usr/ucb/vacation worked the same way though. RTFM.

> But other (non-BSD) vacation programs or other types of
> autoresponders may not respect the non-standard Precedence:
> header.


That's their problem, not ours! ;-)

> So if one of the vacationaires uses UNIX and the other,
> say, Windows, there *will* be a loop (by your algorithm).
> Remember, you usually don't get any traces of the original
> message back in the autoreplied message.


Nope. You forget the programmed delay between responses to the same
address. By default you'd only get one bounce per week.

> > Most e-mail autoresponder user agents also use several common de facto
> > standard mechanisms to further avoid interacting with dissimilar agents,
>
> Several *different* de-facto standard mechanisms.


Yup, that's basically what "de facto" boils down to! ;-)

> When you think whether or not to set the sender address to <>,
> you need to ask yourself: do I want to get bounces if this
> message is not delivered?


You cannot set the SMTP Envelope sender address to "<>" without directly
using SMTP. Neither the sendmail version, nor my version, of vacation
can do that. Even if you did you'd be violating the protocol layering
in the worst way.

> And how will I prevent mail loops if
> the responder on the other side just responds without leaving any
> sign that the message is an automatic reply, or any traces from
> the original message?


What do you care if it's one bounce per week? If the guy on the other
side is stupid enough to run a broken autoresponder then he deserves to
get a weekly reminder of his stupidity! You should be able to delete
his noise after you get back to your e-mail -- just as easily as he can,
delete yours, I suppose! ;-)

-- 
                            Greg A. Woods


+1 416 218-0098      VE3TCP      <gwoods@???>     <woods@???>
Planix, Inc. <woods@???>;   Secrets of the Weird <woods@???>