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