SMTP pull
| Anti-spam technique: SMTP pull | |
|---|---|
| Date of first use: | ? |
| Effectiveness: | Low |
| Popularity: | Low |
| Difficulty of implementation: | High |
| Where implemented: | MTA/MUA/MSA |
| Harm: | ? |
SMTP pull is the opposite of SMTP push, the usual store and forward model. SMTP pull provides for the sender to submit only part of a message, an offer. Either the MUA or the MTA will then pull, i.e. connect to the relevant server and fetch the rest of the message's content.
Pull proposals for anti-spam purposes provide for asynchronous pull, i.e. storing offers in a queue and fetching the relevant content at some later stage. Synchronous pull allows to fail an SMTP transaction in case fetching the content fails, which is not feasible for the MUA case. A variant of this kind of proposals (this) provides for replacing SUBMIT so as to avoid SMTP entirely.
Advantages
The pull model might lend itself to traffic optimizations that are not possible otherwise. In case the recipient can determine from the offer that the content is not interesting, its transfer can be avoided altogether. As automated verifications can be done both synchronously and asynchronously, the only residual advantage for the case of the asynchronous MTA-pull is the added shield against DNS poisoning that asynchronous DNS queries imply.
Psychologically, an apparent advantage may loom from the confusion generated by speaking of clients (or servers) as if they were hosts, rather than processes: Most spam comes from clients, I want to eliminate it, hence I will only pull mail from servers.
Disadvantages
- Pull requires that senders and receivers all be connected to the same network all the time, which is a lot closer to true now than it was in the 1980s, but still a long way from universally true.
- MTA-pull does add a burden to both sides of legitimate transactions: keeping track of message offers that are pending a decision to pull and an actual pull attempt. In order to justify that added burden (in addition to the huge development and deployment costs).
- Asynchronous pull with positive DSNs is likely to incur in the Tumbleweed patent. It covers the idea of putting a message on a web server and sending the recipient a URL to retrieve the message. Tumbleweed enforces it very aggressively (see lawsuits list in Wikipedia.)
Proposed standards
RFC 2017, Definition of the URL MIME External-Body Access-Type, provides for MUA-pull. It is substantially similar to including an http URL in a message, except that a MUA may download the content automatically. It is to be noted that various MUAs' default settings provide for not downloading external images for privacy concerns.
RFC 2111, Content-ID and Message-ID Uniform Resource Locators, provides for embedding images in html mail messages, and also describes mid URLs to refer to external messages.
RFC 4468, Message Submission BURL Extension, provides for MSA-pull, in the SUBMIT variant of SMTP (forward without downloading.) It addresses traffic optimization by allowing the MSA to synchronously pull the message's content from IMAP URLs.
