ietf-mxcomp
[Top] [All Lists]

Re: Principles of Spam Abatement

2004-03-03 15:02:49

Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:

Many of these principles have been well argued over many times. Can you 
clarify where you want to go with this?

   In my experience, discussion of spam-abatement always gets engulfed
in flame-wars between people who know the "one-true-spam-solution" and
feel obliged to correct others whose "one-true-spam-solution" differs
in the slightest detail.

   Some shared basis is needed to get past the initial flame-wars.
I don't honestly know whether working up consensus on principles is the
best way to accomplish that, but it seems like a relatively easy way.

   In any case, I _don't_ intend that such a discussion should happen
_during_ the BoF. The principles I posted represent a first pass at
consensus on the <ietf(_at_)ietf(_dot_)org> (IETF General) mailing list: thus
they _might_ be a good starting point for such a discussion when a WG
forms.

John Leslie wrote:
- All communications must be by mutual consent.

- The spam problem starts with freely accepting mail from strangers.

The main value that the Internet brings to the world is a cheap 
pervasive communications medium. This is the basic underlying principle 
that makes all of the Internet services and applications so great. 

   Quite possibly that needs to be listed as a principle.

Spammers, hackers, DDOS attackers, etc, all utilize the same three 
properties to do the bad stuff. Our goal is to stop the bad guys while 
keeping the Internet cheap and pervasive.

   I'm not sure that's even a reasonable goal -- least of all attainable.
First of all, we're addressing an extremely small slice of the Internet:
SMTP traffic; and considering a very small subset of issues within it.
At most, we'll be weakly authenticating the source/sender envelope-style
information.

   The Internet will stay cheap and pervasive regardless of what we do;
and nothing we could possibly do will "stop" "bad guys" from abusing it.

Restricting communications except by consent reduces the value of the
Internet as a communications medium.

   Agreed. But in the absence of good information to inform that consent,
its value will be reduced even more.

   Maybe we need to state a principle that no human being can effectively
read more than a thousand (e.g.) emails per day...

What I do not like about these two statements is the fact that today you 
can accept email from a stranger and you are implying that it should not 
be so.

   I don't read it that way at all. Whatever you read today, you read
because you consent to reading it. People are beginning to withhold their
consent, however. We need to encourage them to feel more comfortable
about consenting.

What you need to clarify here is whether "all communications must 
be by mutual PRIOR consent" or even "post-facto" consent.

   I welcome any discussion of changing the wording. (If you're asking
my personal opinion, I see no reason consent cannot be delayed.)

- Spam is and will remain a long-term battleground and it needs serious
  effort to counter.

I agreee. This has also been pointed out in Dave Crocker's draft as well 
which also lists 17 points for spam solutions (see 
http://brandenburg.com/specifications/draft-crocker-spam-techconsider-02.txt).

   Dave's draft is excellent, but gets into implementation details,
which I'd rather not do before we reach some consensus on what piece
of the problem we're hoping to solve.

- Every mail message carries a practically unforgeable token: the IP
  address of the SMTP client.

I would clarify this more. The IP address is known at the time the SMTP 
transaction takes place. However, by the time the messsage gets to the 
MUA or relayed inside the organization, the "Received" headers cannot be 
fully trusted since they can be forge. "Fully trusted" - they *can* be 
trusted but not fully.

   I'm hoping we can concentrate on the IP address during the connection,
and avoid pointless arguments about which "headers" are trustworthy.

- It is pointless to erect some expensive Maginot Line and pretend it
  will solve the problem.

Not sure what you mean here, perhaps you can elaborate? Are you refering 
to propopals that propose a new separate email system which is 
trackable, something like "fedex" for email?

   I take this to mean we should resist throwing inordinate amounts of
effort into any "solution" in the (false) belief that it will "stop"
the spam. History is quite clear: it won't. We should instead tackle
simple things which we can specify well enough to be deployed quickly.

- There is not and can never be a hoop low enough to pass all human
  strangers but exclude spammers' computers.

I am assuming you are refering to pseudo-Turing tests. At the ASRG there 
was also some debate on whether spammers can use real humans for such 
tests via porn sites and such, and the conclusion was that very possibly 
for Turing tests on email registrations but not on email by email basis.

   This really didn't arise in that context; though we'd probably stick
by it even in that context: spammers' computers could "increment by one
and test", bringing receivers' systems to their knees.

   The context of this is that many humans will resist "Turing tests";
and that others will fail them, perhaps due to handicaps.

- Spammers need scale because they get a very low return. Therefore,
  part of the solution should be to deny scalability to spammers.

At the same time the email infrastructure of the Internet scales as well 
and we must make sure that if we want to deny scalability to spammers, 
we need to make sure everyone else does not lose it. If you can, please 
elaborate on this point, since I am not getting it 100%.

   I'd have to go back to the original poster. My recollection is that
he went on to talk about imposing (increasing) delays on SMTP sessions
containing suspected spam.

- If we can communicate to the sender (without adverse side effects)
  that a message is discarded, then occasional false positives aren't
  as much of a problem.

I agree but I am not sure how you can do that to senders and not 
spammers, especially in today's world where hijacked machines are often 
used to send spam and no real difference may exist between spammers and 
senders.

   This was originally stated as communicating "discarded as spam", but
revised to simply "discarded". IMHO, there's no harm in letting a
spammer know the message was discarded -- the harm's in letting him
know that there's a real human who would have read it if it weren't
discarded.

   I believe we reached consensus that the benefit to the honest sender
of a false-positive greatly exceeded the harm of letting a spammer know
the message was discarded.

- If you reject the message during the SMTP session you don't need to
  generate a bounce message, the other side will do this.

I agree with the underlying drive BUT this really goes against the next 
statement. Email operates as a store and forward system, if during hop A 
email goes through and fails on hop C, than hop C needs to send back a 
bounce message. You are not suggesting that all three hops should stay 
open? Perhaps you can clarify?

   This, I believe (I didn't write it), meant to say that any problems
of determining the appropriate recipient of a bounce message disappear
if the error is given _during_ the SMTP session.

- Errors returned after the close of the SMTP transaction are likely
  to go to an innocent party; and should be deprecated for any email
  identified as spam.

   I did write that one.

I disagree. Many type of errors occur after the SMTP transaction is 
closed, especially in situtations where internal relaying is done, or 
the external SMTP gateway has no knowledge of internal systems. 

   I stand by the principle, though I'm willing to reword it a bit to
allow generating a bounce if the SMTP server has somehow authenticated
the address to which the bounce is sent.

   I believe there is consensus that most spam and virtually all
viruses forge the sender email addresses; and that the harm of returning
bounces to these forged addresses greatly exceeds the benefit if they
_happen_ to be valid.

   If I may elaborate about store-and-forward: the final recipient knows
the least about the validity of email addresses and SHOULD NOT return
bounces to dubious addresses, except as errors _during_ the SMTP session;
any prior SMTP server in the chain SHOULD have some authentication and
MAY return bounces to dubious addresses; but we're presumably talking
about messages which are spam-like under any evaluation, and the RFC
requirements to return bounce messages need to be reconsidered.

   (IMHO, that is...)

Additionally, *if* the bounce address was authentication such as in any 
LMAP proposal, this is not necessary.

   There may well be cases where the sender is sufficiently authenticated
to justify a post-SMTP-session error emailed to that address; but the
bounces to wrong addresses are _so_ common today, and _so_ confusing to
many end-users, that we should err on the side of not reporting whenever
the address is dubious.

====

BTW: I have no desire to start a long-winded discussion on this list;
but I'm replying to Yakov, who evidently felt it was important to ask
on-list.

--
John Leslie <john(_at_)jlc(_dot_)net>


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