Sorry for the length of this post, but I don't want to spend the time
to make it shorter.
In <20040205013807(_dot_)GQ1323(_at_)dumbo(_dot_)pobox(_dot_)com> Meng Weng
Wong <mengwong(_at_)dumbo(_dot_)pobox(_dot_)com> writes:
I don't think the answers need to be left up to the domain owner. We
know what the domain owner wants: he wants legitimate mail to get
through and forged mail to be rejected.
Agreed.
Suppose the use case is: the domain usually sends mail from a set of
permitted IP addresses, expressed in vanilla SPF notation as "a mx".
But when the domain doesn't send mail from those IP addresses, it always
signs the mail using smime. If there is no smime signature, the mail is
forged.
Ok.
Suppose the domain expresses the above as "v=spf1 a mx smime -all".
Let's explore the space of possibilities. [big snip]
The only discrepancy between what the domain desires and what actually
happens is when a vanilla SPF MTA that does not understand "smime"
accepts the message. But it accepts it with the prepended header
Received-SPF: unknown smime
Agreed, although this will likely be the most common case for random
extentions and/or typos.
which can be processed later down by an smime-capable MUA.
True, although an smime-capable MUA can and should process it whether
there is the Received-SPF: header or not.
An SPF MTA that does understand smime will always do the right thing.
Yes.
If you believe that a domain owner does not want vanilla MTAs to accept
signed mail, then the modifier approach makes sense.
Agreed.
My question to you is, if you want vanilla MTAs to reject smime-signed
mail, why bother adding an smime declaration at all?
Because the complete email system can listen to that declaration and
decide that the result from the SPF check isn't as important as the
result from the smime check.
Instead of just the accepted/rejected status, lets list the SPF result
codes with ? meaning neutral, none and/or unknown.
Showing the SPF result is important because people may configure their
MTAs do do all sorts of things, including rejecting email that has an
SPF result of unknown/none/neutral. Their servers, their rules. Even
if their rules are brain dead, the domain owners must be aware of this
distinction.
1 0
A) SPF MTAs: smime-enabled vanilla
B) Messages: signed unsigned
C) Client IP: IP-permitted not-permitted
D) Domain desires:
E) Actual result:
"v=spf1 a mx smime -all"
A B C D E
------------------
0 0 0 - ? ** mismatch
0 0 1 + +
0 1 0 + ? ** mismatch
0 1 1 + +
1 0 0 - -
1 0 1 + +
1 1 0 + +
1 1 1 + +
"v=spf1 a mx ?all smime=required"
A B C D E
------------------
0 0 0 - ? ** mismatch
0 0 1 + +
0 1 0 + ? ** mismatch
0 1 1 + +
1 0 0 - -
1 0 1 + +
1 1 0 + +
1 1 1 + +
Note that these two tables are identical. However, using the
modifier, it clear that vanilla SPF clients will return unknown
instead of pass or fail. As noted above, some MTAs may reject on
unknown.
Now, let's consider this SPF record:
"v=spf1 a mx ipv4:1.2.3.0/24 -all"
At first glance, this looks like the SPF record should always return
either + or -, but the typo of "ipv4" instead of "ip4" means that in
some rare cases, it could return ? instead of + and in the cases of
forgery, it always returns ?. This may not be immediately obvious
because most forgeries go to people who wont notice or care that the
message doesn't have the right SPF status, it is just spam.
The mechanism usage stats that Weschler posted a while back show that
there were *FAR* more typos than "legitimate" unknown mechanisms.
So, I ask again, what does allowing unknown mechanisms really give us?
And, does that benefit outweigh the problems with typos?
Are we really talking about requiring that mail have *both* factors ---
coming from the right IP address *and* being signed? I hope we aren't.
Requiring both a passing SPF check and smime could be useful in
certain cases. Consider a rogue employee of a bank. If the employee
might be able to highjack one of the banks IP addresses and connect
his laptop up to send forged email. However, the private keys to
create an smime message would be much harder for a rogue employee to
get.
So, the bank might, to use PHB's suggested syntax, want to specify
"smime=required" to require both SPF checking and smime checking.
-wayne
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡