ietf-mxcomp
[Top] [All Lists]

RE: User experience

2004-04-07 22:37:12
Hector, thanks for this very interesting suggestion.  As soon as our developers 
have finished coding up Caller ID I'll ask them to get to work on this new 
protocol extension.  :-)  
 
Seriously this is an interesting idea and as you pointed out earlier could have 
multiple uses.  That said, I have two concerns.  
 
The first is adoption.  Even if such an extension were available today, we'd 
have thousands of legacy SMTP clients and servers out there to deal with.  And 
both ends of the connection have to be upgraded to make this work.  That's a 
serious adoption barrier.  Caller ID tries not to require upgraded SMTP at both 
ends in order to detect spoofing, and I believe SPF is similar in this respect. 
 To be sure, they will eventualy all get upgraded, hopefully, if everyone 
starts performing this type of validation.  The point is not to *require* 
upgraded software at both ends before the mechanism can work. 
 
The second point concerns the motivation for such a change.  As I understand 
it, the goal is to be able to reject a message as early in transmission as 
possible in order to a) conserve bandwidth and b) not generate bounce messages. 
 Correct me if I'm wrong here.  I noted earlier that rejecting at MAIL FROM or 
at end of DATA are equivalent in terms of not generating bounce messages.  Let 
me comment on bandwidth saving.  
 
This is of course a laudable goal.  But are we really going to save much 
bandwidth?  It seems to me that if we reject messages on the basis of the MAIL 
FROM then spammers will simply register throwaway domain names, publish the 
appropriate DNS records and pass the validation.  We'll end up taking the 
message over the wire anyway and putting it through other types of filtering 
and spam detection.  I don't see much bandwidth savings here.  Our view with 
Caller ID is that performing the validations on the 2822 headers gives a more 
accurate and user-centric determination of the sender.  
 
Now, once you've determined that a particular domain or IP address has sent you 
forged mail, then you can use all kinds of interesting strategies to save 
bandwith on subsequent traffic from that source.    

________________________________

From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org on behalf of Hector Santos
Sent: Wed 4/7/2004 12:21 PM
To: John Gardiner Myers; ietf-mxcomp(_at_)imc(_dot_)org
Subject: Re: User experience




Good point.  Yes, that would certainly benefit proposals such as Microsoft
and Yahoos.

It would probably need to be augmented with a BDAT that specifieds the
"chunks" that make up the HEADer only, unless the standard is set so that
the first chunk always contains the header.

Anyway, thanks for pointing this out. Its doable and I think Microsoft
should look at promoting it to help their proposal. It makes sense across
the board otherwise, the pressure is put on SMTP vendors to add DATA hooks
or provide "solutions" or methods for a post smtp support, that might be
outside the whelm of the SMTP software.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message -----
From: "John Gardiner Myers" <jgmyers(_at_)proofpoint(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Wednesday, April 07, 2004 2:09 PM
Subject: Re: User experience



Hector Santos wrote:

What your MCEP (Microsoft' Caller ID Email Policy) design is screaming
for

is a split of the DATA command into two parts, HEAD plus BODY.

The existing CHUNKING extension is quite capable of signalling
rejections before the entire body has been sent.  There is no need for a
third way to send the message text.







<Prev in Thread] Current Thread [Next in Thread>