----- Original Message ----- >
Let's keep focus here:
I'm not objecting at all to MAIL-FROM checks with SPF.
It is only the HELO checks that I object to (and even then, I agree with
the use of HELO in case of <>, but *only* in that case)
Thats illogical. A NULL return path is no different than a NON-NULL return
path.
Perhaps it would help to think about the possible combinations:
I think the PASS-PASS and FAIL-FAIL cases are obvious.
I think this table should look like this
HELO Check MAIL-FROM check what to do
PASS PASS deliver
FAIL PASS deliver
PASS FAIL reject
FAIL FAIL reject
I deliver for FAIL-PASS because even though the mail may be arriving
through a misconfigured MTA, the sender domain would want me to deliver.
No, this can be SPOOF.
Client ip: 208.247.131.9
HELO mail-eur1.microsoft.com --> FAIL
MAIL FROM: spf-discuss(_at_)winserver(_dot_)com --> PASS
You seem to GIVE the spammers more credit than they deserve and that the
above like scenerio does not happen. It does!
The only case to cause close to this is a MUA/MSA or MUA/MDA transaction
where the client domain may not be fully qualified, but in this case, the
HELO result is NONE.
You missed the 3rd state for HELO: NONE
I reject in the PASS-FAIL case, because even though the connected MTA
wants me to deliver, the sender domain wants me to reject.
Maybe yes, maybe no. The problem with your blind analysis is that
doesn't into account the entire transaction parameters.
This could be an alias problem:
MUA --> MSA ---> MDA
MSA/MDA SPF(HELO) = pass.
MSA/MDA SPF(MFROM) = fail.
In this case, I agree, this should be a failed if the MUA is using an ALIAS
from a different submission point.
But for multiple hop system, it may look like a forwarding problem:
MUA --> MSA ---> MTA ---> MDA
MUA/MSA SPF(HELO) = pass.
MUA/MSA SPF(MFROM) = pass.
So far its all good, but now we have:
MTA/MDA SPF(HELO) = pass.
MTA/MDA SPF(MFROM) = fail.
In this case, you can deem this as illogical or a fowarding problem. It all
depends on who owns that MTA. If its part of the MSA network, then it
better be SPF ready across the board. If not, then it may be a problem.
But as I indicated before, if this a multiple hop, you have a chain of trust
situation that you can include in your final analysis.
Remember for the MSA - MTA transaction to take place, it must be AUTHORIZED
using standard protocols (IP Relay Tables usually).
If this is a ROUTER at a final destination. Then the MTA is really a MDA
and it must basically white list at that point. We seen this problem in
hetergenous networks where you have two different sets of rules once the
mail reaches its final destination in the eyes of the MSA.
It's the sender domain's policy that I care about ultimately, not the
connected MTA's. The connected MTA may be under the administration of an
incompetent ISP. That should not prevent the actual vanity domain owner
to express with his SPF policy, how he would like his email treated.
Well, the inner routers MUST be trusted otherwise nothing is going to work.
Once a transaction is submittal, it is the responsibility of the NETWORK to
make sure the network is secured. If not, nothing will work. Everything is
compromised.
----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)