----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "'Hector Santos'" <hsantos(_at_)santronics(_dot_)com>;
To: "'Mark C. Langston'" <mark(_at_)bitshift(_dot_)org>;
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, March 30, 2004 8:52 PM
Subject: RE: Limited scope of work
.... The point about the 2821 checks
is that if you fail them you are not going to make it to the 2822
checks, you will just be /dev/nulled.
Right. This scenario is desirable. But if I am following this group
correctly, what concerns me is what if you don't fail them at 2821. There
seems to be a new reliance on factoring in 2822, which is all fine and dandy
for post SMTP validation systems. But for SMTP, its a new product
liability that traditionally isn't part of the design.
If we had a HEAD/BODY concept in place of DATA, then its all good. But not
with the current specifications, basically what I think I am seeing here is
that there a natural assumption that all systems will behave and operate the
same way.
I would divide 3 up into 3 possible sub-cases:
3a) Both 2821 HELO and FROM are inconsistent
3b) 2821 HELO is consistent but FROM is inconsistent
3c) 2821 FROM is consistent but HELO is inconsistent
What the receiver decides to check is not relevant here, the receiver's
decision on what to check will depend on what they do with the
information,
if they are going to reject anyway lazy evaluation obviates need for test.
I agree from the standard that one that information is well defined, then we
empower developers with solutions. Current proposals are based on how SMTP
operations. With new functional specifications, new ideas will emerge. We
need to empower the SMTP developers with the new enforcement provisions -
not weak or relaxed provisions. Imo, this starts by first clarifying the
new requirements for HELO and MAIL FROM in the new functional specifications
for all software with possible a "migration timeframe statement."
Legitimate systems will adapt.
It is pretty easy to decide what to do for case 3a), the message
is rejected.
I think the treatment of cases 3b and 3c should probably be decided
by looking at some statistics. It may be a shades of grey thing, it
may simply be misconfiguration of HELO.
Great, an SMTP Expert System! <g>
Actually, the scenarios break down even futher depending on remote versus
local. :-)
I know I promise my trust analysis, but I have been busy. Lets go over this
a little if it is ok by you.
First, lets assume we have the follow:
IP = REMOTE
HELO = REMOTE
FROM = NULL
REMOTE means, it is not part of your own domain/ownership. LOCAL (used
below) means its yours, part of your domain/ownership.
and the SPF results are:
1.1 HELO->NONE FINAL->NONE
1.2 HELO->NEUTRAL FINAL->NEUTRAL
1.3 HELO->SOFTFAIL FINAL->SOFTFAIL
1.4 HELO->FAIL FINAL->FAIL
1.5 HELO->PASS FINAL->PASS
If this is the case for NULL return path, then why or how should a non-null
return path change the final result? Or should it? Would this not be
considered the base line result?
The way I see it, this would be all that is necessary if we assert that the
integrity of the LMAP topology (mail route) can not be violated (each node
on the route is trusted). Think about that for a minute because the if the
mail submission node is SPF ready, and the final destination receiver is SPF
reader then it fundamentally can only work if the middle ware are trusted.
Also, in my analysis as far as I am concern, the possible results for HELO
SPF validation should either be a NONE, PASS or FAIL. No softfail or
neatral is possible with HELO SPF lookups.
But lets put that aside for a moment.
Now lets see this possible condition:
IP = REMOTE
HELO = REMOTE
FROM = LOCAL
I am defining LOCAL to mean that the domain presented is a local or hosted
domain owned by the MTA receiver .
This provides a total 25 possible states which reduces then two 12 possible
states. I'll show you how.
Total 25 possible states:
2.1 FROM->NONE HELO->NONE NOT POSSIBLE - SPF violation
2.2 FROM->NONE HELO->NEUTRAL NOT POSSIBLE - SPF violation Spoof!
2.3 FROM->NONE HELO->SOFTFAIL NOT POSSIBLE - SPF violation Spoof!
2.4 FROM->NONE HELO->FAIL NOT POSSIBLE - SPF violation
2.5 FROM->NONE HELO->PASS NOT POSSIBLE - SPF violation
2.6 FROM->NEUTRAL HELO->NONE FINAL->SOFTFAIL? SPF violation?
2.7 FROM->NEUTRAL HELO->NEUTRAL FINAL->FAIL Spoof!
2.8 FROM->NEUTRAL HELO->SOFTFAIL FINAL->FAIL Spoof!
2.9 FROM->NEUTRAL HELO->FAIL FINAL->FAIL
2.10 FROM->NEUTRAL HELO->PASS FINAL->PASS Possible SPF spammer
2.11 FROM->SOFTFAIL HELO->NONE FINAL->SOFTFAIL? SPF violation?
2.12 FROM->SOFTFAIL HELO->NEUTRAL FINAL->FAIL Spoof!
2.13 FROM->SOFTFAIL HELO->SOFTFAIL FINAL->FAIL Spoof!
2.14 FROM->SOFTFAIL HELO->FAIL FINAL->FAIL Spoof!
2.15 FROM->SOFTFAIL HELO->PASS FINAL->PASS Possible SPF spammer
2.16 FROM->FAIL HELO->NONE FINAL->SOFTFAIL? Forwarding problem?
2.17 FROM->FAIL HELO->NEUTRAL FINAL->FAIL Spoof!
2.18 FROM->FAIL HELO->SOFTFAIL FINAL->FAIL Spoof!
2.19 FROM->FAIL HELO->FAIL FINAL->FAIL Spoof!
2.20 FROM->FAIL HELO->PASS FINAL->PASS Forwarding problem?
2.21 FROM->PASS HELO->NONE FINAL->SOFTFAIL or PASS if trusted
router
2.22 FROM->PASS HELO->NEUTRAL FINAL->FAIL Spoof!
2.23 FROM->PASS HELO->SOFTFAIL FINAL->FAIL Spoof!
2.24 FROM->PASS HELO->FAIL FINAL->FAIL spoof!
2.25 FROM->PASS HELO->PASS FINAL->PASS Possible SPF spammer
Since FROM is LOCAL and the MTA receiver is SPF compliant, scenarios 2.1 to
2.5 can be eliminated since your local domains are SPF ready and its not
possible to have a NONE result for Mail From:.
If you agree with the assertion I made above that HELO SPF can not have
NEUTRAL/SOFTFAIL results,this eliminates 2.7, 2.8, 2.12, 2.13, 2.17, 2.18,
2.22 and 2.23 resulting in 12 possible states:
Total 12 Possible States:
2.6 FROM->NEUTRAL HELO->NONE FINAL->SOFTFAIL? SPF violation?
2.9 FROM->NEUTRAL HELO->FAIL FINAL->FAIL Spoof!
2.10 FROM->NEUTRAL HELO->PASS FINAL->PASS Possible SPF spammer
2.11 FROM->SOFTFAIL HELO->NONE FINAL->SOFTFAIL? SPF violation?
2.14 FROM->SOFTFAIL HELO->FAIL FINAL->FAIL Spoof!
2.15 FROM->SOFTFAIL HELO->PASS FINAL->PASS Possible SPF spammer
2.16 FROM->FAIL HELO->NONE FINAL->SOFTFAIL? Forwarding problem?
2.19 FROM->FAIL HELO->FAIL FINAL->FAIL Spoof!
2.20 FROM->FAIL HELO->PASS FINAL->PASS Forwarding problem?
2.21 FROM->PASS HELO->NONE FINAL->SOFTFAIL or PASS if trusted
router
2.24 FROM->PASS HELO->FAIL FINAL->FAIL spoof!
2.25 FROM->PASS HELO->PASS FINAL->PASS Possible SPF spammer
So the question here is how can this happen and how much trust can you put
on these states.
If you consider the base line results (when FROM = NULL), then you can fail
all HELO->FAIL conditions with a high degree of trust:
2.9 FROM->NEUTRAL HELO->FAIL FINAL->FAIL Spoof!
2.14 FROM->SOFTFAIL HELO->FAIL FINAL->FAIL Spoof!
2.19 FROM->FAIL HELO->FAIL FINAL->FAIL Spoof!
2.24 FROM->PASS HELO->FAIL FINAL->FAIL spoof!
Now lets look at the HELO->NONE states:
2.6 FROM->NEUTRAL HELO->NONE FINAL->SOFTFAIL? SPF violation?
2.11 FROM->SOFTFAIL HELO->NONE FINAL->SOFTFAIL? SPF violation?
2.16 FROM->FAIL HELO->NONE FINAL->SOFTFAIL? Forwarding problem?
2.21 FROM->PASS HELO->NONE FINAL->SOFTFAIL or PASS if trusted
router
I think the above 4 states could also be explained as basic forwarding
problem scenarioes. I think the decision can be reinforced programmatically
by analyzing the 2822 entities, including the HOPS as I will explain below.
Now lets look at the HELO->PASS states:.
2.10 FROM->NEUTRAL HELO->PASS FINAL->PASS Possible SPF spammer
2.15 FROM->SOFTFAIL HELO->PASS FINAL->PASS Possible SPF spammer
2.20 FROM->FAIL HELO->PASS FINAL->PASS Forwarding problem?
Possible SPF spammer
2.25 FROM->PASS HELO->PASS FINAL->PASS Possible SPF spammer
State 2.20 can be explained as a obvious forwarding situation. But if the
machine SPF validated, then it should result as a PASS. However, it could
a SPF ready compliant spammer too. This is where I think we might a SPF
can be helped with a new result that says "SOFTPASS" to indicate that there
is a MIX policy situation. We have a valid SPF machine sending the mail.
That has to mean something. Again, this is where I keep saying that the
message submission and any possible route (middle ware) has to have some
level of trust, otherwise, we run into issues like this at the protocol
level. This SOFTPASS might indicate that 2822 analysis can be applied.
I think the HOPS place a big role here.
In the HELO->NONE states, this is possible as follows
via direct:
MUA--->MDA
via ISP:
MUA--->MTA--> MDA
via broken trust (MTA2) in multi-hop route:
MUA ---> MTA1 ----> MTA2 ---> MDA
Think about this for a moment.
Is MTA2 part of the MTA1 nework?
If MTA1 is assumed to be SPF compliant, and MTA2 is part of the MTA1 network
with no SPF record, then this is a bad configuration at MTA1 domain/network.
Or is MTA2 part of the MDA domain network?
If so, then this would be another SPF bad configuration.
Or is MTA2 is a completely different domain all together? I would like to
know how this can happen. An Anti-Spam Proxy Service? Could it be like a
few of my customers have stated who were concern how their TZO setup will
world with our new SPF ready software after I announce to them that they
better start studying how to get SPF DNS records setup? In this case, some
of my customers have indicated they use TZO for email sub-domains and TZO
has indicated they will not (or are not ready) to support SPF.
In any case, I think you can look at the hops. I hope this table comes out
ok.
HELO->NONE
FROM->NEUTRAL H0->NEUTRAL H1->FAIL IF HOP #1 != HELO
FROM->SOFTFAIL H0->SOFTFAIL H1->FAIL IF HOP #1 != HELO
FROM->FAIL H0->FAIL H1->APASS IF HOP #1 = HELO
FROM->PASS H0->PASS H1->APASS IF HOP #1 = HELO
HELO->PASS
FROM->NEUTRAL H0->NEUTRAL H1->APASS
FROM->SOFTFAIL H0->FAIL H1->APASS
FROM->FAIL H0->FAIL H1->FAIL
FROM->PASS H0->PASS H1->APASS
For this:
H0 is Hops = 0
H1 is Hops => 1
APASS means that authenticated pass/session was established. For hops > 1,
this would be a route, therefore most likely an authenticated session at hop
= 1.
If I haven't lost you yet, <g>, as you can see, when you look the the hops
to make some decisions here programmatically.
Remember the above for the condition where FROM domain was local which means
you have something to say in all this. When you look at the states where:
IP = REMOTE
HELO = REMOTE
FROM = REMOTE
I have not completed this complete remote entities analysis but it all
starts with 30 possible states and my initial thoughts where how in the
world can you trust any of these if you nothing to "anchor" your results
with, like as it was done in the FROM=LOCAL analysis.
The next question I have is about 2822 Sender/From. Can these be used while
ignoring the Hops?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com