On Wed, Feb 27, 2002 at 01:32:44PM -0800, Mark Morley wrote:
> > Replying to the return-path is wrong for a "mail user agent", of which
> > an auto-responder is almost always acting as (eg. when the auto-
> > responder is used to handle "out-of-the-office" types of messages,
> > "info" mailbox replies, and so on).
>
> Hmm... most of the discussions I've come across on the 'net seem to favor
> the return-path only. But I understand your points. Does anyone else here
> have a different view of this?
Sure, at least a couple of us do, but if we say so, Greg will reply us into
oblivion (not that I overly care anymore due to his messages being
/dev/nulled on my side)
The short version is that if you follow protocol layers, a user agent
autoresponder should not have to deal with SMTP headers.
Of course, it gets more shady when you put the autoresponder inside the MTA
where you can then argue that it should deal with SMTP addresses.
From what I've seen, and some unwritten conscensus on the internet that many
people seem to abide with, automated messages are sent with an envelope from
set to NULL, and are sent to the envelope from of the incoming message if
that one isn't null either.
This provides loop protection on top of the Precedence header.
Of course, all autoresponders can't do that because
1) you might not have access to the envelope from (rare on unix)
2) you might not be able to set the envelope from to NULL
(exim does let me do exim -f '<>' as un unpriviledged user however)
> remembered and isn't challenged again. Works great to eliminate spam.
> Which address should it challenge and remember? Reply-to? From? Currently
> it deals with Return-path and it works well.
mmhh, I'd recommend to use the header sender here because a user (let's say
me) can Email you with 10 different envelope senders depending on the
machine the mail came from.
I remember this from my mailman days when it was checking froms for a
members only list, and it was checking envelopes instead of header froms.
> > You might want to add "listserv@*", "mailer@*", "*-relay@*", and
> > "*-outgoing@* too.... "listserv@*" is the most critical of course
> > (because of L-Soft's idiotic refusal to add a "precedence: list" header).
>
> Thanks, I've added those now. Why on earth would they not want to add
> that header?
Why is there so much software out there that breaks basic RFCs, like
refusing NULL envelope froms?
It's an imperfect world I'm afraid. That's why I've taken the stance to
follow the RFCs wherever it made sense, and get a bit creative sometimes
when that seemed to make sense.
Of course, you have to be very careful when doing so and make sure you know
what you're doing :-)
> > > - It won't respond to any message that contains an "x-mailing-list"
> > > header or any "list-*" headers.
> >
> > Is that really necessary? It shouldn't be....
>
> Can't really hurt I figure. I've seen some mailing lists that have these
> but are missing a Precedence: header. I suspect they were home-grown things.
It never hurts to check more, double check, triple check, especially when
you try to avoid loops (one of the reasons why to avoid loops, people also
set the env from to NULL in addition to setting Precedence)
> > You really don't have to send it with a null return-path. It might be a
> > nice option to have in a full-featured auto-responder (mine has it), but
> > it should not be the default.
>
> The idea was to avoid mail loops. I suppose it's not an issue unless the
> recipient of the autorespodner has a broken autoresponder himself. But
> making it a configurable option sounds like a good idea.
Quite frankly, outside of following protocol boundaries by the letter, there
are few pratical reasons to not set the env from to null (actually, none
that I can see). Worst thing, the MTA will not let you and you didn't lose
anything by trying.
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
