Re: [Exim] Administrivia - Christmas is coming, the autorepl…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Exim Users Mailing List
日付:  
To: Exim Users Mailing List
題目: Re: [Exim] Administrivia - Christmas is coming, the autoreplies are getting fat
[ On Saturday, December 15, 2001 at 08:40:47 (-0800), Marc MERLIN wrote: ]
> Subject: Re: [Exim] Administrivia - Christmas is coming, the autoreplies are getting fat
>
> 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.


What the heck are you talking about? Almost all "vacation" messages
probably come from strange mail systems where there's very little
distinction between MTA and MUA. Certainly that's where the majority I
get come from. The majority of the remaining few most certainly come
from Sendmail's vacation program, which is most certainly an MUA itself
even though the original version (and most derivatives) misbehave badly
in that respect.

Remember too that we're talking about giving advice to people who may
not even be running exim!

> 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.


Indeed. The original version of Sendmail's vacation got things wrong,
and you probably see a lot of crap from it. That's why I re-wrote it.
The world need no longer suffer with the broken old version.

Obviously you'd be one of the people who would benefit greatly if most
autoresponders were to reply as per RFC-2822 instead of acting as if
they're part of a layer they are most definitely not at. I really don't
see what you're arguing about or why. Perhaps you're so caught up in
the details (being that you're apparently swamped with so many of them)
that you've forgotten about the bigger picture?

> 3) Of course,  it's also why  programs like  formail, when they  generate an
>    answer, answer to the envelope sender by default


Formail? What's that? Surely you don't mean formmail, that most ugly
perl CGI script too many people use..... obviously not as it doesn't
have an "envelope sender".

> 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.


Ah Marc, you're ignoring some very fundamental issues here. There's no
reason to keep using broken stuff, especially when that broken stuff
causes problems and misbehaves, and doing things the right way actually
avoids those same problems!

Why don't you try to think of a real reason for doing things incorrectly
instead of relying on such lame and obviously flimsy excuses?

> I see your point of separating the SMTP layer from the mail content, but
> again, there is that "ideal world" vs "real world" thing.


Huh? My vacation program is a very real solution to very real
problems. I've only very rarely ever used any vacation program myself,
but my work to improve it was spurred by users I was supporting -- users
who were not getting the right results with the old implementation!

> 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.


Now there you go confusing things again! Where a response is sent and
the mechanisms dangerous mailing loop avoidance are two totally separate
things. My version of vacation includes several loop avoidance
mechanisms that all work together and it literally cannot get into a
dangerous mail loop (at least not without very careful subterfuge on the
part of the other party). Yet it still responds to the correct
addresses as per RFC-2822.

In any case you're starting to sound like a broken record. You need to
learn to do proper and unbiased risk assessment. I already have as many
anti-loop mechanisms in my vacation program as I need, and then some! I
do not need any more, especially when they might interfere with its
proper operation.

Perhaps though you were thinking too quickly and you confused the
desired recipient address with the desired SMTP envelope sender address,
which is the _next_ topic:

> 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.


Hmmmm.... and are you sure they've all obeyed? :-)

Note too that with that syntax you've already limited yourself to a
subset of sendmail-compatable command-line interfaces. Remember again
that this thread started with general advice for users (and perhaps
authors) of 'vacation'-like programs and similar MUA features.

If you look carefully at my version of vacation you'll even find it
supports an undocumented option to allow you to pass the above option to
the MTA in hopes it'll do something sane with it. I don't document it
because normally people want to know when mail they or their agents sent
has bounced.

> 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)


Sendmail, Smail, Zmailer, Postfix, and even Exim, or any other mailer
that supports piping to programs in a ~/.forward file, all normally
allow users to write their own autoresponders.

> 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.


First off note there's a difference between catching a bug in testing
and releasing a buggy autoresponder. I said I triggered such a loop in
testing, more or less on purpose.

Note also that an autoresponder is properly an MUA automaton. It's not
a (normally) feature of an MTA (though obviously some MTAs over-step
their bounds and do MDA and MUA-like things too :-).

> So SMTP callbacks, for me, have contributed to many people becoming RFC
> compliant.


Perhaps you should try practicing at least some of what you preach then
(RFC compliance, that is). I see you can't even get it right on your
own domain it seems:

    Received: from m206-12.dsl.tsoft.com ([198.144.206.12] helo=moremagic.merlins.org)


    $ host -a moremagic.merlins.org
    moremagic.merlins.org   A       204.80.101.251


> > 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)


I did look.

The one mailman installation I can check quickly does not forward
bounces to the MLM command processor, but rather to the mailbox of the
human list owner.

Several installations (including my own) using an ancient brain-dead
LISTSERV clone called 'TULP' also set the envelope sender adress to be
the mailbox of the real human list owner.

Yes I do know of MLM software that'll process bounces in order to
automatically suspend distribution to addresses that frequently bounce,
and such, but they're not the only way mailing lists are managed.

> Or when the autoresponder doesn't parse the precedence header correctly
> (which we of course all know, never happens, right?)


Perhaps you've forgotten that vacation stores the addresses it has sent
replies to and won't reply again to the same address for seven days by
default. Unless the other party to a potential loop works hard to fool
vacation there's no loop possible.

--
                                Greg A. Woods


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