Re: Reversing order when mail is local (not relayed)?

[Sebastian Nielsen]

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"

Sent: Monday, March 09, 2015 6:58 AM
To: postfix-users@postfix.org
Subject: Re: Reversing order when mail is local (not relayed)?

On Mon, Mar 09, 2015 at 05:27:21AM +0100, Sebastian Nielsen wrote:

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 the whole mail is marked as forged. 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. I think you should really publish a SPF record. Especially if you have a certain reputation that would make you target for email forgeries. Then its up to email receivers how they want to use the record. So I dont reject any email based on any signature failures, rather I use the signatures in a positive fashion to mark the email as extra validated when they pass one signature method. -----Ursprungligt meddelande----- From: Viktor Dukhovni

Did split up the OpenDKIM process into 2 instances, one running as verifier,

placed before any content modification, and one running as signer, placed
after any content modification.
I also moved the SPF signature validator to the instance before content
modification. That was not because SPF signatures has with content to do,
rather it was because the old SPF signature validator I had, was a policy
script checking against MAIL FROM. The new SPF signature validator checks
against the "From:" MIME header, which raises security, but milters do not

front" so it sees the real IP.

get access to the XFORWARD client IP, thus I had to move the milter to "the

SPF is not a signature protocol.  SPF is *supposed* to check the
envelope sender and NOT the author.  Applying spf to message headers
was SenderID which inteoperated with mailing lists by matching
"Sender" when present.  With rampant misuse of SPF records, I
neither publish nor check SPF records.

Good luck.

--

Viktor.

smime.p7s
Description: S/MIME Cryptographic Signature