spf-discuss
[Top] [All Lists]

Re: Forking SPF into The New SPF and SPF1

2004-06-07 09:04:11
Stuart D. Gathman wrote:

> [snip]
>
After DATA authentication, on the other hand, will encompass a number of
cryptographic and reputation schemes, with varying PKI systems.  The
flexibility of XML is needed for this application.  An MTA validating headers,
message body, and cryptographic signatures of various types needs to be able to
reliably parse a tree of data, interpreting the systems it implements and
ignoring those it doesn't recognize.  XML is ideally suited for this.  Yes,
more bandwidth is required for the XML, but once you've commited to the DATA
phase of SMTP, gathering another few kilobytes of XML data is a reasonable
overhead.  Yes, more code bloat and complexity is required for XML - but it is
comeasurate with the kinds of header and message body signing systems being
proposed for after DATA.  As long as we keep the lightweight authentication
available before DATA, a lightweight MTA can reasonably chose to "pass" on the
heavyweight systems.  Furthermore, the after DATA XML based systems are
reasonably implemented outside of the MTA, in a MUA, LDA, milter, or post
reception filter.  (As opposed to SPFv1 which needs to be implemented in real
time during the SMTP transaction - either directly by the MTA or via a milter or similar MTA extension.)

If you do the checks in the MUA what do you win? What should be the coal? Then the coal can't be to prevent the MUA (which perhaps is connected by a slow modem) from unwanted mail. Or do I miss here something?

Teddy