I sent an email from mail.ru to pobox.com, pobox forwarded it to gmail.
This is DMARC setting of mail.ru:
_dmarc.mail.ru. 164 IN TXT
"v=DMARC1;p=reject;rua=mailto:d...@rua.agari.com,mai";
"lto:dmarc_...@corp.mail.ru"
(please notice p=reject setting)
When gmail receive the forwarded email f
On 2021-08-13 04:44, Ken N wrote:
I sent an email from mail.ru to pobox.com, pobox forwarded it to gmail.
This is DMARC setting of mail.ru:
_dmarc.mail.ru. 164 IN TXT
"v=DMARC1;p=reject;rua=mailto:d...@rua.agari.com,mai";
"lto:dmarc_...@corp.mail.ru"
(please notice p=reject se
The DMARC record itself looks fine and valid; however, the issue is going
to be whether your SPF and DKIM records alignment. I suspect the issue will
be in the alignment and the OP didn't provide those details to be able to
evaluate.
On Thu, Aug 12, 2021 at 11:47 PM Benny Pedersen wrote:
> On 20
Hello
When gmail see this forwarded email from pobox.com, it won't break SPF
because Pobox does a SRS.
But I doubt it will break DMARC for mail.ru since:
1) the from address in message header is x...@mail.ru
2) the sender IP addr (by pobox) is not owned by mail.ru
so gmail maybe reject this
On Fri, Aug 13, 2021 at 10:44:31AM +0800, Ken N wrote:
> I sent an email from mail.ru to pobox.com, pobox forwarded it to gmail.
>
> This is DMARC setting of mail.ru:
>
> _dmarc.mail.ru. 164 IN TXT
> "v=DMARC1;p=reject;rua=mailto:d...@rua.agari.com,mai";
> "lto:dmarc_...@
On 2021-08-13 06:25, Ken N wrote:
Am I right?
no, SRS is not part of dmarc
pobox have there own spf, and dkim, but pobox should not use srs or add
dkim signing, so only arc sealing on pobox is needed to not break dmarc
if pobox on the other hand originating emails thay should dkim sign it,
thank you very much @raf. I have got your idea.
On 2021/8/13 1:03 下午, raf wrote:
On Fri, Aug 13, 2021 at 10:44:31AM +0800, Ken N wrote:
I sent an email from mail.ru to pobox.com, pobox forwarded it to gmail.
This is DMARC setting of mail.ru:
_dmarc.mail.ru. 164 IN TXT
"v=D
Raf,
Im confused by this, i thought as long as either dkim or spf passes then
dmarc passes. But i still see dmarc fails.
Envelope-From: dovecot-boun...@dovecot.org
Header From: some...@netcourrier.com
DKIM: bad signature data
DMARC: SPF(mailfrom): dovecot.org pass
DMARC: netcourrier.
On August 13, 2021 12:05:44 PM UTC, post...@ptld.com wrote:
>Raf,
>Im confused by this, i thought as long as either dkim or spf passes then
>dmarc passes. But i still see dmarc fails.
>
> Envelope-From: dovecot-boun...@dovecot.org
> Header From: some...@netcourrier.com
>
> DKIM: bad signa
I have pasted @raf's answer to my blog posting.
copyright @ralf certainly. thank you.
https://blog.hoxblue.com/will-a-forwarded-message-break-the-dmarc/
regards.
On 2021/8/13 1:03 下午, raf wrote:
Maybe. It depends on lots of stuff. A DMARC check
passes if either SPF or DKIM pass, but (for DMARC
On 2021-08-13 at 08:05:44 UTC-0400 (Fri, 13 Aug 2021 08:05:44 -0400)
is rumored to have said:
Raf,
Im confused by this, i thought as long as either dkim or spf passes
then dmarc passes. But i still see dmarc fails.
Envelope-From: dovecot-boun...@dovecot.org
Header From: some...@netcourr
Domain alignment is essential to DMARC. DMARC always refers to the
From header domain. SPF validates the envelope sender (MailFrom)
domain. DKIM can validate any domain, even one not used anywhere else
in the message. For DMARC to succeed, the From header domain must
align with a domain whose vali
post...@ptld.com:
> > Domain alignment is essential to DMARC. DMARC always refers to the
> > From header domain. SPF validates the envelope sender (MailFrom)
> > domain. DKIM can validate any domain, even one not used anywhere else
> > in the message. For DMARC to succeed, the From header domain mu
On Fri, Aug 13, 2021 at 01:31:05PM -0400, Wietse Venema
wrote:
> post...@ptld.com:
> > > Domain alignment is essential to DMARC. DMARC always refers to the
> > > From header domain. SPF validates the envelope sender (MailFrom)
> > > domain. DKIM can validate any domain, even one not used anywher
Yes I agree.
most google groups add the additional info at the end of each message,
that makes DKIM invalid.
since google groups is a forwarding service who does a valid SRS, SPF
has no contribution to the DMARC validation.
So, almost every message forwarded by google groups has DMARC failed.
On 2021-08-14 01:10, raf wrote:
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
note 2 instances of From
i bet both is not dkim signed, or both From is not in the recieved dkim
validator seen
On 2021-08-14 01:22, Ken N wrote:
Yes I agree.
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=purpleemail.com; s=x; h= headers
oversigned headers that dont exits to validators breaks dkim
imho some headers changes on transit here, dont sign every header at
si
On Sat, Aug 14, 2021 at 01:22:43AM +0200, Benny Pedersen wrote:
> On 2021-08-14 01:10, raf wrote:
>
> > h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
>
> note 2 instances of From
>
> i bet both is not dkim signed, or both From is not in the recieved dkim
> validator seen
I
On Sat, Aug 14, 2021 at 01:39:29AM +0200, Benny Pedersen wrote:
> On 2021-08-14 01:22, Ken N wrote:
> > Yes I agree.
>
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=purpleemail.com; s=x; h= headers
>
> oversigned headers that dont exist to validators breaks d
On 2021-08-14 05:50, raf wrote:
On Sat, Aug 14, 2021 at 01:22:43AM +0200, Benny Pedersen
wrote:
On 2021-08-14 01:10, raf wrote:
> h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
note 2 instances of From
i bet both is not dkim signed, or both From is not in the recieved
d
On 2021-08-14 05:54, raf wrote:
Not in this case. It's the To: header that is being
changed by the dovecot mailing list software.
So if the To: header is included in the signature,
then the signature will become invalid.
dovecot do openARC, but dkim can still be breaked after openARC, but if
> On 14 Aug 2021, at 12:38 am, Benny Pedersen wrote:
>
>> It
>> means that the From: header is included twice in the
>> data being signed. But it's odd. The extra inclusion is
>> as an empty From: header.
>
> i will say this is a cleat bug to have resolved
Instead of empty speculation, a radica
On 2021-08-14 06:45, Viktor Dukhovni wrote:
Instead of empty speculation, a radical idea would be to read
the DKIM specification and understand why signing some headers
one more time than they appear in the message is a feature of
that specification.
its then impossible to verify if there ever
> On 14 Aug 2021, at 12:54 am, Benny Pedersen wrote:
>
> its then impossible to verify if there ever was an extra header or not, this
> still make it less strong, it does not more secure or not with that feature
>
> this makes dkim more weak to have that as valid, and imho it does not being
>
On Sat, Aug 14, 2021 at 04:56:33AM +, Viktor Dukhovni
wrote:
> > On 14 Aug 2021, at 12:54 am, Benny Pedersen wrote:
> >
> > its then impossible to verify if there ever was an extra header or =
> not, this still make it less strong, it does not more secure or not with =
> that feature
> >
On 2021-08-14 01:22, Ken N wrote:
Yes I agree.
On 14.08.21 01:39, Benny Pedersen wrote:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=purpleemail.com; s=x; h= headers
oversigned headers that dont exits to validators breaks dkim
they don't.
imho some heade
26 matches
Mail list logo