About signatures: Its just nomenclature. I define a "signature" as something, protocol or encoding, that can, validate the source of something with such a certainibility, so its becomes unfeasible for a attacker to forge this validation so the validation returns a genuine status. Same with for example security tokens on banks, you "sign" a transaction with a TAN code, even if the actual TAN code does not have any relationship with the transaction in question (eg it does only "authenticate" you, but still its a "signature"). So SPF can be some sort of signature, you "sign" mail with SPF by sending mail from a authorized server, and using a from of a domain that has a published SPF record. And verifying SPF signed mail is as easy as cross-checking the client IP against the SPF record.
About banks:In this case, its better to err on the safe side and display the mail as forged, if the mail does have one or more forged signatures, even if the standard says SPF validation should override DKIM and vice versa. A bank's mail shouldn't be forwarded through an "unknown" server, and if it is, then there is some misconfiguration somewhere and the mail shouldnt be trusted anyways. And no, I dont toss away forged mail. Its just that if the mail is forged, I know its forged and I cannot make any assumptions about who is the sender of the mail. If the sender is unimportant (for example, if its a newletter), I can disregard the forged status of the mail.
How is that a false sense of security? What if the bank really send out something that should be filled in? You can't know. If the source can be validated, I can easly weed out forged mai from genuine, and then act on genuine mail.
-----Ursprungligt meddelande----- From: Viktor Dukhovni
Sent: Monday, March 09, 2015 7:34 AM To: postfix-users@postfix.org Subject: Re: Reversing order when mail is local (not relayed)? On Mon, Mar 09, 2015 at 07:16:59AM +0100, Sebastian Nielsen wrote:
I understand. What I do with the SPF signature checker, is to unconditionally add a header that looks like this:X-SPF-Signature: none (dukhovni.org: No applicable sender policy available)receiver=server-desktop; identity=mailfrom; envelope-from="postfix-us...@dukhovni.org"; client-ip="2604:8d00:0:1::4"
In this case, since you got the email not from, but from the Postfix users list, the "envelope-from" is not my address. Rather it is: owner-postfix-us...@postfix.org
The idea behind this, is that the MUA, should be able to mark the email as guranteed genuine and safe to the end user, if a mail is:(SPF signed OR S/MIME Signed OR DKIM Signed), but if ANY is forged, then thewhole mail is marked as forged.
Except that SPF does not "sign" email it just checks a list of authorized relays. This check fails when email is forwarded, and forwarding of mail is not forgery. When using SPF and DKIM, the recommended practice is to accept email as genuine if either DKIM or SPF pass, even if the other fails.
Thus, if a validly signed email, regardless of method (SPF, S/MIME or DKIM)comes from my bank, I know that I can safely visit any links and enter any personal data.
Even better, never click on links in email and enter personal data. Don't get lulled into a false sense of security. Large corporations outsource email communications to all sorts of third parties, and list them in their SPF and DKIM records. --Viktor.
smime.p7s
Description: S/MIME Cryptographic Signature
