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.
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@xxxxxxxxxxxxxx>
To: <ietf-mxcomp@xxxxxxx>
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.
>
>
>