You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by user321 <ma...@gmail.com> on 2019/05/03 13:55:40 UTC
SPF
Any reason why SA is checking for SPF against envelope from not the header
from?
I am rejecting the SPF_FAIL e-mails on Postfix (-all only), but still
spammers can forge the header from field.
Can I change SPF plugin to work with header from? If yes how?
What are the pros and cons of that?
cheers
user
--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html
Re: SPF
Posted by David Jones <dj...@ena.com>.
On 5/3/19 9:47 AM, RW wrote:
> On Fri, 3 May 2019 06:55:40 -0700 (MST)
> user321 wrote:
>
>> Any reason why SA is checking for SPF against envelope from not the
>> header from?
>
See the SPF link on this page:
https://blog.returnpath.com/how-to-explain-dmarc-in-plain-english/
> Because that's how SPF works.
>
>> I am rejecting the SPF_FAIL e-mails on Postfix (-all only), but still
>> spammers can forge the header from field.
>> Can I change SPF plugin to work with header from? If yes how?
>> What are the pros and cons of that?
>
> Generally you don't want to enforcing a modified standard that no one
> else knows about.
>
> DMARC solves the problem by requiring that for a DMARC pass from SPF
> the envelope address has to be aligned with the from header address.
>
FYI,
If opendmarc is setup in your MTA with local SA rules...
DMARC_PASS = SPF_PASS and From: domain aligns with envelope-domain
_OR_ DKIM_VALID_AU (DKIM_SIGNED and aligns with the From: domain)
I am rejecting DMARC failures of incoming domains with p=reject within
opendmarc then have these rules in SA:
(change the rule below to match your header in opendmarc.conf)
header DMARC_PASS Authentication-Results =~ /smtp\.ena\.net; dmarc=pass/
describe DMARC_PASS DMARC check passed
score DMARC_PASS 0.001
header DMARC_FAIL Authentication-Results =~ /smtp\.ena\.net; dmarc=fail/
describe DMARC_FAIL DMARC check failed
score DMARC_FAIL 0.001
header DMARC_NONE Authentication-Results =~ /smtp\.ena\.net; dmarc=none/
describe DMARC_NONE DMARC check neutral
score DMARC_NONE 0.001
--
David Jones
Re: SPF
Posted by RW <rw...@googlemail.com>.
On Fri, 3 May 2019 06:55:40 -0700 (MST)
user321 wrote:
> Any reason why SA is checking for SPF against envelope from not the
> header from?
Because that's how SPF works.
> I am rejecting the SPF_FAIL e-mails on Postfix (-all only), but still
> spammers can forge the header from field.
> Can I change SPF plugin to work with header from? If yes how?
> What are the pros and cons of that?
Generally you don't want to enforcing a modified standard that no one
else knows about.
DMARC solves the problem by requiring that for a DMARC pass from SPF
the envelope address has to be aligned with the from header address.
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 11:41 PM, Bill Cole wrote:
> This is all true of any authentication mechanism: if control of
> authenticating credentials is lost, the authentication is worthless.
Agreed.
> For example, if someone can control the DNS for tnetconsulting.net,
> they can very likely get Comodo to reissue your S/MIME cert and send
> it to them instead of you. At that point they can sign mail as you in a
> manner that normally would be seen as more robust and more reliable than
> DKIM.
Yep.
Hence the repudiation comment.
I'm afraid that our industry is painting themselves into a corner and we
may not realize it until it's too late.
"Jury of peers" is going to be more and more problematic. Not only will
it need to be peers that understand the technologies in play, but peers
that understand the ramifications of the weird failure modes.
> BUT: you have an advantage over many victims of DNS compromise in that
> tnetconsulting.net has implemented DNSSEC.
}:-)
As long as they only compromise my DNS and /don't/ compromise my
registrar, things should be relatively okay. At least in that there is
a higher authority that can be used to correct things top down.
My understanding is that DNSpionage & Sea Turtle did compromise things
at the registrar level. As such, they can alter the DS records and even
overcome DNSSEC.
> Also, DKIM is potentially less vulnerable to DNS compromise than
> PKI-reliant X.509 certificates (which DNSpionage & Sea Turtle target)
> because the protocol is designed to support short-lived keys distributed
> over DNSSEC so that a compromise of DNS needs to be persistent and
> stealthy to live longer than a signed TXT record.
Sure. Smaller exposure window.
--
Grant. . . .
unix || die
Re: SPF
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 4 May 2019, at 0:48, Grant Taylor wrote:
> On 5/3/19 5:51 PM, Kevin A. McGrail wrote:
>> If your key is compromised, generate another and publish it on DNS.
>
> That requires knowing that the key is compromised.
>
> It really helps to know that an APT is going on to know that your key has been compromised.
>
> The point being there are reasonable circumstances that someone else can DKIM sign messages as a victim.
This is all true of any authentication mechanism: if control of authenticating credentials is lost, the authentication is worthless.
For example, if someone can control the DNS for tnetconsulting.net, they can very likely get Comodo to reissue your S/MIME cert and send it to them instead of you. At that point they can sign mail as you in a manner that normally would be seen as more robust and more reliable than DKIM. BUT: you have an advantage over many victims of DNS compromise in that tnetconsulting.net has implemented DNSSEC.
Also, DKIM is potentially less vulnerable to DNS compromise than PKI-reliant X.509 certificates (which DNSpionage & Sea Turtle target) because the protocol is designed to support short-lived keys distributed over DNSSEC so that a compromise of DNS needs to be persistent and stealthy to live longer than a signed TXT record.
Re: SPF
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 5/4/2019 12:48 AM, Grant Taylor wrote:
> The point being there are reasonable circumstances that someone else
> can DKIM sign messages as a victim.
Sure, your entire server can be compromised and there might be a mole in
the ministry.
Your premise started out with the From Header versus Envelope for SPF
and now has moved into DKIM being insecure if you don't maintain control
of your PKI security.
What is your point?
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 5:51 PM, Kevin A. McGrail wrote:
> If your key is compromised, generate another and publish it on DNS.
That requires knowing that the key is compromised.
It really helps to know that an APT is going on to know that your key
has been compromised.
The point being there are reasonable circumstances that someone else can
DKIM sign messages as a victim.
--
Grant. . . .
unix || die
Re: SPF
Posted by "Kevin A. McGrail" <km...@apache.org>.
If your key is compromised, generate another and publish it on DNS.
On Fri, May 3, 2019, 19:43 Grant Taylor <gt...@tnetconsulting.net> wrote:
> On 5/3/19 5:10 PM, Kevin A. McGrail wrote:
> > I guess if you lose control of your keys and/or your DNS is compromised,
> > then yes, you have a DKIM issue.
>
> This brings up a non-repudiation issue introduced by DKIM.
>
> How can you successfully refute a DKIM-Signature if someone has your
> signing keys.
>
> My quick skim of parts of RFC 6376 makes me think that it is dangerous
> and discouraged to associate authentication based on DKIM-Signature,
> even when the d= SDID (?) matches the From: header.
>
> Yet even more reason to reread RFC 6376 before replying to Bill's email.
>
> Presently I'm comfortable in thinking that DKIM-Signature validation
> meaning that the message has not changed in transit. I'm not (yet)
> comfortable drawing any conclusions about authentication.
>
>
>
> --
> Grant. . . .
> unix || die
>
>
Re: SPF
Posted by David Jones <dj...@ena.com>.
On 5/3/19 6:26 PM, Grant Taylor wrote:
> On 5/3/19 5:10 PM, Kevin A. McGrail wrote:
>> I guess if you lose control of your keys and/or your DNS is
>> compromised, then yes, you have a DKIM issue.
>
> This brings up a non-repudiation issue introduced by DKIM.
>
This is similar to saying not to use HTTPS because there's a possibility
that the web server's certificate private keys and DNS might be
compromised so I am safer with plain HTTP. If the DKIM signature aligns
with the From: header domain and is valid, DKIM_VALID_AU means you know
the source of the email and that is was not modified. If the DKIM
signature is any other domain, then it doesn't mean much from a spam/ham
perspecitive which is why DKIM_VALID has a tiny default value.
> How can you successfully refute a DKIM-Signature if someone has your
> signing keys.
>
DKIM is only one of dozens of tools in the spam-fighting tool bag. I
use it in very specific cases when DKIM_VALID_AU rules hit or I use it
in meta rules so that other conditions have to also be true.
> My quick skim of parts of RFC 6376 makes me think that it is dangerous
> and discouraged to associate authentication based on DKIM-Signature,
> even when the d= SDID (?) matches the From: header.
>
I have been using SPF, DKIM, and DMARC for years now in specific meta
rules based on patterns noticed in the mail flow through smtp.ena.net
and it has worked pretty well.
1. Carefully whitelist_auth primary domains with user/human mailboxes
since they can be compromised. Some cases are worth the risk for
difficult partners like legal, HR, financial, etc. with content that
looks spammy and can hit high Bayes scores.
2. Whitelist_auth subdomains of primary domains are usually safe for
systems-generated emails and mailing lists (whitelist_auth *.apache.org)
> Yet even more reason to reread RFC 6376 before replying to Bill's email.
>
> Presently I'm comfortable in thinking that DKIM-Signature validation
> meaning that the message has not changed in transit. I'm not (yet)
> comfortable drawing any conclusions about authentication.
>
Analyze your email based on DKIM_VALID_AU hits and look for patterns.
Based on your definition of spam vs UCE vs ham. If there is enough
volume, you should see how DKIM_VALID_AU and DMARC can enhance/extend
SPF accuracy which was your original question.
--
David Jones
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 5:10 PM, Kevin A. McGrail wrote:
> I guess if you lose control of your keys and/or your DNS is compromised,
> then yes, you have a DKIM issue.
This brings up a non-repudiation issue introduced by DKIM.
How can you successfully refute a DKIM-Signature if someone has your
signing keys.
My quick skim of parts of RFC 6376 makes me think that it is dangerous
and discouraged to associate authentication based on DKIM-Signature,
even when the d= SDID (?) matches the From: header.
Yet even more reason to reread RFC 6376 before replying to Bill's email.
Presently I'm comfortable in thinking that DKIM-Signature validation
meaning that the message has not changed in transit. I'm not (yet)
comfortable drawing any conclusions about authentication.
--
Grant. . . .
unix || die
Re: SPF
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 5/3/2019 6:53 PM, Grant Taylor wrote:
> On 5/3/19 4:47 PM, Kevin A. McGrail wrote:
>> Unless you have the private key matching the public key in DNS of a
>> domain, that's the benefit of a DKIM signature.
>
> I was referring to exactly that.
>
I guess if you lose control of your keys and/or your DNS is compromised,
then yes, you have a DKIM issue.
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 4:47 PM, Kevin A. McGrail wrote:
> Unless you have the private key matching the public key in
> DNS of a domain, that's the benefit of a DKIM signature.
I was referring to exactly that.
As in the real ena.com being compromised and attackers taking a copy of
their private key.
See recent reports of DNSpionage and Sea Turtle. (Cisco Talos)
There's also the fact that DNSpionage attackers can modify the contents
of DNS to fit their needs.
--
Grant. . . .
unix || die
Re: SPF
Posted by "Kevin A. McGrail" <km...@apache.org>.
On 5/3/2019 6:40 PM, Grant Taylor wrote:
> I think that I could sign as d=ena.com if I had access to their keys.
> Which obviously I / my server should not.
>
> I need to reread if there is any protection in DKIM to detect such
> malicious use of the spoofed domain's keys. My current understanding
> is that there is not any such protection in DKIM.
Unless you have the private key matching the public key in DNS of a
domain, that's the benefit of a DKIM signature. You might want to read
more about asymmetric crypto:
https://en.wikipedia.org/wiki/Public-key_cryptography
Regards,
KAM
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 4:35 PM, RW wrote:
> But if you sign it with d=ena.com it wont pass as valid, unless you have
> also gained control of the DNS for ena.com.
I was referring to signing it with d=tnetconsulting.net.
I need to reread RFC 6376 to comment further. But at this point, I
think that I could sign as d=ena.com if I had access to their keys.
Which obviously I / my server should not.
I need to reread if there is any protection in DKIM to detect such
malicious use of the spoofed domain's keys. My current understanding is
that there is not any such protection in DKIM.
--
Grant. . . .
unix || die
Re: SPF
Posted by RW <rw...@googlemail.com>.
On Fri, 3 May 2019 13:28:00 -0600
Grant Taylor wrote:
> On 5/3/19 11:53 AM, David Jones wrote:
> > Not completely true as long as domain/DNS control is not
> > compromised.
>
> How is it not completely true?
>
> My server can apply a DKIM signature to an outgoing email with a
> From: header of djones@ena.com.
But if you sign it with d=ena.com it wont pass as valid, unless you
have also gained control of the DNS for ena.com.
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 11:53 AM, David Jones wrote:
> Not completely true as long as domain/DNS control is not compromised.
How is it not completely true?
My server can apply a DKIM signature to an outgoing email with a From:
header of djones@ena.com.
Nothing about my server's DKIM signature verifies the contents of the
From: header is accurate.
> Technically this is correct but the fact that it's signed and matches
> the author's domain in the From: header provides authenticity of the
> origin of the email. In SA rules this would be DKIM_VALID_AU hits.
No it does not.
First, you have introduced an additional requirement that the signature
matches the author's domain. This is not a requirement of DKIM.
Second, it's (hypothetically) possible for me to get an account on the
ena.com email server and send email as djones@ with a signature matching
the ena.com domain. But such message is decidedly not from you. Ergo,
DKIM does nothing to verify the authenticity of what was signed.
> For example, Microsoft signs customer emails using the tenant's subdomain
> under onmicrosoft.com. All this confirms is the email came from the
> Office 365 platform with the original content unmodified.
It only confirms that the content is unmodified after the DKIM signature
is applied. DKIM does nothing for any part of email before the DKIM
signature is applied.
Microsoft could modify the message before they apply the signature.
> Since it doesn't align with the From: domain, DKIM really means nothing
> from a forged/spoofed (negative) perspective. DKIM can prove the positive
> that it was not forged/spoofed when it aligns and hits DKIM_VALID_AU.
See above about signatures matching domains.
I really don't think there is any part of the DKIM specification that
matters if the signing domain matches the purported sending domain.
There are other things that deduce things from that information. But to
the best of my knowledge, they are outside of the DKIM specification.
Please point to something for me to read if you think I'm wrong.
> I am not completely clear on ARC but I though it's objective is to provide
> a "chain of custody" as email goes through mail servers so receiving mail
> servers can authenticate the origin. I was thinking it's something like
> a combination of SPF (validation) and DKIM (authentication).
My understanding is that ARC primarily provides a way for a server to
state "This is who I received the message from, with these parameters."
Then if down stream servers trust the ARC signer, they can apply their
own (SPF) processing using the asserted information from the trusted ARC
signer.
--
Grant. . . .
unix || die
Re: SPF
Posted by David Jones <dj...@ena.com>.
On 5/3/19 11:30 AM, Grant Taylor wrote:
> On 5/3/19 9:48 AM, Bill Cole wrote:
>> An entirely different mechanism (DKIM) exists to verify From headers.
>
> DKIM is only positive confirmation that the (signed) headers (and body
> content) has not changed since the signature was applied.
>
Not completely true as long as domain/DNS control is not compromised.
> DKIM does nothing to verify the authenticity of what was signed (at the
> time it was signed).
>
Technically this is correct but the fact that it's signed and matches
the author's domain in the From: header provides authenticity of the
origin of the email. In SA rules this would be DKIM_VALID_AU hits.
For example, Microsoft signs customer emails using the tenant's
subdomain under onmicrosoft.com. All this confirms is the email came
from the Office 365 platform with the original content unmodified.
Since it doesn't align with the From: domain, DKIM really means nothing
from a forged/spoofed (negative) perspective. DKIM can prove the
positive that it was not forged/spoofed when it aligns and hits
DKIM_VALID_AU.
> ARC (not DMARC) is a similar signature of what comes in to detect
> modification down stream.
>
I am not completely clear on ARC but I though it's objective is to
provide a "chain of custody" as email goes through mail servers so
receiving mail servers can authenticate the origin. I was thinking it's
something like a combination of SPF (validation) and DKIM (authentication).
--
David Jones
Re: SPF
Posted by RW <rw...@googlemail.com>.
On Mon, 6 May 2019 15:10:07 -0600
Grant Taylor wrote:
> Many university IT departments claim responsibility for what the
> university's staff and students do while decidedly NOT authenticating
> anyone.
DKIM author domain signing provides strong authentication where it
matters, which is where the domain owner cares. For well-known
addresses it's merely a matter of putting them on a separate domain or
sub-domain from user accounts.
If a university server accepts spoofed submissions then they clearly
don't care that one user can spoof another.
Re: SPF
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 6 May 2019, at 17:10, Grant Taylor wrote:
> On 5/3/19 2:02 PM, Bill Cole wrote:
>> If the signer domain and the From header domain match, a valid DKIM signature that includes the From header is authentication of the From header to the limits of DNS trustworthiness and trust in the integrity of the domain's authority.
>
> Which section of RFC 6376 supports this statement?
The parts that use the word "domain."
There is a basic premise grounded in the the definition of domain names and buttressed by the use of domain names in effectively everything else that domains have a unitary executive: that the entity which publishes a public key in a DKIM record, the entity that signs mail with the corresponding private key, and the entity that controls the email local-part namespace for the domain are all one entity, as far as the world is concerned.
> I just re-read large chunks of RFC 6376 and see verbiage that states the opposite. All of which seem to me to specifically avoid drawing any conclusion about the authorship of a message within the context of DKIM. Further, such conclusions are left to other things making policy decisions based on DKIM results.
>
> | § 3.11 - Relationship between SDID and AUID
> |
> | INFORMATIVE DISCUSSION: This document does not require the value
> | of the SDID or AUID to match an identifier in any other message
> | header field.
>
> DKIM does not require SDID or AUID to match any other header field. As such, DKIM itself can't be relied upon as authentication of other header fields.
Non sequitur.
DKIM itself does not require any sort of match. It is entirely valid for a signer to sign with a key whose domain is unrelated to any domain in the message or its envelope.
However, in ALL cases the DKIM signer is claiming responsibility for the message being signed. What that claim is worth in all cases is not specified by DKIM. In a special case (DKIM signer domain = From address domain) the conceptual nature of the DNS implies that the claim of responsibility is de facto authentication.
> | This requirement is, instead, an Assessor policy issue.
>
> Per § 2.7, the Identity Assessor "consumed DKIM's payload" which tells me that it is not part of DKIM. I believe that "Other DKIM (and non-DKIM) values can also be used by the Identity Assessor…." supports the fact that the Identity Assessor is external to DKIM.
Yes.
This does not mean that it does not exist or that it doesn't need to follow some basic rules.
SpamAssassin has a DKIM_VALID_AU rule because a basic rule it understands about assessing identity is that a domain signer should know whether a From in its domain is valid.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 2:02 PM, Bill Cole wrote:
> If the signer domain and the From header domain match, a valid DKIM
> signature that includes the From header is authentication of the From
> header to the limits of DNS trustworthiness and trust in the integrity
> of the domain's authority.
Which section of RFC 6376 supports this statement?
I just re-read large chunks of RFC 6376 and see verbiage that states the
opposite. All of which seem to me to specifically avoid drawing any
conclusion about the authorship of a message within the context of DKIM.
Further, such conclusions are left to other things making policy
decisions based on DKIM results.
| § 3.11 - Relationship between SDID and AUID
|
| INFORMATIVE DISCUSSION: This document does not require the value
| of the SDID or AUID to match an identifier in any other message
| header field.
DKIM does not require SDID or AUID to match any other header field. As
such, DKIM itself can't be relied upon as authentication of other header
fields.
| This requirement is, instead, an Assessor policy issue.
Per § 2.7, the Identity Assessor "consumed DKIM's payload" which tells
me that it is not part of DKIM. I believe that "Other DKIM (and
non-DKIM) values can also be used by the Identity Assessor…." supports
the fact that the Identity Assessor is external to DKIM.
| The purpose of such a linkage would be to authenticate the value in
| that other header field. This, in turn, is the basis for applying a
| trust assessment based on the identifier value.
Sounds like the job of the Identity Assessor to me.
| Trust is a broad and complex topic, and trust mechanisms are subject
| to highly creative attacks. The real-world efficacy of any but the
| most basic bindings between the SDID or AUID and other identities is
| not well established, nor is its vulnerability to subversion by an
| attacker.
Sounds like the DKIM spec is specifically trying to avoid a tricky issue
and instead sticking to the simpler verifiable facts of has the message
been modified since it was signed.
| Hence, reliance on the use of such bindings should be strictly
| limited. In particular, it is not at all clear to what extent a
| typical end-user recipient can rely on any assurances that might be
| made by successful use of the SDID or AUID.
Sound to me like RFC 6376 is not even willing to loosely assert any
relationship between the SDID / AUID / other headers.
To me, RFC 6376 goes out of it's way to avoid that conclusion and avoids
asserting any authentication of the From: header.
> This is authentication analogous to the authentication of the envelope
> sender provided by SPF.
I can't even agree to that.
I agree that SPF authenticates that a server is authorized to send an
email purporting to be from an address in a domain that it's authorized
to send email on behalf of. But that does not extend to anything about
the sending address, much less actual author of the message.
> Email has an implicit trust that domains have a unitary executive,
> so we assume that a signer for a domain is not spoofable.
I concede that a server (SPF) / signer (DKIM) is authorized to send
email on behalf of a domain.
I don't agree that the trust in the server extends into any statements
about the authorship of a message.
> Well, I know that the entity in control of DKIM signing for
> tnetconsulting.net was willing to claim responsibility for the message
> to which I am responding.
Willingness to accept responsibility for a message does not directly
translate to vouching for it's authorship.
> If the entity in control of DKIM signing for tnetconsulting.net is not
> an authoritative judge of "authenticity" (whatever that means... )
The "whatever that means" is EXTREMELY germane in this context.
> for mail claiming to be from gtaylor@tnetconsulting.net at the signing
> point, there is no way for me to detect that.
You have no way to know what, if any, authentication was done by the
signing server.
As such, I believe the only safe thing that can be done is to assume
that no authentication was done.
> If the entity in control of DKIM signing for tnetconsulting.net chooses
> to sign mail claiming to be from an address in some other domain, there
> is no discernible reason to deem that to be authentication,
I believe this should be the behavior for all DKIM signature verification.
As outlined above, there is no guarantee that the SDID / AUID / From (et
al.) headers correlate, much less actually authenticate.
RFC 6376 states the following in § 8.3.
| A more secure architecture involves sending messages through an
| outgoing MTA that can authenticate the submitter using existing
| techniques (e.g., SMTP Authentication),
Submitter ≠ Author
| possibly validate the message itself (e.g., verify that the header is
| legitimate and that the content passes a spam content check),
"legitimate" is rather nebulous. Is it as simple as making sure that it
is an email address? Any email address? Or does it mean that there is
correlation check between the email address and the credentials used to
authenticate?
Many of the MSAs that I've run across over the years don't do any form
of correlation between SMTP AUTH credentials and the email address used.
One notable exception that I'm aware of is that Gmail used to do so.
I'm confident that there are more examples of both types of MSAs.
| and sign the message using a key appropriate for the submitter
| address.
I wonder how many signers actually use something other than the default
value of i= and specify something more specific.
| Such an MTA can also apply controls on the volume of outgoing mail
| each user is permitted to originate in order to further limit the
| ability of malware to generate bulk email.
I think I've seen this being done. However IMHO it's not directly
related to DKIM.
> although it is still (according to the RFC) a claim of responsibility for
> that mail by the entity in control of DKIM signing for tnetconsulting.net.
"claiming responsibility for" ≠ "authenticating"
Many university IT departments claim responsibility for what the
university's staff and students do while decidedly NOT authenticating
anyone. Think NATed internet connections.
> So as Dave said: DKIM_VALID_AU has authentication value where DKIM_VALID
> alone has none unless you have some reason to trust the signer.
I still don't buy that as part of the DKIM specification.
I will concede if SpamAssassin is functioning as the Identity Assessor,
which as previously stated is decidedly outside of DKIM as specified by
RFC 6376.
> DMARC is not a signature. It is a statement of policy recommendations
> for how to assess and handle messages which purport to be from a domain
> but either fail SPF checking or DKIM validation *and alignment with From*
>
> ARC is a totally different thing, authenticating chain-of-custody.
Agreed on both accounts.
--
Grant. . . .
unix || die
Re: SPF
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 3 May 2019, at 12:30, Grant Taylor wrote:
> On 5/3/19 9:48 AM, Bill Cole wrote:
>> An entirely different mechanism (DKIM) exists to verify From headers.
>
> DKIM is only positive confirmation that the (signed) headers (and body content) has not changed since the signature was applied.
RFC6376:
1. Introduction
DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name [RFC1034] with the message [RFC5322], which
they are authorized to use.
If the signer domain and the From header domain match, a valid DKIM signature that includes the From header is authentication of the From header to the limits of DNS trustworthiness and trust in the integrity of the domain's authority. This is authentication analogous to the authentication of the envelope sender provided by SPF. Email has an implicit trust that domains have a unitary executive, so we assume that a signer for a domain is not spoofable.
> DKIM does nothing to verify the authenticity of what was signed (at the time it was signed).
Well, I know that the entity in control of DKIM signing for tnetconsulting.net was willing to claim responsibility for the message to which I am responding which claims to be from gtaylor@tnetconsulting.net which was substantially unchanged between the signing point and my mail server. If the entity in control of DKIM signing for tnetconsulting.net is not an authoritative judge of "authenticity" (whatever that means... ) for mail claiming to be from gtaylor@tnetconsulting.net at the signing point, there is no way for me to detect that.
If the entity in control of DKIM signing for tnetconsulting.net chooses to sign mail claiming to be from an address in some other domain, there is no discernible reason to deem that to be authentication, although it is still (according to the RFC) a claim of responsibility for that mail by the entity in control of DKIM signing for tnetconsulting.net.
So as Dave said: DKIM_VALID_AU has authentication value where DKIM_VALID alone has none unless you have some reason to trust the signer.
> ARC (not DMARC) is a similar signature of what comes in to detect modification down stream.
DMARC is not a signature. It is a statement of policy recommendations for how to assess and handle messages which purport to be from a domain but either fail SPF checking or DKIM validation *and alignment with From*
ARC is a totally different thing, authenticating chain-of-custody.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Re: SPF
Posted by Grant Taylor <gt...@tnetconsulting.net>.
On 5/3/19 9:48 AM, Bill Cole wrote:
> An entirely different mechanism (DKIM) exists to verify From headers.
DKIM is only positive confirmation that the (signed) headers (and body
content) has not changed since the signature was applied.
DKIM does nothing to verify the authenticity of what was signed (at the
time it was signed).
ARC (not DMARC) is a similar signature of what comes in to detect
modification down stream.
--
Grant. . . .
unix || die
Re: SPF
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 3 May 2019, at 11:24, user321 wrote:
> But I have a feeling this would be extremely effective in dealing with
> spoofed emails.
Your "feeling" is not consistent with known facts. For example: messages
sent to this mailing list and most other mailing lists would fail a SPF
test using the From header.
Most importantly, SPF records are constructed and published with the
understanding that they primarily relate to the SMTP envelope sender
domain and less frequently to the HELO domain. An entirely different
mechanism (DKIM) exists to verify From headers. There is also DMARC,
which adds a layer of failure handling and reporting policy on top of
the authentication provided by DMARC and SPF.
> They are often having borderline score around the blocking
> point, so that kind of rule with relatively low score could be the
> last
> straw on the camel's back, don't you agree?
No. It would predominantly match valid mail when used for mail aimed at
normal users (i.e. not spamtraps or role accounts.)
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
Re: SPF
Posted by Daniele Duca <du...@staff.spin.it>.
Take your email in example:
envelope from:
users-return-120376-duca=staff.spin.it@spamassassin.apache.org
body from: majk81@gmail.com
SPF for gmail.com: v=spf1 redirect=_spf.google.com
You see that in case of mailing lists (and ESPs and possibly every other
VERP case) a check on the body from would fail even if the original
sender intended to send that email.
Daniele
On 03/05/19 17:24, user321 wrote:
> But I have a feeling this would be extremely effective in dealing with
> spoofed emails. They are often having borderline score around the blocking
> point, so that kind of rule with relatively low score could be the last
> straw on the camel's back, don't you agree?
>
> cheers
> user321
>
>
>
> --
> Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html
Re: SPF
Posted by user321 <ma...@gmail.com>.
But I have a feeling this would be extremely effective in dealing with
spoofed emails. They are often having borderline score around the blocking
point, so that kind of rule with relatively low score could be the last
straw on the camel's back, don't you agree?
cheers
user321
--
Sent from: http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html
Re: SPF
Posted by Christian Grunfeld <ch...@gmail.com>.
El vie., 3 may. 2019 a las 11:13, user321 (<ma...@gmail.com>) escribió:
> Any reason why SA is checking for SPF against envelope from not the header
> from?
>
> This is what SPF is made for
>
> cheers
> user
>
>
>
> --
> Sent from:
> http://spamassassin.1065346.n5.nabble.com/SpamAssassin-Users-f3.html
>