DKIM: fail (body hash did not verify) but DMARC: pass - dkim

I received an email (using Office365) which had the following:
spf=pass
dkim=fail (body hash did not verify)
dmarc=pass action=none
compauth=pass reason=100
Should DMARC not fail when DKIM fails or?
Part of mail header (redacted):
Authentication-Results: spf=pass (sender IP is 185.XXX.XXX.XXX)
smtp.mailfrom=xxxxx.com; yyyyy.com; dkim=fail (body hash did not verify)
header.d=xxxxx.com;yyyyy.com; dmarc=pass action=none
header.from=xxxxx.com;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of xxxxx.com designates
185.XXX.XXX.XXX as permitted sender) receiver=protection.outlook.com;
client-ip=185.XXX.XXX.XXX; helo=xxxxx.com;
Received: xxxxx.com (185.XXX.XXX.XXX) by
XXXXT057.mail.protection.outlook.com (10.152.5.104) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.3370.16 via Frontend Transport; Tue, 15 Sep 2020 09:28:04 +0000
Received: from [10.244.53.49] (unknown [62.xxx.xxx.xxx])
(Authenticated sender: johndoe#xxxxx.com)
by xxxxx.com (Postfix) with ESMTPSA id 958xxxxxx
for <janedoe#yyyyy.com>; Tue, 15 Sep 2020 09:27:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 xxxxx.com 95811831E7
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xxxxx.com;
s=default; t=1600162079;
bh=nuM3cWrinDLZjraJCy30WYG0ePetEpsDwkYbe7tHCOs=;
h=Date:Subject:From:To:From;
b=jJZ91ejcq4Tu3xV+PtcT1/pgwHbUXQRxFLbilFKFiYTnBi1Zn31vzAHbPe4o40HM0
gi+7F9TdBu47MhNwTFIvY94M+uSx1U4B9Ci9hTSDwEaDGazONyB8ER1fFmD7LPRMvV
oXdTEACywQrrYPPb15RkSUNg6m8+6AJjdMgDrRDU=

Short answer:
No, DMARC fails if and only if:
SPF or SPF Alignment has failed, and
DKIM or DKIM Alignment has failed
If only one of them fails and the other passes, DMARC will pass.
Some more details around DMARC failures and the protocol in general:
An important detail to keep in mind from the perspective of DMARC is that a failure for SPF or DKIM can mean 2 things:
The underlying SPF or DKIM authentication has failed, or
The underlying SPF or DKIM alignment has failed.
Authentication is probably clear since it is related to the underlying protocols themselves.
Alignment is an additional feature introduced by DMARC, which checks if the domains used for the SPF/DKIM authentication are in alignment with the domain portion of the RFC5322.From domain (which is the domain portion of the sender's email address, e.g. senderxyz#domain.com).
A successful SPF/DKIM alignment implies that the domains are either identical or that the SPF/DKIM domain is a subdomain of the RFC5321.From domain. This is called a strict or relaxed alignment respectively, and can be controlled via the aspf and adkim tags in your DMARC Record.

Related

SagePay VPS Protocol 4.00 Server Integration - VPSSignature not matching

Please see the transaction post
VPSProtocol=4.00&TxType=PAYMENT&Vendor=Vendorname
&VendorTxCode=324234906133500
&Amount=20.00
&Currency=GBP
&Description=Payment
&BillingSurname=Jo
&BillingFirstnames=Test
&BillingAddress1=43
&BillingCity=Ash
&BillingPostCode=Asd234
&BillingCountry=GB
&BillingPhone=323-8412233
&CustomerEMail=test#test.com
&DeliverySurname=Jo
&DeliveryFirstnames=Test
&DeliveryAddress1=43
&DeliveryCity=Ash
&DeliveryPostCode=Asd234
&DeliveryCountry=GB
&DeliveryPhone=323-8412233
&AllowGiftAid=0
&ApplyAVSCV2=1
&Apply3DSecure=1
&Profile=LOW
&VendorData=Rent
&NotificationURL=https://testpage/notificationpage.aspx
Please see the Transaction Post Response below
Status: OK
VendorTxCode: 324234906133500
VPSTxId: {8652345E-5B25-49F1-DD23-1B9CCC2B6545}
Security Key: AZFE2KOSDS
VPSSignature: N135C007EF1643ABE44CAC12EBD9ED43
StatusDetail: 0000 : The Authorisation was Successful.
TxAuthNo: 34234532
AVSCV2: SECURITY CODE MATCH ONLY
AddressResult: NOTMATCHED
PostCodeResult: NOTMATCHED
CV2Result: MATCHED
GiftAid: 0
3DSecureStatus: OK
CAVV: Y2c2ZVVBeTRvTUVwVGtpaGVMdzk=
AddressStatus:
PayerStatus:
CardType: VISA
Last4Digits: 0006
DeclineCode: 00
ExpiryDate: 0123
BankAuthCode: 999777
Surcharge: 0.40
FraudResponse:
ACSTransID: 490ead88-8dc8-4ac4-b40a-fbe1f8a95182
DSTransID: 3f06865c-33c1-462c-956d-01f4c55114b5
SchemeTraceID: Wkv0Jq8QEYu4DupyW0gG}s2~}N2K~U+7LAMYCVU0vXt2uH0prPJCpY6
The Issue is VPSSignature is not matching after computing the MD5 signature
VPSTxId+VendorTxCode+Status+TxAuthNo+VendorName+AVSCV2+SecurityKey+AddressResult+ PostCodeResult+CV2Result+GiftAid+3DSecureStatus+CAVV+AddressStatus+PayerStatus+CardType+ Last4Digits+DeclineCode+ExpiryDate+FraudResponse+BankAuthCode+ACSTransID+DSTransID+SchemeTraceID
SERVER Integration POST URL: https://test.sagepay.com/gateway/service/vspserver-register.vsp
Have you validated your code that builds the signature to be compared against VPSSignature in the Post response? Are they salting the MD5? Are you feeding it the exact payload? I fed your Post into an MD5 generator and I got 79dda36adfdc796412ab0fa77ca67380 instead of N135C007EF1643ABE44CAC12EBD9ED43 .

In POP3, what is the expected first response line to a RETR command?

I'm learning about POP3 by reading RFC 1939.
The description of the RETR command says the following:
Possible Responses:
+OK message follows
-ERR no such message
Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .
What does "120 octets" refer to? Is this optional information about the message that may or may not be included, and if so, is "message follows" not required (as specified under "Possible Responses")?
What does "120 octets" refer to? Is this optional information about the message that may or may not be included
Correct, the "120 octets" is optional informational text but is not required text nor can the number of octets be used as definitive for calculating the end of the message data.
and if so, is "message follows" not required (as specified under "Possible Responses")?
That's why it was stated to be a "possible response" ;-)
Basically, all you can really use from that first line is the first token which will be "+OK" or "-ERR". Everything after that is informational text that may be a helpful when debugging, but not guaranteed to be useful for your code to try and interpret.
I would argue that if it is of the form "# octets", you might be able to use it to show progress as you read data, but that's about the best you can do.
Even so, I would probably recommend using the octet value from the LIST command instead.

FusionPBX: Ring Group with external phone numbers?

I want to define a Ring Group that, when called, rings one extension and one external number (mobile phone). What is the best way to achieve that?
Right now only the extension is called. So just entering an external number in the Destination field does not work, the logs say
[NOTICE] switch_cpp.cpp:1376 [ring groups][call forward all] user_exists id <mobileno> <domainname>
and later
[DEBUG] switch_ivr_originate.c:3865 Originate Resulted in Error Cause: 27 [DESTINATION_OUT_OF_ORDER]
It will check all calls using the dialplan to see if the destination is a local number for an external number it should say user_exists false every time.
This [DESTINATION_OUT_OF_ORDER] indicates that it may not have found a matching outbound route that matches the number of digits of the external phone number. Or it may mean that your carrier rejected the call maybe didn't like the caller ID that was sent. Easiest thing to try is attempt it with an outbound rout to different carrier.
In case you weren't aware FusionPBX 4.4 was release on 5 April 2018. Instructions to upgrade are post on docs.fusionpbx.com. Search term upgrade (version upgrade).

SPF = Hotmail : Pass / Gmail : Fail

I have a problem with my hmailserver and DNS configuration. I've done some research like always but couldn't find a solution.
My problem is, I'm sending mail from the same configuration with the same content. I'm just testing my SMTP with some random content.
Here are my headers
Hotmail (GOING TO SPAM) :
x-store-info:4r51+eLowCe79NzwdU2kRyU+pBy2R9QCP2v0IhDR+nDcjJhExUZYgyI5gvwWZJm3B9+zhp1b8g9rWgPTcyugiNy5RNAKdzcQ85c68teICR4NR4jawKrGyam4AxeWgzfI4kCCw0YhWHc=
Authentication-Results: hotmail.com; spf=pass (sender IP is 213.xxx.77.226) smtp.mailfrom=newsletter#bulten.mywebpage.com; dkim=pass header.d=bulten.mywebpage.com; x-hmca=pass header.id=newsletter#bulten.mywebpage.com
X-SID-PRA: newsletter#bulten.mywebpage.com
X-AUTH-Result: PASS
X-SID-Result: PASS
X-Message-Status: n:n
X-Message-Delivery: Vj0xLjE7dXM9MDtsPTA7YT0wO0Q9MjtHRD0yO1NDTD02
X-Message-Info: M98loaK0Lo27IVRxloyPISH/oVyrdG4nMrQ10tOoOAh+4yXzzinDYnrCEwQMhKw5Kbg20/W+pSaAgRNb6qx3ZAIS4jQ8o1SuT0gLmEqUYP5WkN/qCGlIwYTMVcAEJWElUKKFHOe6+xDjYXG7bZTx832DICnQ8i2eplRpU0YjHv0=
Received: from bulten.mywebpage.com ([213.xxx.77.226]) by BAY0-MC2-F20.Bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4900);
Sun, 12 May 2013 06:11:06 -0700
dkim-signature: v=1; a=rsa-sha1; d=bulten.mywebpage.com; s=1368316485.mywebpage;
c=relaxed/relaxed; q=dns/txt; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
bh=jFvLWT7EYZtAdGQ7lvPhguutUpw=;
b=ntkQpaORlFsM79gFqd8WLhfuGb+nKHWSc3Iuonq6CM7A+W1xO32p+6pOxnpgMqK6/GkVnNFbBrU44NAw5hpffvon/VKcRj1S4hBl9BrfryKKAMdjHw6UvH6MwT5KE/zTzzdm66EpLzfoK6ytwPar67KArvsE1JbcUgYm/RglRGU=
Received: from bulten.mywebpage.com ([213.xxx.77.226])
by bulten.mywebpage.com
; Sun, 12 May 2013 16:11:02 +0300
mywebpage
Gmail (GOING TO SPAM)
Delivered-To: webmaster#mywebpage.com Received: by 10.76.101.68 with SMTP id fe4csp131929oab;
Sun, 12 May 2013 06:12:01 -0700 (PDT) X-Received: by 10.14.221.67 with SMTP id q43mr20043754eep.1.1368364321268;
Sun, 12 May 2013 06:12:01 -0700 (PDT) Return-Path: <newsletter#bulten.mywebpage.com> Received: from bulten.mywebpage.com ([213.xxx.77.226])
by mx.google.com with SMTP id z48si11728661een.205.2013.05.12.06.12.00
for <webmaster#mywebpage.com>;
Sun, 12 May 2013 06:12:01 -0700 (PDT) Received-SPF: fail (google.com: domain of newsletter#bulten.mywebpage.com does not designate 213.xxx.77.226 as permitted sender) client-ip=213.xxx.77.226; Authentication-Results: mx.google.com;
spf=hardfail (google.com: domain of newsletter#bulten.mywebpage.com does not designate 213.xxx.77.226 as permitted sender) smtp.mail=newsletter#bulten.mywebpage.com;
dkim=neutral (no signature) header.i=#bulten.mywebpage.com dkim-signature: v=1; a=rsa-sha1; d=bulten.mywebpage.com; s=1368316485.mywebpage; c=relaxed/relaxed; q=dns/txt; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=jFvLWT7EYZtAdGQ7lvPhguutUpw=; b=NaPGwJqhXuvi4oXzwD5Ldr3I1ZqIhF8V6Q/SB7n5lbdklqNdW1IUXAJ5m0ndjOAz2xaBMhfte2PvL3aQdVRQDuLY2YDXBReznz20UCkAA6xUj0Lyvb0wrjhZgeOBIuOWrU0l+siM12fLVDAulPOKZ5s1R0RKAbJ+Leq3Lb8W76o= Received: from bulten.mywebpage.com ([213.xxx.77.226]) by bulten.mywebpage.com ; Sun, 12 May 2013 16:11:57 +0300
Can anyone help me in anyway? I'm about to lose it. It's my first SMTP server configuration and I know I'm missing something.
This is the key:
Received-SPF: fail (google.com: domain of newsletter#bulten.mywebpage.com does not designate 213.xxx.77.226 as permitted sender)
There should be text record in the DNS of bulten.mywebpage.com in spf format that points to the mail server sending out the mail, something like this:
v=spf1 mx mx:mailserverdomain.com

Google marks seemingly perfect emails as spam [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
First post, have found many answers here, so hopes are high.
The problem: Google marks seemingly correctly formatted emails from my apache/postfix server as spam. Sample email as follows;
(I have replaced my domain with mydomain.com.au and the IP with a pretend IP)
Delivered-To: my.email#gmail.com
Received: by 10.150.216.21 with SMTP id o21cs22383ybg;
Fri, 26 Feb 2010 23:11:55 -0800 (PST)
Received: by 10.231.152.75 with SMTP id f11mr1470919ibw.50.1267254715619;
Fri, 26 Feb 2010 23:11:55 -0800 (PST)
Return-Path: <apache#mydomain.com.au>
Received: from mydomain.com.au (mydomain.com.au [80.107.158.80])
by mx.google.com with ESMTP id 29si1651619iwn.31.2010.02.26.23.11.54;
Fri, 26 Feb 2010 23:11:55 -0800 (PST)
Received-SPF: pass (google.com: domain of apache#mydomain.com.au designates 80.107.158.80 as permitted sender) client-ip=80.107.158.80;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of apache#mydomain.com.au designates 80.107.158.80 as permitted sender) smtp.mail=apache#mydomain.com.au
Received: by mydomain.com.au (Postfix, from userid 48)
id ACB735030340; Sat, 27 Feb 2010 18:11:53 +1100 (EST)
To: my.email#gmail.com
Subject: Quote for David Brent (00125512123)
From: quotes#mydomain.com.au
Reply-To: quotes#mydomain.com.au
X-Mailer: PHP/5.2.10
Message-Id: <20100227071153.ACB735030340#mydomain.com.au>
Date: Sat, 27 Feb 2010 18:11:53 +1100 (EST)
Name: David Brent
Mobile: 00125512123
Phone:
Email: my.email#gmail.com
Date: 2010-20-21
Time: 21:00
Location: Syd
Eventype: Musicians
Message: Yep, this should work!!!!
how did you hear about us: Newspaper
I have tried sending it to non-google emails, and they arrive fine.
I have tried posting to several different google accounts, all end up as spam.
Mydomain.com.au uses Google Apps as email provider.
I have added "v=spf1 a mx ~all" as TXT in my NS.
I used http://remote.12dt.com/ to check reverse DNS and the IP seems to be resolving back to the domain name just fine.
The headers seem fine, and the SPF look up seems to pass (?).. Any ideas?
Kind regards
It is not that simple. If all you had to do was provide SPF and an RFC-compliant message, every spammer in the world could get past such a filter.
This could be due to sender reputation, i.e. apache#mydomain.com.au may have sent spam messages before, or 80.107.158.80 may be previously unknown to Google. Google knows that a new sender suddenly popping up from a previously unknown IP is possibly a hacked server or part of a botnet.