On Sat, Dec 15, 2001 at 01:53:36AM -0500, Greg A. Woods wrote:
> the MTA to use, not any MUA. The SMTP envelope sender address is only
> where an SMTP-based MTA "MUST" send delivery status notifications
> (i.e. bounces, etc.). It is not for use by the MUA. There may not even
1) You seem to not take into account that almost all vacation messages come
from an MTA.
2) Regardless of what you say, and what "should be" according to you and
your interpretation of the RFCs, which may be correct in some points, in
the "real world" [tm], I know from experience (16,000+ mailing lists,
100,000+ users) that autoresponders go to the envelope sender in 90% of
the cases.
3) Of course, it's also why programs like formail, when they generate an
answer, answer to the envelope sender by default
Feel free to see that all these programs are broken, and that 90% of the
people are broken, but since I happen to live in the real world, I try to
play along with others, and conventions that are mostly agreed upon by
everyone else.
This is of course, why Miguel, who is also a seasoned list manager, and
knows a thing or two about MTAs, was making the same suggestion, to have
unattended autoresponders answer to the envelope from.
> > autoresponders are talking to one another in unexpected situations like a
> > stupid autoresponder that would eat an X-Loop header I insert and not insert
> > any precedence headers.
>
> I think you've somewhat confused the protocol levels here.....
I see your point of separating the SMTP layer from the mail content, but
again, there is that "ideal world" vs "real world" thing. It has been shown
over and over again by broken autoresponders, that one protection against
loops is not enough. You want as many as you possible can.
> > That's why any good autoresponder also sets the envelope to null
>
> A program acting on behalf of the user, i.e. as a user agent, may not
> always be permitted to set an empty sender address. Indeed not all mail
All the MTA I've dealt with on UNIX (granted, that's a subset of what's out
there), allowed you to set -f"<>" or equivalent.
In addition to that, the MTAs that would allow you to set the envelope
from, for the most part, probably do not allow you to write your own
autoresponders either (you have to write an autoresponder message, and the
MTA takes care of sending the "foo isn't there" message for you)
> In any case this is irrelevant for any properly designed and configured
> autoresponder since they cannot get into dangerous mail loops in the
> first place. (one pair of messages cycling per day does not constitute
> a "dangerous mail loop"! ;-)
You were saying in a previous message that you had never seen a mail loop
between autoresponders, outside of one you made while writing one.
1) If you, who has a clue about mail, can write a buggy autoresponder, think
about all the other people without a clue who add this feature in some
MTA right before it ships.
2) yes, I've seen dangerous mail loops, more than once, and where both mail
servers were so beefy that hundreds, sometimes thousands of message went
back and forth, in minutes.
The entire domain the loop came from ended up being entirely blocked
until all traces of the autoresponder had been removed and/or the faulty
MTA replaced/upgraded (which typically hasn't happened, but I don't have
to hear from them anymore now that they are blocked)
> Besides only a very few very lame idiots are implementing SMTP callbacks
> unilaterally to verify the SMTP envelope sender address. That's a gross
Eh, you can have all the opinions you want, good for you.
In the meantime, since I have to deal with the real world [tm], I don't want
to have to see mail that I can't bounce or reply to anymore, sorry.
Incidently, it also catches a lot of spam, but that's merely a byproduct
> violation of good sense, and as you of all people should know by now it
> leads to increased amounts of interoperability problems, lost e-mail,
> and all kinds of other gross RFC violations. I dislike failed bounces
Actually, I've seen SMTP callback get lots of people fix their envelope
froms to correct ones, fix their mail masquerading (or lack thereof), and
make sure that they actually have a postmaster account.
So SMTP callbacks, for me, have contributed to many people becoming RFC
compliant.
> > Regardless of what you say, many people have used the envelope sender and
> > pointed it elsewhere with the understanding that all bounces and automated
> > replies will go there.
>
> Who cares what people have set their SMTP envelope sender address to!?!?!?
Sigh...
> Once the message is being delivered to a Mail USER Agent it is no longer
> an SMTP message. The SMTP envelope sender address no longer has any
> importance and is never to be used for reply by a conforming Mail USER
> Agent. If you send me a message and expect me to reply to it then it
Again, you make wide large claims.
> makes no difference whether I reply to it with my interactive MUA, or I
> reply to it with my automated MUA called 'vacation', you'd better have
> set the proper RFC-2822 reply headers so that I've got a good enough
> chance of sending my reply to you. When you send me a message you MUST
I fully agree that everyone should also set the relevant RFC2822 headers.
> NOT care whether my MUA is interactive or automated if you have any hope
> of expecting any reply.
My message doesn't care, but I care, because if you reply I know that there
is someone there to stop really stupid things from happening (like a mail
loop). If it's a vacation program, I assume by default that it will do
something stupid and generate a loop.
I'll do everything I can on my side to prevent this from happening,
including setting the envelope sender to null.
I expect an autoresponder to not answer a message if the envelope is set to
null. You can't do that if you don't get the envelope from. Sure the
precedence header should be set too, but how many autoresponders ignore it?
> Sorry, but you're quite wrong about that. First off the MLM normally
> won't receive mail sent to the SMTP envelope address used with mailing
> lists -- the list owner will (unless perhaps its misconfigured). You
Well, look again.
MLMs like ezmlm and mailman process bounces themselves, and only pass it on
to the owner if they can't do anything with them (at least for mailman,
ezmlm may be fully automated)
> definitely do not ever want bounces going to the -request mailbox!!!
Nope, they go to -admin, which is what's set as the envelope for mailman.
> Now where this could get a bit messy is when a MLM sets the reply-to
> header, but doesn't add a proper "Precedence: list" header (only Lsoft's
> LISTSERV is so lame as far as I know), and when the 'vacation' user
Or when the autoresponder doesn't parse the precedence header correctly
(which we of course all know, never happens, right?)
> reply-to address. Normally the adding of a reply-to by the MLM (where
> one doesn't already exist) is a "good thing", but that's really only
Well, you prove again that there are very very few things we agree on.
> because most people who post to mailing lists forget to do so themselves
User problem, not for the list to try to fix.
> You can agree with whomever you want, but you and everyone you are
> agreeing with are clearly wrong w.r.t. the RFCs. Re-read RFC-2822, and
> read it again. Try to understand that RFC-2822 is not for SMTP alone.
Again, for some things, you may be right in theory (certainly not on
reply-to munging though), but you fail to take the real world into account.
There no need to continue wasting your time or mine, you have kept the same
position on different topics, and you seem to want to ignore real world
cases, "hiding" behind what RFCs say should happen (even when the RFCs
themselves can't cover all the real world cases, and the people who read
them are supposed to use their brains and do the best they can with what
they have to work with)
> There may not even be an equivalent of an envelope sender address!
> Remember that 'vacation' programs and the like are Mail USER Agents!
BTW, most vacation programs do the right thing and answer to the envelope
sender. I'm sure
Marc
--
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page:
http://marc.merlins.org/ | Finger marc_f@??? for PGP key
