--On Wednesday, 22 August, 2007 00:22 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:
On Fri, 17 Aug 2007, John C Klensin wrote:
One could preserve the relaying by turning message
transmission and delivery into a multiple-stage handshake:
* Message notifying recipient of availability
* Message from recipient to store asking for
transmission of the real message
* Transmission of the real message
I don't understand how it can be easier to do anti-spam checks
in an IM2000 design than in current email. The check has to be
performed during the first step otherwise you have already
lost, but the notification has fewer clues for an AI to work
with.
FWIW, I agree completely. For anti-spam purposes, the only
value of this sort of drill, IMO, would be to authenticate the
message sender. While it doesn't have much appeal to me, there
is a fraction of the community for which "no incoming email at
all except by prior arrangement" makes sense. For them, if the
receiving system had a whitelist of acceptable backward-pointing
addresses and could authenticate the legitimacy of those
addresses when a message arrived and reject any other messages,
those users would see no spam. For the rest of us, there is
certainly a large fraction of today's spam that can be rejected
on the basis of bogus or inconsistent backward-pointing
addresses. However, I believe that, if we were to make major
changes just to deal with such addresses, the spammers would
quickly clean up their acts and start using better ones (see
Paul Vixie's piece, cited some days ago).
Even for the more restricted community, the approach leaves some
open questions, e.g.,
* Whether that community is important enough to justify
mail protocol changes, and
* Whether the additional opportunities for attacks that
are introduced by a multi-step process overwhelm any
possible advantages from first authenticating the sender
and then fetching the message content (presumably in an
environment in which it is possible to authenticate the
sender if the message content arrives in a single
transaction).
Put differently, there is a community for whom a "we are not
willing to receive mail except from known, authenticated, and
trusted senders" solution would be sufficient to control what
that community considers spam. That is largely because their
effective definition of spam requires neither "bulk" nor
"commercial" elements, only "sent by someone I haven't
pre-approved". For that situation, and modulo the issues with
authentication mentioned in the article Steve Bellovin cited as
well as some other issues about how one authenticates, the
presumption is that one doesn't need to worry about scanning
message content for evidence of possible spam.
However, even that narrow an acceptance rule assumes that one's
trusted friends have not been turned into zombies. It will not
prevent introduction of malware (by forwarding from careless
and/or zombie friends). If one is concerned about malware, then
one needs to scan message content anyway (as I think you are
suggesting) and the appeal of what I understand of Doug's
proposal is reduced to saving the bandwidth for the messages
that can be rejected on the basis of backward-pointing addresses
at the cost of additional complexity, handshaking, etc.
I'm not convinced that is worth it --and strongly suspect it is
not-- but, if Doug believes otherwise, I'm looking forward to
seeing a proposal.
best,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf