ietf-mxcomp
[Top] [All Lists]

Re: Principles of Spam Abatement

2004-03-03 13:20:05

John Leslie wrote:
On the <ietf(_at_)ietf(_dot_)org> mailing list there has been discussion of
Principles of Spam Abatement. This is a brief summary of principles
which _may_ have consensus of that list. I accept full responsibility
for editing errors and misunderstandings.


John,

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

- 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. 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. Restricting communications except by consent reduces the value of the Internet as a communications medium.

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. What you need to clarify here is whether "all communications must be by mutual PRIOR consent" or even "post-facto" consent.

- 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).

- 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.

- 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?

- 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.

- 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%.

- 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.

- 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?

- 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 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. Additionally, *if* the bounce address was authentication such as in any LMAP proposal, this is not necessary.

Yakov

Yakov


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