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.