Peter J. Holzer wrote:
David Nicols' DATAFIRST proposal.
Could "DATA-first mail" (DF) work ?
It could but in reality quite a lot of mail is rejected before
it even hits the DATA stage (either because none of the recipients
exists or because of checks which don't need the content (DNSBL,
Some of the checks (incl. DNSBL and SPF) are possible before RCPT,
unless you intend to apply them selectively per receiver.
If you want to get RCPT before DATA it's simple, just don't offer
"DATAFIRST". A similar idea is Hector's HEAD proposal, splitting
DATA into HEAD and BODY somehow, for folks interested to check the
"header first" (roughly as with TOP in POP3). Maybe he gave up on
it because it won't help with DKIM body hashes.
With DATAFIRST all this mail will have to be transferred only to
be rejected. I suspect that this will sharply increase the bandwidth
It should be visible in the log files of major site. If they check
more than only the size between DATA and dot, otherwise they can't
be interested to get "DATAFIRST" anyway.
What I didn't like in draft-hall-inline-dsn was the sequence of
per recipient responses after DATA matching the sequence of RCPT
before DATA. It would be more plausible if it implies PIPELINING.
Asrg mailing list