On Tue, 2004-06-08 at 19:54 -0500, Seth Goodman wrote:
From: Mark Shewmaker
Sent: Tuesday, June 08, 2004 7:12 PM
On Tue, 2004-06-08 at 18:28, administrator(_at_)yellowhead(_dot_)com wrote:
The SUBMITTER document was even more informative. It doesn't
say you have
to process the RFC 2822 From: (I am dead set against processing anything
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
after DATA), although in early implementations you would
probably have to
^^^^^^^^^^^
just to get the information at times.
I do not understand *universal* objections to after-DATA processing. I
do not think it is entirely rational.
I want to second Mark's position on this. A more reasonable requirement is
to avoid doing _any_ expensive tests during the SMTP session, whether before
or after DATA. While we want to reject everything possible before DATA,
adding an inexpensive test after DATA that permits rejection at the end of
DATA is worthwhile. Expensive is a subjective term, so here's what it means
to me:
- Fetching and parsing XML records appears to be incompatible with the
real-time requirements of the SMTP session. IMHO, this is just as
undesirable during the DATA phase as before it.
With the appending and prepending of XML namespace attributes, the most
expensive part of XML is avoided being transmitted: It is merely
implied. That's a big boon, a big plus over the Caller-ID draft. The
remaining XML is a bit more verbose than SPF's syntax, though not really
much. It will only affect the cases near the edge anyway, which is
avoidable through a multiple lookup, just as in SPF. It just lowers the
bar a very few tens of characters.
XML really isn't that much of a burden. It's really surprising, and the
MARID improvements to Caller-ID have helped a lot. If you want to avoid
a full XML parser, a minimal subset for the spec will do a lot, so
that's not really an issue, either. It's about as bad as SPF in the
first place.
- Requiring all 2822 checks to be expressed as an XML record is tantamount
to saying they must be done after the end of DATA.
Well, 2822 has to be done after data by definition, though with a spec
like SUBMITTER, it can leak a very little.
- Any policy engine that operates after the end of DATA is largely a waste
of effort. Existing post-acceptance message filtering tools are extremely
effective. If we discover a forgery after accepting a message, we can't
send a DSN since the return-path is dubious so we are forced to null route
the message. Though this is clearly the lesser of two evils, it highly
undesirable.
Not really. Existing post-acceptance filtering is historically very bad
at detecting forgery, since there's no policy information to go on.
There's spam filters, but SPF and SPF-ID were never intended to be an
anti-spam measure in any direct way.
- Once a message passes 2821 tests and we allow the SMTP-client to proceed
to DATA, it is to our advantage to identify any _inexpensive_ tests that can
be done that permit us to reject at the end of DATA. We should look for
these opportunities because it is better to reject at the end of DATA than
to discover the problem later and silently drop the message.
Absolutely. Avoiding DSNs is a good thing.
Ari