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 Fri, Aug 13, 2021 at 04:20:59PM +0200, Josh Good
wrote:
> Hello, to follow up on this issue regarding Rhenus.com and TLS 1.2,
> I confirm that mail flow to them without using the STARTTLS verb in the
> SMTP transaction, is working fine. So it looks like plain text SMTP is
> still allowed by t
> 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 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: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 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 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 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 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 13 Aug 2021, at 7:52 pm, MRob wrote:
>
> But if I want to not REMOVE those limits, but set a higher override limit, is
> there a way? Like inside smtpd_client_restrictions or something?
No.
--
Viktor.
On 2021-08-13 23:06, Viktor Dukhovni wrote:
On Fri, Aug 13, 2021 at 10:55:41PM +, MRob wrote:
Is this error:
warning: Message delivery request rate limit exceeded
result of surpassing smtpd_client_message_rate_limit?
I remember theres a way to specify certain parameter overrides
per-recipi
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 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
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 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
On 2021-08-13 23:01, post...@ptld.com wrote:
I remember theres a way to specify certain parameter overrides
per-recipient, but is there a way to override
smtpd_client_message_rate_limit per-client IP address? Right now
smtpd_client_message_rate_limit is set in main.cf
Is smtpd_client_connectio
On Fri, Aug 13, 2021 at 10:55:41PM +, MRob wrote:
> Is this error:
> warning: Message delivery request rate limit exceeded
> result of surpassing smtpd_client_message_rate_limit?
>
> I remember theres a way to specify certain parameter overrides
> per-recipient, but is there a way to overrid
I remember theres a way to specify certain parameter overrides
per-recipient, but is there a way to override
smtpd_client_message_rate_limit per-client IP address? Right now
smtpd_client_message_rate_limit is set in main.cf
Is smtpd_client_connection_count_limit what you are looking for?
http:/
Hllo,
Is this error:
warning: Message delivery request rate limit exceeded
result of surpassing smtpd_client_message_rate_limit?
I remember theres a way to specify certain parameter overrides
per-recipient, but is there a way to override
smtpd_client_message_rate_limit per-client IP address? R
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
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
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
On 2021 Jul 29, 10:01, Viktor Dukhovni wrote:
>
>
> > On 29 Jul 2021, at 8:17 am, raf wrote:
> >
> > The Rhenus email did say:
> >
> > "...must be sent with the TLS 1.2 protocol or higher.
> > Any mail received without fulfilling this condition
> > will be rejected by our server."
> >
> >
Ken N:
> Hello
>
> Given my domain has this two MXes:
>
> example.us. 299 IN MX 5 mx-1.example.com.
> example.us. 299 IN MX 5 mx-2.example.com.
>
> Do you think if I can setup a rule to tell any peer MTA that:
>
> Messages for use...@example.us wi
On 13.08.21 21:03, Ken N wrote:
Given my domain has this two MXes:
example.us. 299 IN MX 5 mx-1.example.com.
example.us. 299 IN MX 5 mx-2.example.com.
Do you think if I can setup a rule to tell any peer MTA that:
Messages for use...@example.
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
Hello
Given my domain has this two MXes:
example.us. 299 IN MX 5 mx-1.example.com.
example.us. 299 IN MX 5 mx-2.example.com.
Do you think if I can setup a rule to tell any peer MTA that:
Messages for use...@example.us will go to mx-1.example
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
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.
29 matches
Mail list logo
