[oclug] I am angry. Spam went to far today. Want to fight back.

[Jacques B.]

> Unless the new protocols are 100% backwards-compatible, they will never be
> adopted.  If they're 100% backwards-compatible, then they will not have fixed
> the problem, would they?  Cf. Pandora's Box.

True.  But if the new protocol was 100% backwards compatible in the
transition phase only, and eventually it could drop the old protocol
then it might work.

>
<snip>
> (2) Whitelisting is not an improvement on what we have now.

Agreed.

> --smw

It should be something that cannot be manipulated/spoofed.  It would
not stop spam. But it would allow people/providers to properly trace
back either a compromised machine that they could take offline until
the owner deals with it, or to trace back the true sender of spam (if
any of them actually send from machines they own) to deal (either
through local laws or through blacklisting the email address and/or IP
or IP range if the originating provider is spam tolerant.

Preventing the manipulation of headers (IP and email address of the
true sender) would certainly aid in combating spam (as well as for
phishing, 419 scams, eBay scams, threatening emails, and all the rest
of the stuff where masking one's identity is desired).  I agree that
it would not eliminate it.  But alas just like when you invent a
better mouse trap they invent a better mouse.  You invent a better
protocol and they will invent a better way to circumvent it.

A provider might be able to accomplish better authentication and
non-repudiation by providing its customers with a unique token that
they would have to place on their machine (much like a SSH key) which
would be provided by the mail client when authenticating to send
messages.  Of course that wouldn't work for web based email services.
I guess it's like all aspects of security.  It can be done but
convenience will suffer.  When spam becomes more of an inconvenience
than implementing a better email protocol then we'll see the change
happen.

Jacques B.