Antispam-certified mail servers.
Ken Hirsch
2002-05-03
Voluntary certification. Other SMTP traffic is allowed. Certified
servers may accept mail from non-certified servers as specified below.
In order to be considered a compliant server,
I. INCOMING - Each incoming connection to the server must be checked
(SMTP "clients" may of course be other SMTP servers.)
A. Connections from outside SMTP clients must either be checked by
IP address or by (client) certificate in the TLS handshake (IP
addresses should be checked with reverse DNS, etc.)
B. A connecting client must be recognized in a positive (whitelist)
manner. While more than one kind of whitelist is possible (e.g.
Bonded Sender, antispam-certified, etc.), the whitelist must be
revokable. Compliant servers may cache the checking of the
connecting clients, but there must be a time-limit on the caching.
[Servers may use more more than one way to validate an incoming
connection, but it must treat unknown servers as in paragraph D.]
C. Clients that are not on a recognized whitelist must be checked
against a blacklist of open relays and other unforgivable behavior
(e.g. not responding to either postmaster or abuse(_at_)server).
D. If a client is neither on a whitelist or a blacklist, then each
message from the client is treated as unauthenticated and subject to
either (1) certificate checking or (2) challenge/response
authorization. The certificates of signed messages are subject to
the same verification and policies as the certificates of clients
connecting to the SMTP server. When per-message certificates are
used for authentication purposes, each message signature must be
checked to make sure it is valid and each RCPT TO address must be
listed as a recipient within the signed portion of the message.
E. Messages from whitelisted clients are generally not subject to
per-message authorization, except that this may be specified in an
anti-spam profile.
[There should be an SMTP extension which requests that each email
should or should not be signed by the outgoing server.]
Servers may sign messages whether or not they are requested to.
Again, when per-message authentication is used, each message
signature must be checked to make sure it is valid and each RCPT TO
address must be listed as a recipient within the signed portion of
the message.
F. Each server must have an address where its compliance to incoming
messages can be checked (but not postmaster).
G. Each server must respond appropriately to messages to postmaster.
For each server, there should be a responsible person that can be
contacted by the whitelist administrator at a separate mail address.
This address need not be published.
II. OUTGOING
A. The party responsible for the SMTP server must agree to an
explicit anti-spam policy set by a whitelist administrator. The
administrator of the SMTP server is responsible for enforcing this
policy on the users of the server. The administrator of the
whitelist is responsible for verifying that the SMTP server is
enforcing the policy and to handle complaints against the SMTP
server. The whitelist administrator has the authority and technical
means to revoke the authorization of the SMTP server.
B. Clients connecting to an SMTP server to send outgoing mail must
be authenticated.
C. The originating SMTP server may add headers that give
information about the sender. E.g. Hotmail & Yahoo may (should)
distinguish between paying customers and free customers. Further
classification of customers is possible. The originating SMTP
server must not allow its users to forge these headers.
D. The original sender may add message headers for classifying the
mail. The originating SMTP server may also add/require/verify these.
E. The originating SMTP server must be able to sign each message
with the certificate issued by the whitelist administrator.
Transparent signing should be used [RFC1847/RFC2633] so that users
without S/MIME-compliant MUAs can read the message.
F. Each server must respond appropriately to messages to postmaster.
For each server, there should be a responsible person that can be
contacted by the whitelist administrator at a separate mail address.
This address need not be published.
III. WHITELIST PRACTICES
Some parts of this section are applicable only to whitelists that
use cryptographic certificates as part of the authentication and
authorization process. Other parts are applicable to any feasible
whitelist. For cryptographic authentication, the whitelist
administrator may be the CA or must work with the CA to sign and
revoke certificates.
A. Procedures that are used to identify, authenticate, and authorize
whitelist members must be published.
It must not be possible for a spammer to obtain many certificates
without significant penalties.
If strong identity can be established, a whitelist administrator
would (1) check the identity against a database of known spammers
(2) get the person to sign a contract to abide by a set of
antispam policies.
[While it is not mandatory for whitelist administrators to
exclude persons who have been declared "known spammers" by other
whitelist administrators, their reputation is at stake. Among
the possibilities are (1) requiring a large deposit against any
claims made against them, (2) assigning them to a lower user-class so
recipients can filter them...]
When whitelist adminstrators revoke a certificate because of
spamming activity, they must publish enough details of the
identity of the spammer that other CAs can identify the person if
they apply to them. Since this may contain somewhat sensitive
information (such as social security numbers), this information
should be available to other CAs, but not for casual inspection,
much as a credit-reporting agency does. In fact,
credit-reporting agencies may find this within their scope.
Not specified: up-front costs/renewals/bonds/credit checks ...
There may be more than one procedure used to verify members but
the certificate must specify exactly which class the user falls
into.
B. The antispam policy that is going to be enforced on the
certificate holder needs to be posted. There may be more than one
policy, but the certificate must specify exactly which one will be
enforced on that user. This needs to be available (via HTTP, HTTPS,
and SMTP) from the whitelist administrator. The policy needs to be
available in human-readable form and, hopefully,
program-understandable form. It may be possible to embed a summary
of the policy in the certificate.
C. There must be a simple, automated way to check whether a
whitelist member's authorization has been revoked.
D. There must be clear procedures for filing complaints against servers
on the whitelist. These complaints must be acted upon in a timely
manner. It must be easy to determine where/how to complain from the
certificate.
E. Whitelist administrators must actively check compliance of the
members. They must post email addresses on the web and USENET (in a
way not obviously linked to them) that they will monitor for spam
from their members. They must periodically check that member's
incoming SMTP servers correctly handle at least the following cases:
1) A client with a valid certificate
2) A client without a certificate
3) A client with a recently revoked certificate
4) A signed email with a valid certificate
5) A signed email with a recently revoked certificate
6) An email with an invalid signature
IV. CHALLENGE-RESPONSE
Email users who do not have direct access to a certified antispam server
need to be able to send to one. They could contract with a third-party
mail provider who is antispam-certified. They can also acquire a
personal antispam email certificate and use it with an S/MIME-capable
MUA. These will be accepted by a compliant server.
For other users, antispam-compliant servers must provide a
challenge-response system.
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.
[This must include opt-out replies to a mailing]
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.
----------------------------------------------------------------
Opportunities for standardization:
- requirements of antispam certificate
- mechanism for CRL retrieval
- machine-understandable description of spam-policy
- message headers for challenge-response
- message headers for user-classification
- message headers for message-classification
- SMTP extension to negotiate message-signing
----------------------------------------------------------------
My thinking about "SMTP extension to negotiate message-signing" is that
in many/most cases, you want to avoid the overhead of the signature
(which is about 1K without embedded certificate and 4K with embedded
certificate), but that it is very valuable for proving abuse.
You may want to have messages signed depending on the CA/whitelist or on
the particular client connecting. The CA may not have an established
reputation and you may want to keep a chain of evidence in case they
turn out to be unreliable. The client connecting may have a user-class
indicated in their certificate that is less than stellar.
Messages especially should be signed if the receiving SMTP server is not
the final destination. This may mean that signatures could be
negotiated depending on RCPT TO, not just on a session basis. Or perhaps
based on the MAIL FROM address, too.
I include the requirement that the actual RCPT TO recipient is included
in the signed part of the message because determining whether a message
is spam must include that information. It is also important that the
signing date is relatively recent since it needs to be determined
whether a message is sent before or after an opt-out.
This is the only change to SMTP that is required by this proposal.
--------------------------------------------------------------------
Proposed implementation:
Phase 1:
All participating servers validate other participating servers via IP
address. A challenge-response system is provided for
non-participating servers. This can be done with current software
(most any mail server plus TMDA). TMDA would just need to be
configured to exempt whitelisted servers from the challenge-response
system.
[Annoyance of challenge-response will encourage other SMTP servers
to become certified.]
Phase 2:
Signed messages would be checked and exempted from challenge-response
if they pass. Messages may be signed at originating server or by MUA.
Software changes: Challenge-response systems would need to be modified to do
this checking. SMTP servers aren't mandated to sign at this point, but may,
so they don't
Phase 3:
All participating servers sign outgoing messages. The server that
they connect to may request that they not sign messages (e.g. via
an EHLO response), but that does not have to be honored. (Messages
may be signed before being submitted to the mail server software.)
[Annoyance of all those .p7s attachments will encourage other SMTP
servers to become certified.]
Phase 4:
Servers should support TLS and SMTP extensions for negotiating
message signatures that may depend on MAIL FROM and RCPT TO.
--------------------------------------------------------------------
Antispam policies should be as objective and verifiable as possible.
None of these will be universally mandated (except probably the first
four.)
- no open relays
- more generally, no sending of mail from unauthenticated parties
- opt-out must work
- 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)
In each email message, the class of sender and/or email should be
indicated. These could be used to filter messages or require
challenge-response, even from a certified server.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg