----- Original Message -----
From: "Arnt Gulbrandsen" <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, March 09, 2005 7:01 AM
Subject: Re: Site policy vs. HELO
Hector Santos writes:
Like I said, there is a reason for everything. Nothing to do with
protocols or its reliability. In fact, it was a 100% trusted result.
It's just that the error message did not say so, eh?
Right. Because it was an older deprecated filtering logic that was still
active on my system.
Expecting people to report a problem (as you wrote about earlier today)
is 100% unrealistic when your error message gives them no idea of what
the problem is. Get real.
We did get real. It was a built-in decision long ago to not feed malicious
senders any information that might help them adjust.
If any problem, is that we didn't log it on the server-side and that was
because it was a deprecated filtering feature.
The new system does log it on the server-side. That is what made this whole
thing strange.
Bruce could of easily reported back in Oct 2004, "Yo hector, my mail is
being rejected."
He would of found out early on he was twitted. No, he tried to prove "some
point" here in public with no real agenda.
The fact is he knew this. He knew he was being blocked via WCSMTP because
at the same date Oct 27, he tried out the TESTWCSAP directly and saw that he
passed the test.
The facts are if a site is experiencing problems with it users, they will
investigate it. They don't want to run a poor system any more than you and I
do. This is a increasingly on going issue as more and more of the "layman"
is putting their trust in a working system. We just solved a big one
yesterday which illustrated alot of whats going on.
Customer has an user that switches between the ISP's user email account and
the user's aol.com account.
The user's transactions using his AOL.COM were accepted.
The user's transactions using the ISP's domain were rejected.
In both cases, the user was sending mail via AOL's machines.
AOL.COM has a SPF record.
WCSAP accepted the AOL.COM sender transacton as SPF pass.
When the user used the ISP's domain, WCSAP softfailed the query, and for
some reason rejected the transaction.
Technically, SPF says to accept softfail results.
I deem this a big security flaw in SPF and said so from the beginning.
WCSAP has an optional setting that addresses this:
; SPF can return low trust results. A pass means the sender has
; a valid SPF record and is accepted. Softfail and Neutral means
; no match is found but rejection is not automatic. Setting a
; true accept can provide a loophole for potential spoofers who have
; SPF records and think they will allow them in. The options
; below allow you to control this.
Accept-SPF-Pass True ; if false, continue testing
Accept-SPF-SoftFail False ; if false, continue testing
Accept-SPF-Neutral False ; if false, continue testing
So by default, we reject the SOFTFAIL.
Well, why wasn't a big issue in the pass?
Well, because WCSAP is a suite of testing where a CBV is the final test
done.
WIth the option above set to false, wcSAP will continue testing. But he had
turned off CBV, so therefore the final result was a rejection.
If we followed the SPF rule, than we just open up the door to SPF relaxed
provisions exploitation. We don't need any more relaxed provisions. That is
what caused the problem at SMTP in the first place.
By turned on CBV, the user would of been vailidated against his own system,
thus the problem is solved.
Another issue about SPF was its other loophole of not having a provision to
check for HELO/EHLO domains unlike earlier LMAP proposals. I argued for for
it and I believe it has been finally been put in. It was always left as an
"option" with a recommendation that it was a redundant overhead therefore it
shouldn't be done. That thinking has changed.
We have yet to update to this current SPF logic, but we have it built in for
Local Domain Spoof checking which is a compromise of having an open-ended
SPF HELO check.
Assuming we have this implemented, here is the transaction parameters for
the rejection:
Client IP address: 64.12.138.7
Client Machine Name: rly-ip03.mx.aol.com
From (Return Path): highjacker(_at_)skyhawkbbs(_dot_)com
The SPF lookup for skyhawkbbs.com (he has since changed it to a hard fail),
but he had a soft fail yesterday.
With the new SPF logic, it allows for a HELO SPF check.
Go ahead do all the DNS lookups you can on that AOL client domain. SPF,
PTR, A whatever, it all fails.
This is why will keep it as a Local Domain Check only as this is the only
thing you can rely on. You can't trust the result of a HELO domain DNS
lookup.
The SUBMITTER proposal have promise. That would of worked here too. Our
system at this time is SUBMITTER ready for the INBOUND side.
It has privacy security issues It sends the entire address, when SPF only
needs the DOMAIN.
So if the AOL client send:
mail from: <highjacker(_at_)skyhawkbbs(_dot_)com> submitter=aol.com
It woud would of solved this forwarding problem.
AOL could of done some ridiculous sender rewriting scheme too.
But today, the solution here was turn on the CBV and to give the customer a
side of white listing rules to emulate a proper SPF lookup test:
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
152.163.225.0/24
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
205.188.139.0/24
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
205.188.144.0/24
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
205.188.156.0/24
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
205.188.159.0/24
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
64.12.136.0/24
Accept if %RP% in highjacker(_at_)skyhawkbbs(_dot_)com and %CIP% in
64.12.138.0/24
All this is par for the course and I goal is teach the customer enough to
have them do this themselves.
Could SMTP + some methodology solve this?
Dave and Doug has CSV/DNA. They think it will work.
Not in this case, AOL must support to.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office