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.
- Requiring all 2822 checks to be expressed as an XML record is tantamount
to saying they must be done after the end of DATA.
- 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.
- 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.
--
Seth Goodman