Re: [mailop] Gmail's dkim=neutral
On 01/26/2018 04:45 PM, Vladimir Dubrovin via mailop wrote:> Actually, SPF can not protect against (visible) spoofing, because it > doesn't check RFC5322.From, it performs sender's server identification > for SMTP's MAIL FROM/HELO domain only. Just adding that “it” also protects against visible spoofing when used in conjunction with DMARC, as DMARC performs the “SPF” check against the domain part of 5322.From >> On the other hand, there could be false positives (like automatic >> forwarding), but in this case DKIM should remain ok. >> > > Not exactly, because there are mailing lists, and list can modify > message content, e.g. subject, like this one. (actually, this one rewrote 5322.From, most likely because corp.mail.ru publishes a p=reject DMARC record, so as not to break the DKIM signature and thus send a DMARC-rejected email -- but that's maybe off-topic) >> So when there's SPF, and it fails, AND there's DKIM, and it fails too, >> I guess we can consider that the trap is working as intended, and try >> to prevent a spoofing attempt from being successful. > > Unfortunately, the fact message fails or passes SPF and DKIM doesn't > have sufficient correlation with spam/ham or phishing/clear properties > to use it directly, for large e-mail systems, at least. It may work for > some private server where you can control all possible mail flows. Also, RFC6376 §6.3: If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed. As to why this makes sense, saying “there's DKIM and it fails” most likely means there is a bug in the sender's mail system, not that there is an attack: an attacker wouldn't earn anything against not-utterly-ill-configured servers by adding a bogus DKIM signature. However, note that §6.3 also states: [...] If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code. So it doesn't necessarily mean “let mail pass in the no-DKIM / failing-DKIM case”, it just means “please handle both the same way.” HTH, Leo ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail's dkim=neutral
26.01.2018 17:37, Benjamin BILLON пишет: > > Thanks for those details, > > > > My understanding is that SPF was primarily conceived against spoofing, > and not for reputation purposes. > > It doesn't mean that spammers can't have a proper SPF. It doesn't mean > that legitimate senders can't have no SPF. > It's right from RFC 7208: An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses since domains are likely to be more stable over a longer period. Furthermore, if a claimed identity fails verification, local policy can take stronger action against such email, such as rejecting it. Actually, SPF can not protect against (visible) spoofing, because it doesn't check RFC5322.From, it performs sender's server identification for SMTP's MAIL FROM/HELO domain only. > On the other hand, there could be false positives (like automatic > forwarding), but in this case DKIM should remain ok. > Not exactly, because there are mailing lists, and list can modify message content, e.g. subject, like this one. > > > So when there's SPF, and it fails, AND there's DKIM, and it fails too, > I guess we can consider that the trap is working as intended, and try > to prevent a spoofing attempt from being successful. > Unfortunately, the fact message fails or passes SPF and DKIM doesn't have sufficient correlation with spam/ham or phishing/clear properties to use it directly, for large e-mail systems, at least. It may work for some private server where you can control all possible mail flows. > > > But yeah, DMARC could help. With ISPs which actually check it. > > > > Best, > > -- > > Benjamin > > > > > > *From:*Vladimir Dubrovin [mailto:dubro...@corp.mail.ru] > *Sent:* Friday, 26 January, 2018 19:32 > *To:* Benjamin BILLON <bbil...@splio.com> > *Cc:* mailop@mailop.org > *Subject:* Re: [mailop] Gmail's dkim=neutral > > > > 26.01.2018 13:07, Benjamin BILLON пишет: > > Hi there! > > > > I have a case where one sender's message has been abused, reused > by someone who just added a Subject: line (so now there's two), > before sending it. > > Apparently the final recipient was at Gmail (given the headers I > had access to), and logically: > > * SPF failed: the domain name of the MAIL FROM didn't allow this > IP, which is not mine, to send. Fine. > * dkim=neutral (body hash did not verify): here I'm puzzled. One > of the purposes of DKIM being to validate the consistency of > the content. If the body hash doesn't verify, then it's > inconsistent. Then why "neutral" and not a pure fail? > > > > > > none: > > The message was not signed. > > fail: > > The message was signed and the signature(s) is (were) acceptable to > the verifier, but it (they) failed the verification test(s). > > neutral: > > The message was signed but the signature(s) contained syntax errors or > were not otherwise able to be processed. This result SHOULD also be > used for other failures not covered elsewhere in this list. > > permerror: > > The message could not be verified due to some error which is > unrecoverable, such as a required header field being absent. A later > attempt is unlikley to produce a final result. > > > There is no much difference between these states, any state different > from "pass" and "temperror" means message is not actually signed > correctly. Invalid hash means DKIM-Signature header doesn't match the > message. Verifier can treat it as either invalid DKIM-Signature header > (neutral) or verification failure (fail), there is no strict > requirements and there is no practical difference. > > > * > > > > Another question is how come the email hasn't been rejected > already, with a failed SPF and a, let's say, neutral DKIM. > > I don't know if it hit junk folder or not (I like to believe it > did, but I still receive the complaint). > > > > > Spammer can publish SPF and sign messages with DKIM. The fact of DKIM > presence or absence means nearly nothing. DKIM can be used by itself > to use DKIM domain's reputation to validate message. Same goes to SPF. > In the absence of DKIM or SPF, or if DKIM/SPF domains lacks reputation > data, verifier can use reputation of IP address. > > An exception is if SP
Re: [mailop] Gmail's dkim=neutral
Thanks for those details, My understanding is that SPF was primarily conceived against spoofing, and not for reputation purposes. It doesn't mean that spammers can't have a proper SPF. It doesn't mean that legitimate senders can't have no SPF. On the other hand, there could be false positives (like automatic forwarding), but in this case DKIM should remain ok. So when there's SPF, and it fails, AND there's DKIM, and it fails too, I guess we can consider that the trap is working as intended, and try to prevent a spoofing attempt from being successful. But yeah, DMARC could help. With ISPs which actually check it. Best, -- Benjamin From: Vladimir Dubrovin [mailto:dubro...@corp.mail.ru] Sent: Friday, 26 January, 2018 19:32 To: Benjamin BILLON <bbil...@splio.com> Cc: mailop@mailop.org Subject: Re: [mailop] Gmail's dkim=neutral 26.01.2018 13:07, Benjamin BILLON пишет: Hi there! I have a case where one sender's message has been abused, reused by someone who just added a Subject: line (so now there's two), before sending it. Apparently the final recipient was at Gmail (given the headers I had access to), and logically: * SPF failed: the domain name of the MAIL FROM didn't allow this IP, which is not mine, to send. Fine. * dkim=neutral (body hash did not verify): here I'm puzzled. One of the purposes of DKIM being to validate the consistency of the content. If the body hash doesn't verify, then it's inconsistent. Then why "neutral" and not a pure fail? none: The message was not signed. fail: The message was signed and the signature(s) is (were) acceptable to the verifier, but it (they) failed the verification test(s). neutral: The message was signed but the signature(s) contained syntax errors or were not otherwise able to be processed. This result SHOULD also be used for other failures not covered elsewhere in this list. permerror: The message could not be verified due to some error which is unrecoverable, such as a required header field being absent. A later attempt is unlikley to produce a final result. There is no much difference between these states, any state different from "pass" and "temperror" means message is not actually signed correctly. Invalid hash means DKIM-Signature header doesn't match the message. Verifier can treat it as either invalid DKIM-Signature header (neutral) or verification failure (fail), there is no strict requirements and there is no practical difference. * Another question is how come the email hasn't been rejected already, with a failed SPF and a, let's say, neutral DKIM. I don't know if it hit junk folder or not (I like to believe it did, but I still receive the complaint). Spammer can publish SPF and sign messages with DKIM. The fact of DKIM presence or absence means nearly nothing. DKIM can be used by itself to use DKIM domain's reputation to validate message. Same goes to SPF. In the absence of DKIM or SPF, or if DKIM/SPF domains lacks reputation data, verifier can use reputation of IP address. An exception is if SPF and DKIM are used as authentication method within DMARC policy. If you want message with your From address to be rejected in the absence of both valid DKIM and SPF authentication you have to publish restrictive DMARC policy. Side not: the recipient we initially send the first message to was also a Gmail user. Cheers, -- Benjamin ___ mailop mailing list mailop@mailop.org<mailto:mailop@mailop.org> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Vladimir Dubrovin @Mail.Ru ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail's dkim=neutral
26.01.2018 13:07, Benjamin BILLON пишет: > > Hi there! > > > > I have a case where one sender's message has been abused, reused by > someone who just added a Subject: line (so now there's two), before > sending it. > > Apparently the final recipient was at Gmail (given the headers I had > access to), and logically: > > * SPF failed: the domain name of the MAIL FROM didn't allow this IP, > which is not mine, to send. Fine. > * dkim=neutral (body hash did not verify): here I'm puzzled. One of > the purposes of DKIM being to validate the consistency of the > content. If the body hash doesn't verify, then it's inconsistent. > Then why "neutral" and not a pure fail? > none: The message was not signed. fail: The message was signed and the signature(s) is (were) acceptable to the verifier, but it (they) failed the verification test(s). neutral: The message was signed but the signature(s) contained syntax errors or were not otherwise able to be processed. This result SHOULD also be used for other failures not covered elsewhere in this list. permerror: The message could not be verified due to some error which is unrecoverable, such as a required header field being absent. A later attempt is unlikley to produce a final result. There is no much difference between these states, any state different from "pass" and "temperror" means message is not actually signed correctly. Invalid hash means DKIM-Signature header doesn't match the message. Verifier can treat it as either invalid DKIM-Signature header (neutral) or verification failure (fail), there is no strict requirements and there is no practical difference. > * > > > > > Another question is how come the email hasn't been rejected already, > with a failed SPF and a, let's say, neutral DKIM. > > I don't know if it hit junk folder or not (I like to believe it did, > but I still receive the complaint). > > > Spammer can publish SPF and sign messages with DKIM. The fact of DKIM presence or absence means nearly nothing. DKIM can be used by itself to use DKIM domain's reputation to validate message. Same goes to SPF. In the absence of DKIM or SPF, or if DKIM/SPF domains lacks reputation data, verifier can use reputation of IP address. An exception is if SPF and DKIM are used as authentication method within DMARC policy. If you want message with your From address to be rejected in the absence of both valid DKIM and SPF authentication you have to publish restrictive DMARC policy. > Side not: the recipient we initially send the first message to was > also a Gmail user. > > > > Cheers, > > -- > > Benjamin > > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Vladimir Dubrovin @Mail.Ru ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
[mailop] Gmail's dkim=neutral
Hi there! I have a case where one sender's message has been abused, reused by someone who just added a Subject: line (so now there's two), before sending it. Apparently the final recipient was at Gmail (given the headers I had access to), and logically: * SPF failed: the domain name of the MAIL FROM didn't allow this IP, which is not mine, to send. Fine. * dkim=neutral (body hash did not verify): here I'm puzzled. One of the purposes of DKIM being to validate the consistency of the content. If the body hash doesn't verify, then it's inconsistent. Then why "neutral" and not a pure fail? Another question is how come the email hasn't been rejected already, with a failed SPF and a, let's say, neutral DKIM. I don't know if it hit junk folder or not (I like to believe it did, but I still receive the complaint). Side not: the recipient we initially send the first message to was also a Gmail user. Cheers, -- Benjamin ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop