I've read back through the archives for April, but not before, so apologies
if this duplicates something earlier.
From my reading, it seems that a distributed challenge-response system is
perceived as too burdensome and too likely to cause problems (lost messages,
delays, and loops), and a centralized challenge-response system is perceived
as legally/politically/technically unworkable.
What I propose is that the large ISPs transition to cryptographically
authenticated email and use challenge-response systems for non-participating
ISPs. The proposal uses already existing protocols (S/MIME, SMTP,
SMTP-over-TLS) with relatively minor changes to existing software.
No new laws would be needed--impractical given the international nature of
email, anyway. Instead, ISPs will be responsible for declaring their
anti-spam policy and enforcing it with their users. Third parties will
handle complaints about ISPs not enforcing their policies. Note that the
third-parties do not set the policy, they only handle disputes about whether
the ISP is enforcing its policy on its senders. If ISPs feel that a given
third-party (dispute arbitrator) is not doing its job, it will treat all
email from ISPs using it as non-authenticated email.
Here are some (slightly disorganized and redundant) notes:
Each participating ISP must use cryptographic signatures when
sending or receiving messages from other participating ISPs and MUST
use a challenge-response system for messages not from participating
ISPs (unless the intended recipient has specifically requested
otherwise).
This is completely compatible with existing protocols. It allows
users to send messages to and receive messages from
non-partiticipating ISPS. The added C/R burden on users of
non-participating ISPs will put pressure on their ISPs to join the
system.
Users of non-participating ISPs can either use the
challenge-response system or sign up with a 3rd-party authenticating
service who will send/forward mail. (I think that in some countries
it may be a while before you can find an ISP that will be
acceptable.)
For brevity, I'll just use ISP as a generic term for entities
operating MTAs, although obviously not all are ISPs in the narrow
sense.
The cryptographic signatures can be on each message (S/MIME) or can
be for an entire session (HTTP-over-TLS). But the latter is only
acceptable if no further forwarding of messages will occur.
The certificate used to sign the message (or authenticate the
session) must be from a recognized Certificate Authority (CA), must
be "expensive enough" that spammers cannot easily get many of them,
and should be designated for email authentication purposes.
In the certificate, the responsible party (generally ISP) must
indicate which anti-spam policies are followed and procedures for
dispute resolution. It must include a party (which can be CA or
third-party) which will indicate whether the entity is following the
declared policies and dispute resolution procedures.
(e.g. must have automated certificate-revocation checking)
Example anti-spam policies--
- no open relays
- more generally, no sending of mail from unauthenticated parties
- no sending allowed to harvested emails
- double opt-in required for mailing lists.
- all senders identities and addresses have been authenticated.
(e.g. road-runner, but not Hotmail)
(4) In each email message, the class of sender and/or email should
be indicated
Some possiblities:
- This is a free email account without identity verification
- This user is limited to 100 messages/day
- This user is limited to existing correspondents + 10 messages/day
- This user has been active for more than 180 days and has no complaints
- This a new user
- This user is a paying customer resident in same country as ISP
- This email is an advertisement to existing customer
- This email is non-advertisement to existing customer
- This is a challenge message for email list subscription
- This is a challenge message for antispam purposed
- This is a message for a subscribed and confirmed email list
etc.
The properties that are supported are related to the general
anti-spam policies listed in the certificate.
From both a legal and technical standpoint, it is desirable that
each receiving ISP have the final decisions over:
(1) Which CAs are acceptable
(2) Which classes of certificates are acceptable
(3) Which dispute resolution arbitrators are reputable
(4) Which anti-spam policies are acceptable
(It may be desirable that individual users have the ability to
choose these.)
E-mail that does not meet the ISP's policies are subject to the
challenge-response system.
Almost all the technology to do this already exists. A workgroup
could specify what specific properties and polices need to be
defined and how to encode the necessary information in certificates
and email headers.
It might also be helpful for a workgroup to standardize message
headers for challenge-response systems to facilitate the requirements
that Brad Templeton enumerated:
a) Properly handle mailing list mail
b) Never challenge a reply to an E-mail you sent, even if you sent
it from elsewhere and a different account which aliases over to
the real mailbox.
c) Include protections against loops, obviously and challenging other
challenges, autoresponses etc.
d) Provide a means to allow the user to review all their blocked mail
(sorted by spam score) to catch the people who did not respond
to the challenge. Yes, these happen regularly even with simple
challenges, and not because the other person is lazy.
e) If you don't do (d), provide some other means for anonymous mail
and yes, mail from people with broken mailers, to make it to you.
Okay, discuss.
Ken Hirsch
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg