[ On Wednesday, February 27, 2002 at 13:32:44 (-0800), Mark Morley wrote: ]
> Subject: Re: [Exim] Proper autoresponder behavior
>
> What about this scenario: my software allows users to issue challenges
> to unrecognised addresses. Once a challenge is answered, the address is
> 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.
It should reply as a mail user agent if it is not generating a DSN on
behalf of the MTA. No ifs ands or buts. (i.e. yes, 'reply-to' else 'from')
For example it might not work against me if I were to reply using the
headers I normally use when I want return replies to go to my corporate
mailbox.
Want to try?
> The challenge system is subject to the same autoresponder rules, by the
> way, so they can't accidentally challenge a mailing list.
That could be fun! (just kidding! :-)
> > 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?
You really do not want to know.... (and I probably shouldn't say what I
think about it in a public forum!) Suffice it to say that
securityfocus.com (eg. BUGTRAQ, INCIDENTS, etc.) now runs on ezmlm
instead, and that's only after a long, and as I understand it arduous,
battle with L-Soft, who they were apparently even willing to pay for
that feature (which, provided the code hadn't morphed too much since the
last public release I've seen, would have taken about five minutes to
add, and another five minutes to test!).
These days securityfocus.com run occasional administrative sweeps of
their lists (by posting a message to the lists) to discover
mis-configured autoresponders and so far as I know they quickly and
unceremoniously unsubscribe any addresses that respond. A few such
responders still get through to their unmoderated lists unfortunately.
> > > - 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.
Hmmmm.... If you still have an example of such a set of headers I'd be
interested in receiving a copy!
> > You'll want to be careful how you recognise addresses you've already
> > replied to (ignore the comments, etc., parse out multiple addresses,
> > etc.) -- that's a feature coming in the almost-released version of my
> > program....
>
> No worries, I already parse out the actual addresses from any and all
> headers I deal with.
>
> But in the case of multiple addresses - should an autoresponder send to
> ALL of them? Seems to me it might be easy to abuse.
If an autoresponder is acting as a mail user agent then it should reply
in the same way a mail user agent will. No ifs ands or buts. ;-)
Not many people use multiple reply-to addresses, but they may if they
wish (I do for things like GNATS and humans not known directly by GNATS)
> > > - The reply message itself is sent with a "Precedence: junk" header and
> > > a null return-path. If the customer wants it to be replyable they can
> > > add a Reply-to header.
> >
> > 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.
You still don't have to worry about loops -- you've absolutely
guaranteed they cannot do any damage, even if the remote responder is
malicious and attempting to draw your responder into a loop. Your
responder will not send another reply until after the delay timeout.
Nothing they do can avoid that delay. A loop of one message every day
or less is not really anything to worry about.
(My program will not allow an interval of less than a day to be specified)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
