Path validation

From ASRG
Jump to: navigation, search
Anti-spam technique: Path validation
Date of first use: late 1990s
Effectiveness: Low
Popularity: Medium
Difficulty of implementation: Low to do poorly, High to do well
Where implemented: MTA
Harm: Medium

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 complaints, and damages resulting from spam might hypothetically be claimed before courts. Even if resorting to such extreme measures is sporadic, the theoretical possibility to take that course helps to keep 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, DNS hierarchy neither follows nor implies administrative hierarchy, as stated in RFC 5507 section 4 "Zone Boundaries are Invisible to Applications".

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.