----- Original Message -----
From: "David Mayne" <dmayne(_at_)corp(_dot_)earthlink(_dot_)net>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Monday, April 05, 2004 4:19 PM
Subject: Re: plan for april 5th xmpp conference...
Are best left to digital signing technology independent of the IP/MTA
identity/authorization.
I am starting to agree that a good starting point for IP/MTA
authorization for this working group should involve HELO/EHLO checking,
and leave MAIL FROM, RFC(2)822 headers out of the discussion.
I agree with a strong HELO/EHLO checking.
However, based on my work, strict MAIL FROM enforcement policies is not an
issue for compliant and legitimate systems. Only abusers will have a
problem with a new enforcement policy.
The problem is "HOW" to do the MAIL FROM validation.
I said, we make the functional specs open-ended (as it is now for this
specific MAIL FROM concept) for future MAIL FROM validation possibilities.
However, what we need to get clear to everyone that it needs to be "correct"
and "verifiable" and once this is written in stone, the "validation" methods
will come.
Until a better technology is available, we use a CBV (call back verifier) as
a final test.
What we need to remember here with a CBV, is that we are looking for a
"rejection" as that is where the reliable trust in the result is achieved.
If a remote system returns "OK" well, there is nothing you can do any more
at this point. You can't trust this result, but you can't make a decision
on it either other than "let it thru."
But one thing I have learned, in reality, you will get a high rejection
rate. The MAIL FROM spoofing is split between:
a) bad domain (NXDOMAIN)
b) spoofed good domain, bad user part
c) spoofed good domain, good user part (the latest generation)
and what is the beauty of all this, when you combine a suite of testing
methods, the CBV will catch A and B and C can be caught by LMAP and/or
local domain spoof protection.
Our SMTP protocol level validation testing rejection breakdown result is:
FILTER (Accept/Reject Rules) : 12%
RBL (Accreditation Test): 75%
SPF (Domain Policy Test): 0% (negligible)
CBV (Return Path Test): 13%
Are you surprise the SPF is negligible? This is why I say, if you do SPF
records, you are need to do so with the understanding that the benefits are
mostly gained for local domain spoof protection. The 12% above is because
we do the local domain/ip check in the Accept/Reject rules for fast
processing. If we removed the rules, our SPF domain records would of caught
them as well. So I would say that SPF is providing us 12% rejection nearly
~100% based on local domain spoofing.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com