[Asrg] Re: 0. General - anti-harvesting (was Inquiry about CallerID Verification)

[Scott A Crosby <scrosby@cs.rice.edu>]

On Sun, 30 Nov 2003 10:11:39 -0800, Matthew Elvey <matthew@elvey.com> writes:

> Perhaps a better alternative to deprecating <> would be saying that
> MTAs SHOULD bitbucket DSNs about email they know (thanks to LMTP
> and/or Received/MessageID headers) weren't sent from authorized
> IPs/systems.  Good/workable idea?

Probably, if the burden of proof is low and relatively easy.

> True.  By deprecated, I mean a spec that says that MTAs SHOULD not
> (not MUST not) use  <>.  Let's see if there is another solution for
> everything legit that it's currently useful for.  We don't want <> to
> be a way around LMTP, right?   For any failure DSN, I think the
> systems that send them can and should be modified so that all the
> failure status codes of rfc 1893 can be provided during SMTP.  Any
> intermediate system (offline UUCP excepted) that does so would need to
> be redesigned, as you point out below, if they wanted to avoid using
> <>.    For any success DSNs, perhaps they shouldn't be sent MAIL FROM:
> <>.  Locally generated and delivered mail shouldn't be bitbucketed.
> 

This seems to be putting the cart before the horse.

AFAIK, DSN's are for exceptional conditions. IE, in a well functioning
system, all messages get delivered and no DSN's need to be sent. Right
now we have a mis-functioning system where people send messages with
forged sending addresses, thus the DSN's are a DoS on the person
having their email address forged. Especially if they cannot be
programattically filtered.

But, perhaps they could?

How to do it is all sending systems attach a nonce (a random number)
to an email. All DSN's must include a nonce indicating to what this is
a response to. Users have the option to filter based on whether a
correct nonce is attached.

If a mailserver is changed to implement LMTP, it can be changed to
also implement the nonce scheme at the same time.

Scott

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg