Re: Other SMTP verification methods

On Thu, 4 Mar 2004, Yakov Shafranovich wrote:

> Alan DeKok wrote:
> > Yakov Shafranovich <[email protected]> wrote:
> > 
> >>>  e.g. an originating MTA "logs in" to a recipient MTA, using
> >>>"[email protected]".  The recipient MTA then somehow authenticates
> >>>that user ID, using information published by "example.com".
> >>
> >>Wouldn't that be the same as the various callback systems?
> > 
> >   I'm not sure.  I've skimmed over the callback documents, but haven't
> > read them in detail.
> 
> One example is Hector Santos's CBV system. Another example is my CRI 
> proposal 
> (http://www.ietf.org/internet-drafts/draft-irtf-asrg-cri-00.txt). 
I'd suggest possibly redoing and renaming this document into just
authentication framework rather then Challenge/Response (fully computer 
automated challenge/response = authentication), this would be better as it
is more accurate representation of what is tried there and it distances 
the document from all other human-intervention-required  challenge/response
systems (which are also perceived negatively by many for how they operate) 
and from possible pattent claims. However I'm not certain its all worth 
it any case.

> There
> is also regular C/R and the use of MSG TRK mentioned by William Leibzon 
> (I think). In CBV you do a RCPT TO and if it passes, then the email goes 
> through. In my CRI proposal there is a ESMTP extension for C/R and 
> special headers for non-compliant MTAs and compliant MUAs. In William's 
> proposal is the use of MSG TRK protocol for this.
MSGTRK protocol has its own problems, its possible IESG may not let it 
through to RFC status eventhough its drafts are complete. It seems 
unlikely that it would be widely deployed (and to work it will require
separate software to be added to every mail server that will actually 
have keep information about every message that passed through the mail 
server - i.e. it requires separate sizeable log database - so deployment 
is would be very slow - even slower probably then just extension to SMTP). 
Rather people are more willing to work on new mail protocol that would 
include message tracking as part of the design of new system.

I'm starting to work instead on possible a draft for direct message 
tracking with cryptographically signed tracking information that 
would not require msgtracking database server, but I do not believe this 
would be deployed either because its will be usefull only if many upgrade 
their software (nor do I expect that spammers would actually follow this) 
and the reality is that the deployment-time/benefits ratio is not good if 
it requires updates to all MTAs to be effective and requires for the SMTP 
extensions to actually go all the way through IETF process. 

> All of these callback schemes have possible DDOS and privacy problems, 
> not to say they should not be done but we must tread carefully.
Anything that relies on ability of sender to verify the existance of
receipient's email address is somehow looked negatively as people believe 
it maybe used by spammers to harvest email addresses. But the reality is 
that spammer can already do that by sending an email - properly run 
systems would provide a bounce (often at SMTP level) if address is not 
correct. Same with DoS, if somebody wants to DoS somebody elses email they 
would mailbomb that person. So I do not see that callback systems really 
introduce anything new to the picture. 

William