Path validation: Difference between revisions

From ASRG
Jump to navigationJump to search
No edit summary
(→‎Accountability: new section, to summarize recent discussion)
Line 22: Line 22:


* All-in-one web mail: Web mail systems including Yahoo and Google Gmail allow users to collect mail from other mailboxes via POP or IMAP and send mail with those mailboxes as return addresses.
* All-in-one web mail: Web mail systems including Yahoo and Google Gmail allow users to collect mail from other mailboxes via POP or IMAP and send mail with those mailboxes as return addresses.
= Accountability =
The rationale of path validation techniques is to hold a sending client responsible for what it transmits. Providers may terminate spammers' accounts upon receiving complains, and damages resulting from spam may be claimed before courts. Even if resorting to such extreme measures is sporadic, the theoretical possibility to take that course helps keeping control. To this end, various tokens may be considered in order to learn who is the accountable party.
== IP addresses ==
The immediate client IP address is the one fact about ''every'' MX-driven attempt at message transport that the receiving MTA can know with very high certainty, even when the message is originated by someone who maliciously tries to hide his identity. IP addresses are trackable and ultimately tied to an ISP, even if that carrier is often an upstream one. However, there is no working global mechanism for identifying an accountable party (i.e. one who explicitly ''accepts'' accountability) from an IP address, due largely to the political and historical variations in how IP addresses have been allocated.
== HELO name ==
The helo name can be verified to match the IP address in various ways. The CSV paradigm is that the operator of a MTA should exercise some responsibility for what is sends. Its HELO string validation states whether that domain exercises responsibility. However, even if ''mta.example.com'' is the true FQDN of the responsible transmitting client, the hostmasters at ''example.com'' can unilaterally delegate ''mta.example.com'' the way they wish, with no obligation whatsoever to run a whois service or otherwise publish data about their delegate's admins, if any, and in general do not take accountability for what a transmitting client in the subdomain sends.
== Right Hand Side of MAIL FROM ==
This is the mail domain used for SPF checking. For registered domains, whois data exists, even if it's possibly privacy concealed. SPF allows to verify that an IP address is authorized to relay mail on behalf of that mail domain, but says nothing about possible accountability implications.

Revision as of 06:21, 4 July 2009

Techniques that match up the apparent sender of a message with the path via which it arrived.

  • SPF (Sender permitted from)
  • SRS (Sender Rewriting Scheme)

General issues

Internet mail is designed to make message delivery independent of the path a message takes. Although much, perhaps most, mail is sent from hosts managed by the same people that manage domains in a message's header or envelope, there are a variety of well known situations where mail can legitimately arrive via other paths. Some of these situations are:

  • Courtesy forwards, e.g. professional organizations and college alumni assocations. They remail messages to a recipient's actual address, so the recipient system sees the message originating at the forwarding site.
  • Users of courtesy forwards. Since courtesy forwards tend to be inbound only, users send mail from their own ISP with the courtesy forward address.
  • Mailing lists. Messages are resent from the list host.
  • Mail-an-article and kiosks. Web sites allow users to send limited amounts of mail manually entering To: and From: addresses.
  • All-in-one web mail: Web mail systems including Yahoo and Google Gmail allow users to collect mail from other mailboxes via POP or IMAP and send mail with those mailboxes as return addresses.

Accountability

The rationale of path validation techniques is to hold a sending client responsible for what it transmits. Providers may terminate spammers' accounts upon receiving complains, and damages resulting from spam may be claimed before courts. Even if resorting to such extreme measures is sporadic, the theoretical possibility to take that course helps keeping control. To this end, various tokens may be considered in order to learn who is the accountable party.

IP addresses

The immediate client IP address is the one fact about every MX-driven attempt at message transport that the receiving MTA can know with very high certainty, even when the message is originated by someone who maliciously tries to hide his identity. IP addresses are trackable and ultimately tied to an ISP, even if that carrier is often an upstream one. However, there is no working global mechanism for identifying an accountable party (i.e. one who explicitly accepts accountability) from an IP address, due largely to the political and historical variations in how IP addresses have been allocated.

HELO name

The helo name can be verified to match the IP address in various ways. The CSV paradigm is that the operator of a MTA should exercise some responsibility for what is sends. Its HELO string validation states whether that domain exercises responsibility. However, even if mta.example.com is the true FQDN of the responsible transmitting client, the hostmasters at example.com can unilaterally delegate mta.example.com the way they wish, with no obligation whatsoever to run a whois service or otherwise publish data about their delegate's admins, if any, and in general do not take accountability for what a transmitting client in the subdomain sends.

Right Hand Side of MAIL FROM

This is the mail domain used for SPF checking. For registered domains, whois data exists, even if it's possibly privacy concealed. SPF allows to verify that an IP address is authorized to relay mail on behalf of that mail domain, but says nothing about possible accountability implications.