ietf-smtp
[Top] [All Lists]

Re: draft-duan-smtp-receiver-driven-00.txt

2005-05-10 12:42:08

John, 

Thanks for your note. In DMTP, we use coarser MTA classifiers at the
level of their IP address or domain names -- not the fine-grained
email-address classifiers (as you seem to mention below). Using the
latter would indeed have the problems you describe -- but DMTP I-D
does not use email-address classifiers. Its possible to do that, but
only with the kind of strong sender authentication you mention, which
is the reason we steered away from them in the first place.

- Kartik

On 5/10/05, John C Klensin <john+smtp(_at_)jck(_dot_)com> wrote:


--On Tuesday, 10 May, 2005 00:52 -0400 Kartik Gopalan
<kartik(_dot_)gopalan(_at_)gmail(_dot_)com> wrote:

...
DMTP gives solution to the scenario that none of the currently
used anti-spam technologies can satisfactorily handle without
receiving the entire message. DMTP intent messages are used
ONLY for unclassified senders that are neither in receivers
MTA's whitelists nor blacklists.  It is only unclassified
senders who are treated using the receiver-pull model. And
even to this category you can apply the same
sender-discouragement schemes that are currently being applied
-- such as greylisting, any other challenge-response schemes,
etc.
...

Kartik,

I want to reinforce, from a different perspective, one of Tony's
points.

Ultimately, to let a message through, you are depending on a
whitelist that is, in turn, based on sender addresses.  Your
greylist technique, effective or not, is ultimately just a
technique for determining which addresses get onto the
whitelist. That causes you to inherit all of the issues with
whitelists based on sender addresses, especially the fact that,
in the absence of strong authentication, sender addresses are
easily faked.  If, as a receiver, I've got sufficient
infrastructure --probably, but perhaps not necessarily, PKI
machinery-- in place to authenticate sender addresses, then I
probably don't need your technique.  If I don't, then all the
spammer needs to do is to send messages to me that are "from"
people whom I know and with whom I have corresponded in the
past.

Not only is that not hard, but they are doing it today.

That brings me to the serious downside of this, and many other,
"maybe it would help at least a little bit" ideas.    Assume,
for purposes of argument, that the details of your proposal,
such as not understanding how to use the SMTP extension model,
can be sorted out.   Assume you can get it widely enough
deployed in sending and receiving SMTP servers to make it useful
without putting huge burdens on legitimate, known, users trying
to exchange mail with each other (for better or worse, this is a
very high barrier).     Now, what we end up with is:

(1) Another list of really-good addresses that can presumably be
easily harvested by an address-harvesting virus.   Note that
your technique is of almost zero use against a spam generator
who relies on compromising a machine and using the sender name
to spam the people in the and address books or using the names
in the address book to spam the machine's owner from other
machines at a later date.  In either case, names intentionally
put in the address book or whitelist are presumably already
whitelisted.

(2) Another cycle in which: (i) A technique reduces the amount
of spam that is received slightly. (ii) The spammers respond by
increasing the amount of spam sent by, say, twice that amount,
resulting in a slight increase in the amount of spam received.
(iii) The spammers then devise a countermeasure.  In this case,
the countermeasure is quite easy: address-pair lists are
apparently already in heavy use by some spammer-enabling tools.
Net result is an increase in the total amount of spam being
delivered by around twice the amount that your method presumably
stopped.

Those "arms race" cycles are not good for anyone concerned.

     john