"Linus Upson" <[EMAIL PROTECTED]> writes:
> Does TMDA support automatically responding to challenges sent by
> other TMDA users?
No. It's been discussed, but in lieu of a standard for this type of
thing, I didn't want to waste time trying to implement it. In
practice, TMDA users don't tend to see each others confirmation
requests when they use 'dated' addresses in their outgoing messages.
> We'd like to support automatic processing of other
> challenge/response systems and we're interested in supporting TMDA.
I think the right approach is to pursue an RFC or IETF draft for this,
and then encourage the other C/R systems to adopt it. I'd adopt it.
I'll even help you design/write it if you decide to do this.
Actually, I was contacted a few months ago by a journalist who was
trying to do something similar with some of the commercial
implementors. I can pass along his name offline if you'd like to
compare notes.
He gave the impression that they wouldn't need TMDA's input because it
isn't a commercial implementation, so I didn't go any further. This
struck me as ironic, since TMDA probably has the most users of any
single C/R system, and has been around the longest. Oh well.
> if (Return-Path == NULL &&
> Auto-Submitted == "auto-replied" &&
> X-Delivery-Agent begins with "TMDA" &&
> IsReplyToMessageWeSent
> ) {
> // This is a TMDA challenge to a message we
> // sent. Automatically respond for the user.
> SendResponseTo(Reply-To);
> }
Your algorithm will get you only part of the way there.
First, Return-Path is null by default, by many (most?) of us set it to
a bitbucket-type address so that our postmasters aren't bothered by
double-bounces. There is no telling what this might be. My
return-path is '[EMAIL PROTECTED]' for example.
Next, TMDA allows the user to purge selected headers, and some purge
X-Delivery-Agent.
Lastly, you can't count on a Reply-To header being there. Many users
remove Reply-To to thwart auto-responders who use that address. The
result is that the confirmation address may be in Reply-To, From, in
the message body, in an embedded URL, or all of the above. :-)
This illustrates perfectly I think why a published standard is the
only reliable way to address the issue of auto-confirmation.
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
