From: Stuart D. Gathman
Sent: Monday, June 07, 2004 11:09 AM
<...>
Hear hear. I have no objection to the new features being proposed
for 2822 headers and message body validation. But there is no need
to kill the very useful 2821 validation provided by SPFv1. There
are two RFCs for before and after DATA headers: 2821, and 2822. Why can't
we have two RFCs for before and after DATA authentication? SPFv1 for
2821 and SPFv2/CID for 2822.
No reason we couldn't.
Once again, the 2822 functionality is useful - but does not belong in
the MTA. The code bloat from the XML, the non-trivial
cryptography, will be a
security nightmare.
I'm not sure about this one. Why does 2822 header authentication need to
use XML? Are we sure the required functionality can't be incorporated into
the SPF record, even if the test is after DATA? Unless I misunderstand what
you are proposing, this sounds like a domain owner would have to publish an
SPF record to get his 2821 envelopes accepted, then publish an XML document
to get his headers verified. Unless there's no other way to do it, that's
not very appealing.
Fortunately, that functionality does not have to be
in the MTA. Since we already committed to DATA, the complete message has
already been transferred, and external tools can apply the 2822 check.
The external tools do not even have to be real time.
But however wonderful the new 2822 features, we *still* need a lightweight
authentication protocol that works before DATA, works in real time, and
has minimal code bloat. I *already* have tools that delete junk once
I've wasted bandwidth receiving it (content filters). Sure, the 2822
header features will improve junk detection, perhaps greatly
improve it, but if
we don't block the lion's share of the junk before DATA, we are really no
better off.
Heartily agree. Rejecting before DATA should be the goal. However, when a
message passes 2821 tests, rejecting at the end of DATA, _where practical_,
is better than silently dropping the mail after accepting it. The "where
practical" is the important part. We shouldn't burden the MTA excessively
during the SMTP session, and I suspect a complicated policy in XML could
easily do that. However, that doesn't shouldn't rule out _any_ 2822 header
checks during the SMTP session. I suggest that we need to be very
selective. Hopefully, there is a subset of 2822 information that is
reasonable to check in real time and reject at least some of the junk at the
end of DATA. Maybe there isn't such a subset, but it's at least worth a
try. For the rest, I agree that SpamAssassin and its cousins do a fine job
and are happy running on the MUA. I use a purely Bayesian filter and find
it extremely effective. I don't feel like I need anything to make those
tools more effective, but I would like to reject more, even if some of it is
at the end of DATA.
--
Seth Goodman