Spam Links > Prevent > Authentication and Architecture

Email Authentication and Architecture

Much of this research is aimed at various verification schemes, to provide authentication of emails and bounces at the session or message stages, so that you know who sent a message. This is complementary to authorization, which is how you decide that a given sender (now you know who they are, having authenticated them) can send you messages.

Even fully authenticated, authorized email could be spam, so some degree of spam filtering will still be necessary, but these schemes help provide accountability and traceability in contrast to standard email.

Various strands of anti-spam research aimed at altering email in some manner in order to prevent spam have been brought under the umbrella of the Anti-Spam Research Group, of the Internet Research Taskforce. Many of the ideas have existed for some time, but have not been widely implemented, while others are only beginning to be placed on a firm engineering base.

Requirements for and Overviews of Anti-spam Research
Criticism of Anti-spam Research
Session Verification
Bounce Verification
Message Verification
Sender Authorization
New Email Protocols
Other Ideas

Requirements for and Overviews of Email Authentication

Anti-Spam Research Group (ASRG) website - asrg.sp.am/
Inventory of Problems Subgroup of the ASRG - asrg.sp.am/subgroups/problems.shtml
Consent Framework for Fighting Spam - www.shaftek.org/publications/asrg-consent-framework.html
SMTP is not secure - central.kaserver5.org/smtpbad.html
Email Security Anti-Spoofing Protection with Path and Cryptographic Authentication Methods - www.metasignatures.org/path_and_cryptographic_authentication.htm
Sender Reputation in a Large Webmail Service - www.ceas.cc/2006/19.pdf
E-mail authentication at Wikipedia - en.wikipedia.org/wiki/Category:E-mail_authentication
Efforts to Control Unsolicited Bulk Email - bbiw.net/recent.html#spam
Criteria for Proposed Techniques for the management of Spam - www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
Trust in Email Begins with Authentication - www.maawg.org/about/publishedDocuments/MAAWG_Email_Authentication_Paper.pdf

Criticism of Anti-spam Research

You Might Be An Anti-Spam Kook If... - www.rhyolite.com/anti-spam/you-might-be.html
Final Ultimate Solution to the Spam Problem (FUSSP) - www.FUSSP.org/
No anti-UBM measure for SMTP-based Internet mail works - homepages.tesco.net./~J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html
SPF is harmful - homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html
Why you shouldn't jump on the SPF bandwagon - spfsucks.2truth.com/ - mirrors: 1
Problems with Designated Sender - www.taugh.com/mp/lmap.html
SPF Loses Mindshare - www.circleid.com/posts/spf_loses_mindshare/
What else can we do to stop the spammers? - www.guardian.co.uk/technology/2006/nov/23/guardianweeklytechnologysection.insideit2

Session Verification

SPF and Microsoft's Sender ID are but the most famous of a whole set of proposed standards that are designed to prevent senders of email from forging the sender address; that is, using a “From” address that they are not authorised to use.

Session Verification Working Groups
Session Verification Drafts
Session Verification Analysis
Session Verification Tools
Session Verification Capable Spam Filters and Mail Servers
Sender Rewriting Scheme Tools
Session Verification Discussion

Session Verification Working Groups

SMTP Session Verification (SMTP-VERIFY) Subgroup of the ASRG - asrg.sp.am/subgroups/smtp_verify.shtml
IETF Compatible Low-level Email Authentication and Responsibility (CLEAR) - mipassoc.org/clear/

Session Verification Drafts

There is now a wide variety of suggestions for SMTP Session Verification. To the outsider, the differences between them are often hard to discern. Many of these drafts have been written as Internet Drafts, a precursor to the IETF RFC, seen by many as the only way to ensure a new protocol is widely reviewed and then implemented.

Connection Based Session Verification
SMTP Envelope Zone Session Verification
Reverse Zone Session Verification

Connection Based Session Verification

Trusted Email Connection Signing - www.jgc.org/blog/2007/02/trusted-email-connection-signing-rev-02.html

SMTP Envelope Session Verification

These methods to verify SMTP session use a tag in DNS associated with a domain to mark which IP addresses can send mail using that domain in the SMTP envelope.

Similar past proposals are no longer available on the web. Paul Vixie's “Repudiating MAIL FROM” was extremely influential. LMAP was a proposal that came out of the ASRG; another failed proposal was IMX, described in “Enhancing SMTP Mail Services To Minimize SPAM”.

Sender Policy Framework (SPF) - www.openspf.org/
Sender ID for E-Mail Technical Specification - www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx - now merged with SPF
Designated Mailers Protocol (DMP) - www.pan-am.ca/dmp/
A DNS RR for simple SMTP sender authentication (RMX) - www.danisch.de/work/security/antispam.html
The Case For RMX Records - www.mikerubel.org/computers/rmx_records/
Designated Relays Inquiry Protocol (DRIP) - www.sherzer.net/draft-brand-drip-02.txt
Anti-Spam Recommendations II for SMTP MTAs - db.org/2003/12/06/antispam/
DNS Naming Convention for Outbound Email Servers (mxout) - serverauthority.net/draft-lorenzen-marid-mxout-00.txt
Certified Server Validation (CSV) - mipassoc.org/csv/
.mail TLD - www.spamhaus.org/tld/
SPF Record Format and Protocol (SPF3) - elvey.com/draft-ietf-marid-spf3-00.txt
RIA - spamfizzle.com/default.aspx

Reverse Zone Session Verification

The owner of the reverse DNS zone can mark parts of the IP address space as able to send mail. This is much the same principle as a dialup-list DNSBL, but is applied by the owner of the IP space, so making it highly distributed and much more accurate.

Selective Sender - www.taugh.com/mp/ss.html
Marking MTAs in rDNS with TXT RRs (mtamark) - mtamark.space.net/

Sender Rewriting Scheme Tools

The need for sender rewriting in order to not break forwarding is a drawback of SMTP session verification methods. SPF proposes its Sender Rewriting Scheme (SRS), and these links provide tools and discussion of SRS and similar schemes.

Sender Rewriting Scheme - www.openspf.org/SRS
Return Path Rewriting (RPR) - www.roe.ch/Return_Path_Rewriting
SRS integration with sendmail - srs-socketmap.info/
SRS integration with qmail - wooledge.org/~greg/qmail-srs.html
Mail::SRS - www.anarres.org/projects/srs/
Sender Rewriting Scheme in Python - bmsi.com/python/pysrs.html
libsrs_alt - srs.mirtol.com/
libsrs2 - www.libsrs2.org/
qmail SRS patch - opensource.mco2.net/qmail/srs/

Session Verification Discussion

Discussion of particular implementations of SMTP Session Verification.

SPF Mailing List - www.openspf.org/Forums
RMX Discussion - news.gmane.org/gmane.ietf.asrg.rmx
ietf-mxcomp mailing list - www.imc.org/ietf-mxcomp/
.mail TLD discussion - forum.icann.org/lists/stld-rfp-mail/
Sendmail.net discussion forum - www.sendmail.net/forum/index.jspa
ieft-clear mailing list - mipassoc.org/mailman/listinfo/ietf-clear

Requirements for Antispam Measures
Spam Discussion

Bounce Verification

Bounce Verification is a way to reduce or eliminate the volume of backscatter reaching mailboxes. It uses a known token in the headers or SMTP envelope of all outgoing messages (apart from bounces, since these shouldn't be bounced); if a bounce arrives that doesn't contain the token then it is discarded.

Bounce Address Tag Validation (BATV) - mipassoc.org/batv/
BATV for Postfix - babel.de/batv.html
Authbounce for Exim - psg.com/~brian/software/authbounce/configure-authbounce.txt
Signed Return Addresses - www.tuffmail.com/backscatter.php
ABBS - see: qmail.safari.iki.fi/

Message Verification

Message Verification covers spam stamps, tokens, payment, “sender pays” or digital signatures, electronic signatures, e-postage and other technological methods used to authenticate or verify email messages. Authentication does not address the problem of authorization, a topic that is addressed in part by Trusted Sender Programmes. For some of the proposed solutions to this problem it is not entirely clear how the solution separates authentication from authorization. Challenge/response is a message verification technique that places the burden of verification on the human sender of the message, so it is not included under this section.