On Fri, Jul 16, 2021 at 11:32:32AM +0200, Benny Pedersen wrote:
> On 2021-07-16 09:12, raf wrote:
>
> > According to this:
> >
> > https://postmarkapp.com/blog/proof-dkim-and-senderid-improve-delivery
>
> please stay away from senderid, its deprecated
Yes, I thought it was strange that they m
On 2021-07-16 at 03:12:38 UTC-0400 (Fri, 16 Jul 2021 17:12:38 +1000)
raf
is rumored to have said:
On Wed, Jul 14, 2021 at 02:51:25PM +1000, raf wrote:
On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
wrote:
On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
raf
is r
On 2021-07-16 09:12, raf wrote:
According to this:
https://postmarkapp.com/blog/proof-dkim-and-senderid-improve-delivery
please stay away from senderid, its depricated
and stop using spf-milters or opendmarc with libspf2 with aswell
validate senderid, libspf2 is not latest spf rfcs as last
On Fri, Jul 16, 2021 at 05:12:38PM +1000, raf wrote:
> On Wed, Jul 14, 2021 at 02:51:25PM +1000, raf wrote:
>
> > On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
> > wrote:
> >
> > > On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
> > > raf
> > > is rumored to have
On Wed, Jul 14, 2021 at 02:51:25PM +1000, raf wrote:
> On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
> wrote:
>
> > On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
> > raf
> > is rumored to have said:
> >
> > > I'm beginning to think that DKIM headers might be
> >
On 2021-07-16 02:07, Bill Cole wrote:
No, postfix.org has no TXT record, so mail from a postfix.org address
can neither pass nor fail a SPF test.
spf none is a valid test in mail::spf
its not same as spf neutral
as a spamassassin pmc member you should know
On Thu, Jul 15, 2021 at 08:07:52PM -0400, Bill Cole
wrote:
> On 2021-07-15 at 19:44:41 UTC-0400 (Fri, 16 Jul 2021 09:44:41 +1000)
> raf
> is rumored to have said:
>
> > SPF by itself would have checked the envelope address
> > (owner-postfix-us...@postfix.org), but DMARC's
> > reinterpretation
On 2021-07-15 at 19:44:41 UTC-0400 (Fri, 16 Jul 2021 09:44:41 +1000)
raf
is rumored to have said:
SPF by itself would have checked the envelope address
(owner-postfix-us...@postfix.org), but DMARC's
reinterpretation of SPF is not the same as actual SPF.
It checks the From: address (@raf.org) in
On Thu, Jul 15, 2021 at 08:12:39AM -0400, post...@ptld.com wrote:
> Was SPF looking up records for raf.org or for cloud9.net? I see both of
> those domains have published SPF records so why was SPF "None"?
> Why did DMARC reject this even though it didn't fail either check?
Here's my attempt at a
On 2021-07-15 14:12, post...@ptld.com wrote:
Was SPF looking up records for raf.org or for cloud9.net? I see both
of those domains have published SPF records so why was SPF "None"?
Why did DMARC reject this even though it didn't fail either check?
use smtpd_milter_maps to enforce no reject fro
nup[226977]: 4GQLM7378Wz4l3hN: info: header Subject: Re: Conditional
milter_header_checks? from camomile.cloud9.net[168.100.1.3];
from= to= proto=ESMTP
helo=
postfix/cleanup[226977]: 4GQLM7378Wz4l3hN:
message-id=<20210715040216.ga27...@raf.org>
opendkim[221168]: 4GQLM7378Wz4l3hN: camomile.cloud9.
/cleanup[226977]: 4GQLM7378Wz4l3hN: info: header Subject: Re:
Conditional milter_header_checks? from camomile.cloud9.net[168.100.1.3];
from= to= proto=ESMTP
helo=
postfix/cleanup[226977]: 4GQLM7378Wz4l3hN:
message-id=<20210715040216.ga27...@raf.org>
opendkim[221168]: 4GQLM7378Wz4l3hN: c
On 15/07/21 1:07 am, Bill Cole wrote:
If you want to post to discussion mailing lists, you should either use
a From address in a domain without any DMARC record or publish one
with a p=none policy and sign your messages with DKIM, even though
they are likely to be broken by the mailing list.
On Wed, Jul 14, 2021 at 09:34:22PM -0400, Bill Cole
wrote:
> Please keep replies on-list only. Duplicates of anything sent to the list
> are just a nuisance.
Will do. That's my preference too, but different lists
have different opinions about that.
> On 2021-07-14 at 20:51:03 UTC-0400 (Thu, 1
Please keep replies on-list only. Duplicates of anything sent to the
list are just a nuisance.
On 2021-07-14 at 20:51:03 UTC-0400 (Thu, 15 Jul 2021 10:51:03 +1000)
raf
is rumored to have said:
On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole
wrote:
On 2021-07-14 at 03:43:57 UTC-0400 (W
Please keep replies on-list only. Duplicates of anything sent to the
list are just a nuisance.
On 2021-07-14 at 20:51:03 UTC-0400 (Thu, 15 Jul 2021 10:51:03 +1000)
raf
is rumored to have said:
On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole
wrote:
On 2021-07-14 at 03:43:57 UTC-0400 (W
On Wed, Jul 14, 2021 at 09:07:54AM -0400, Bill Cole
wrote:
> On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000)
> raf
> is rumored to have said:
>
> > Here's a (silly) thing that wrong with DMARC: :-)
> > I've sent two messages to this mailing list so far, and
> > I've receiv
On Wed, Jul 14, 2021 at 10:03:00AM +0200, Matus UHLAR - fantomas
wrote:
> > On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote:
> > > Here's a (silly) thing that wrong with DMARC: :-)
> > > I've sent two messages to this mailing list so far, and
> > > I've received 52 DMARC forensic/failure rep
On Wed, Jul 14, 2021 at 09:51:25AM +0200, Bastian Blank
wrote:
> On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote:
> > Here's a (silly) thing that wrong with DMARC: :-)
> > I've sent two messages to this mailing list so far, and
> > I've received 52 DMARC forensic/failure report emails
> > as
You can certainly take a pedantic view, that's contrary to the DKIM
RFCs and common sense, there's no Internet police to stop you. Just
keep in mind that rejecting failed DKIM signatures has no security
benefit.
Hm, there is always the possibility that I misunderstood the
specifications. Correc
On Wed, Jul 14, 2021 at 07:08:07PM +0300, Kevin N. wrote:
> > You can certainly take a pedantic view, that's contrary to the DKIM
> > RFCs and common sense, there's no Internet police to stop you. Just
> > keep in mind that rejecting failed DKIM signatures has no security
> > benefit.
>
> Hm, th
Kevin N.:
> So, *if present*, the signature should be valid.
A system that treats 'no signature' different from 'bad signature'
or 'unverifiable signature' is broken from a security point of view.
It gives an adversary more opportunties than it deserves.
Wietse
It is a really bad idea to reject messages whose DKIM signature is invalid.
DO NOT DO THIS.
Why exactly is it a really bad idea :) ?
Could you give us some more practical details/examples?
The point is that absent DMARC policy that promises DKIM signatures
aligned with the RFC2822.From domain,
There are 2 different and contradictory DMARC records in DNS for
raf.org. That guarantees breakage.
Interesting, according to [1] they shouldn't receive reports at all.
[1] https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.3 point 5
On 2021-07-14 at 03:43:57 UTC-0400 (Wed, 14 Jul 2021 17:43:57 +1000)
raf
is rumored to have said:
Here's a (silly) thing that wrong with DMARC: :-)
I've sent two messages to this mailing list so far, and
I've received 52 DMARC forensic/failure report emails
as a result! :-)
There are 2 differ
On 14/07/2021 08:43, raf wrote:
On Wed, Jul 14, 2021 at 02:38:00PM +1000, raf wrote:
On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote:
Viktor wrote:
That's because DMARC (which I don't use or recommed)
Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL
On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote:
Here's a (silly) thing that wrong with DMARC: :-)
I've sent two messages to this mailing list so far, and
I've received 52 DMARC forensic/failure report emails
as a result! :-)
On 14.07.21 09:51, Bastian Blank wrote:
Your mails are not DKIM
On Wed, Jul 14, 2021 at 05:43:57PM +1000, raf wrote:
> Here's a (silly) thing that wrong with DMARC: :-)
> I've sent two messages to this mailing list so far, and
> I've received 52 DMARC forensic/failure report emails
> as a result! :-)
Your mails are not DKIM signed, so of course they will fail.
On Wed, Jul 14, 2021 at 02:38:00PM +1000, raf wrote:
> On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote:
>
> Viktor wrote:
>
> > > That's because DMARC (which I don't use or recommed)
> >
> > Why don't you recommend DMARC? What is wrong with it? Do you accept *ALL*
> > mail sen
On Wed, Jul 14, 2021 at 01:48:21AM +0300, Kevin N. wrote:
> > It is a really bad idea to reject messages whose DKIM signature is invalid.
> > DO NOT DO THIS.
>
> Why exactly is it a really bad idea :) ?
> Could you give us some more practical details/examples?
The point is that absent DMARC poli
On Tue, Jul 13, 2021 at 10:35:15PM -0400, Bill Cole
wrote:
> On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
> raf
> is rumored to have said:
>
> > I'm beginning to think that DKIM headers might be
> > getting added just to improve spam detection scores.
> > Perhaps I'm
On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote:
> > A DKIM signature does not imply any expectation that
> > all messages will have valid signatures.
>
> Why does DKIM signature exist if not to provide a way to know if an email
> has been altered after someone sent it?
That's n
On 2021-07-13 at 21:18:46 UTC-0400 (Wed, 14 Jul 2021 11:18:46 +1000)
raf
is rumored to have said:
I'm beginning to think that DKIM headers might be
getting added just to improve spam detection scores.
Perhaps I'm getting too cynical. :-)
That would not be very effective.
For example: in Ap
On Tue, Jul 13, 2021 at 06:32:17PM -0400, Viktor Dukhovni
wrote:
> Valid DKIM signatures can make it easier to apply greater scrutiny to
> messages that lack a positive reputation, without incurring an excessive
> false positive rate. But you still need some real evidence that a
> message is li
The DKIM standards are quite emphatically clear that bad signature == no
signature,
and that receiving systems MUST NOT reject a message just because a signature is
missing or fails to match. The treatment of messages that lack a signature is
covered by DMARC (and ARC).
It is a really bad idea
On Tue, Jul 13, 2021 at 06:06:16PM -0400, post...@ptld.com wrote:
> > A DKIM signature does not imply any expectation that
> > all messages will have valid signatures.
>
> Why does DKIM signature exist if not to provide a way to know if an
> email has been altered after someone sent it? Why can'
On 7/13/21 6:06 PM, post...@ptld.com wrote:
I am not meaning to confrontational, i want to develop a deeper understanding
and educate myself.
your issues are not with Postfix, & likely won't be further addressed/solved
here
they're with your understanding of DMARC policy/usage, and the par
I am not meaning to confrontational, i want to develop a deeper
understanding and educate myself.
A DKIM signature does not imply any expectation that
all messages will have valid signatures.
Why does DKIM signature exist if not to provide a way to know if an
email has been altered after so
On Tue, Jul 13, 2021 at 05:33:35PM -0400, post...@ptld.com wrote:
> > If opendkim supports "On-BadSignature reject", that's a disservice to
> > its users.
>
> So it's unacceptable for dkim software to reject a message for a failed
> dkim signature.
Yes.
> But its okay for dmarc software to re
On 07-13-2021 4:14 pm, Viktor Dukhovni wrote:
The DKIM standards are quite emphatically clear that bad signature ==
no signature,
and that receiving systems MUST NOT reject a message just because a
signature is
missing or fails to match. The treatment of messages that lack a
signature is
cove
> On 13 Jul 2021, at 3:59 pm, post...@ptld.com wrote:
>
>> FWIW, there is no such thing as "DKIM enforcement", you're probably
>> thinking of DMARC.
>
> Maybe its technically called DMARC, but what im referring to is the opendkim
> verification mode with a On-BadSignature reject policy. My layma
On 07-13-2021 3:34 pm, Viktor Dukhovni wrote:
FWIW, there is no such thing as "DKIM enforcement", you're probably
thinking of DMARC.
Maybe its technically called DMARC, but what im referring to is the
opendkim verification mode with a On-BadSignature reject policy. My
layman's term of "DKIM e
On Tue, Jul 13, 2021 at 03:29:42PM -0400, post...@ptld.com wrote:
> > On 07-13-2021 2:47 pm, Matus UHLAR - fantomas wrote:
> > btw, as always: what are you trying to achieve?
>
> The end goal is per-recipient kdim enforcement. Since it's impossible to
> control if milter/dkim runs or not based on
On 07-13-2021 2:47 pm, Matus UHLAR - fantomas wrote:
btw, as always: what are you trying to achieve?
The end goal is per-recipient kdim enforcement. Since it's impossible to
control if milter/dkim runs or not based on recipient, my next option to
explore is allowing dkim to run passive to jus
On 07-13-2021 1:27 pm, Bill Cole wrote:
No. All of the restriction lists are named 'smtpd_*_restrictions'
which is a clue that they are used by the smtpd process. The
header_checks are a function of the cleanup daemon, not smtpd.
If you need to handle message content differently on a per-recipien
On 07-13-2021 1:27 pm, Bill Cole wrote:
No. All of the restriction lists are named 'smtpd_*_restrictions'
which is a clue that they are used by the smtpd process. The
header_checks are a function of the cleanup daemon, not smtpd.
If you need to handle message content differently on a per-recipie
On 2021-07-13 at 12:47:35 UTC-0400 (Tue, 13 Jul 2021 12:47:35 -0400)
is rumored to have said:
>> On 07-13-2021 12:29 pm, Bill Cole wrote:
>>
>> Logically impossible. You don't have the headers yet when
>> smtpd_recipient_restrictions directives are evaluated.
>
> If i move the "operation" to ano
On 07-13-2021 12:29 pm, Bill Cole wrote:
Logically impossible. You don't have the headers yet when
smtpd_recipient_restrictions directives are evaluated.
If i move the "operation" to another stage like data or end_of_data is
there a way to invoke header checks based on recipient?
On 2021-07-13 at 12:14:50 UTC-0400 (Tue, 13 Jul 2021 12:14:50 -0400)
is rumored to have said:
> Is there a way to have header checks happen as a condition during
> smtpd_recipient_restrictions but not happen other times?
> Something like assign the header check to a restriction class which can
Is there a way to have header checks happen as a condition during
smtpd_recipient_restrictions but not happen other times?
Something like assign the header check to a restriction class which
can be called on during a check_recipient_access?
End goal is to conditionally run header matching/action
Is there a way to have header checks happen as a condition during
smtpd_recipient_restrictions but not happen other times?
Something like assign the header check to a restriction class which can
be called on during a check_recipient_access?
End goal is to conditionally run header matching/actio
51 matches
Mail list logo
