On Sun, 21 Apr 2019 at 13:16, Benny Pedersen wrote:
> Dominic Raferd skrev den 2019-04-20 12:02:
> > On Fri, 19 Apr 2019 at 14:11, Benny Pedersen wrote:
> >
> >> i have now disabled milters from trusted maillists ips
> >
> > How did you do this? It might help me. I have missed some of this
> >
Dominic Raferd skrev den 2019-04-20 12:02:
On Fri, 19 Apr 2019 at 14:11, Benny Pedersen wrote:
i have now disabled milters from trusted maillists ips
How did you do this? It might help me. I have missed some of this
thread because OP's mails are blocked (correctly of course) by my
* Bill Cole:
> There's no need to watch, if you can imagine what it would look like
> from the description in the specification of how to include non-existent
> headers in a signature.
I'm aware of RFC 4871 section 5.4. "The From header field MUST be
signed", so here's where signing
On 20 Apr 2019, at 6:38, Ralph Seichter wrote:
Signing a non-existing (!) header. Right. Mind if I watch? :-)
There's no need to watch, if you can imagine what it would look like
from the description in the specification of how to include non-existent
headers in a signature.
The purpose
On 20/04/2019 14:59, Richard Damon wrote:
> On 4/20/19 8:08 AM, Reto wrote:
>> On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
>>> Where the issue comes is with DMARC, which restricts the DKIM protocol
>>> to be aligned with the From line of the message, and thus the MLM can't
On 4/20/19 8:08 AM, Reto wrote:
> On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
>> Where the issue comes is with DMARC, which restricts the DKIM protocol
>> to be aligned with the From line of the message, and thus the MLM can't
>> make the message pass the DMARC settings of the
On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
> Where the issue comes is with DMARC, which restricts the DKIM protocol
> to be aligned with the From line of the message, and thus the MLM can't
> make the message pass the DMARC settings of the sending domain. It is
> DMARC which
On 4/19/19 11:22 PM, Bill Cole wrote:
> On 19 Apr 2019, at 22:50, Richard Damon wrote:
>
>> Note also, these RFCs are just Standards Track, which says that they are
>> not yet 'full standards' but still evolving, and I believe that one of
>> the issues that needs to be worked out is to figure out
* Peter:
> Granted in this particular case, and given what Sender is for, it
> probably shouldn't be signed if it's not present, but the RFC does not
> make that explicitly clear, and I would not hold someone at fault for
> signing the Sender header based on what that RFC says.
Signing a
Dominic, you should get the mails now, don't you?
On 20 April 2019 12:04:30 Dominic Raferd wrote:
On Fri, 19 Apr 2019 at 14:11, Benny Pedersen wrote:
i have now disabled milters from trusted maillists ips
How did you do this? It might help me. I have missed some of this thread
because
On Sat, 20 Apr 2019 at 11:18, TG Servers wrote:
>
> Dominic, you should get the mails now, don't you?
>
> On 20 April 2019 12:04:30 Dominic Raferd wrote:
>
>> On Fri, 19 Apr 2019 at 14:11, Benny Pedersen wrote:
>>
>>> i have now disabled milters from trusted maillists ips
>>>
>>
>> How did you
On Fri, 19 Apr 2019 at 14:11, Benny Pedersen wrote:
> i have now disabled milters from trusted maillists ips
>
How did you do this? It might help me. I have missed some of this thread
because OP's mails are blocked (correctly of course) by my opendmarc.
On 19 Apr 2019, at 23:04, Peter wrote:
> But this is just one example of where a header might be signed and then is
> later added or altered by the mailing list,
The only headers that mailing lists often alter are subject (though i think
that is dying off, hopefully) and the only
On Saturday, April 20, 2019 05:04:24 PM Peter wrote:
> On 20/04/19 4:46 PM, Scott Kitterman wrote:
> > RFC 6376 suggests signing the sender field if present. It says nothing
> > about adding it. For that you want RFC 5322, Section 3.6.2. (Originator
> > Fields).
> >
> > Unless a third party is
On 20/04/19 4:46 PM, Scott Kitterman wrote:
RFC 6376 suggests signing the sender field if present. It says nothing about
adding it. For that you want RFC 5322, Section 3.6.2. (Originator Fields).
Unless a third party is transmitting mails to a mailing list on your behalf, it
shouldn't be
On April 20, 2019 4:23:09 AM UTC, Peter wrote:
>On 20/04/19 3:57 PM, Scott Kitterman wrote:
>> Not at all. The unusual aspect of this case is the originator
>including Sender in the mail sent to the list. Don't do that and it's
>all fine.
>
>So we should expect people to do what we think is
On 20/04/19 3:57 PM, Scott Kitterman wrote:
Not at all. The unusual aspect of this case is the originator including Sender
in the mail sent to the list. Don't do that and it's all fine.
So we should expect people to do what we think is best practice instead
of what is recommended in the
On April 20, 2019 3:15:18 AM UTC, Peter wrote:
>On 20/04/19 2:50 PM, Richard Damon wrote:
>> If you look at the background behind DKIM, one of the major impetuses
>> was protecting transactional emails, and protection from attacks like
>> phishing. For these sorts of emails, that stricter
On 20/04/19 3:15 PM, Peter wrote:
I'm not disagreeing with any of this. It simply boils down to that when
a current RFC recommends a certain practice you shouldn't be surprised
that people will follow that recommendation. What then follows is that
people who use google, microsoft or other
On 19 Apr 2019, at 22:50, Richard Damon wrote:
> Note also, these RFCs are just Standards Track, which says that they are
> not yet 'full standards' but still evolving, and I believe that one of
> the issues that needs to be worked out is to figure out how to improve
> their interoperability for
On 20/04/19 2:50 PM, Richard Damon wrote:
If you look at the background behind DKIM, one of the major impetuses
was protecting transactional emails, and protection from attacks like
phishing. For these sorts of emails, that stricter protection makes
sense. These sorts of emails also aren't sent
On 4/19/19 10:04 PM, Peter wrote:
> On 19/04/19 11:16 PM, Nick wrote:
>> You might want to consider reducing the list of headers in your DKIM
>> signatures. E.g. your signed-headers list includes 'sender' but the
>> mailing list adds its own 'sender', which is enough to invalidate your
>>
On 19/04/19 11:16 PM, Nick wrote:
You might want to consider reducing the list of headers in your DKIM
signatures. E.g. your signed-headers list includes 'sender' but the
mailing list adds its own 'sender', which is enough to invalidate your
signature.
This is going to be an ongoing problem
On 4/19/19 12:00 PM, Benny Pedersen wrote:
> Scott Kitterman skrev den 2019-04-19 17:48:
>
>> I'd suggest reading RFC 6376, Section 5.4 (Determine the Header
>> Fields to
>> Sign) [1] directly. I think it's advice holds up reasonably well.
>
> thanks for link, its just that mailman breaks that
yes it seems mailman changes reply-to, I just took the fields out of
RFC6376 now...
On 19/04/2019 17:47, Benny Pedersen wrote:
> TG Servers skrev den 2019-04-19 16:48:
>> according to RFC this would be the full list for rspamd
>>
>> sign_headers = 'from:reply-to:subject:date:\
>>
Scott Kitterman skrev den 2019-04-19 17:48:
I'd suggest reading RFC 6376, Section 5.4 (Determine the Header Fields
to
Sign) [1] directly. I think it's advice holds up reasonably well.
thanks for link, its just that mailman breaks that rfc then, if changing
reply-to
* B. Reino:
> On Fri, 19 Apr 2019, Benny Pedersen wrote:
>
>> B. Reino skrev den 2019-04-19 15:48:
>>
>>> sign_headers = 'from:to:subject:date:message-id:in-reply-to:references';
>>
>> man 5 opendkim.conf
>>
>> dont sign headers that are added or changed remotely
>
> I'm not sure I follow here.
On Friday, April 19, 2019 05:38:08 PM B. Reino wrote:
> On Fri, 19 Apr 2019, TG Servers wrote:
> > according to RFC this would be the full list for rspamd
> >
> > sign_headers = 'from:reply-to:subject:date:\
> > to:cc:resent-to:resent-cc:resent-from:resent-date\
> > in-reply-to:references: >
TG Servers skrev den 2019-04-19 16:48:
according to RFC this would be the full list for rspamd
sign_headers = 'from:reply-to:subject:date:\
to:cc:resent-to:resent-cc:resent-from:resent-date\
in-reply-to:references:';
mailman changes reply-to, no ?
is it time to let rspamd solve its own
On Fri, 19 Apr 2019, TG Servers wrote:
according to RFC this would be the full list for rspamd
sign_headers = 'from:reply-to:subject:date:\
to:cc:resent-to:resent-cc:resent-from:resent-date\
in-reply-to:references:';
although they leave it open as "subjective" regarding message-id,
according to RFC this would be the full list for rspamd
sign_headers = 'from:reply-to:subject:date:\
to:cc:resent-to:resent-cc:resent-from:resent-date\
in-reply-to:references:';
although they leave it open as "subjective" regarding message-id,
in-reply-to and references
On 19/04/2019 16:13,
On Fri, 19 Apr 2019, Benny Pedersen wrote:
B. Reino skrev den 2019-04-19 15:48:
sign_headers = 'from:to:subject:date:message-id:in-reply-to:references';
man 5 opendkim.conf
dont sign headers that are added or changed remotely
I'm not sure I follow here. AFAIK all of the headers I
TG Servers skrev den 2019-04-19 15:56:
Bernardo,
yes, the problem is the defaults rspamd is using don't correspond to
RFC6376, which is itself from 2011 but rather respect 4871 which is
older and was obsoleted by RFC6376.
Of course one is responsible himself but more sane defaults would be
nice
B. Reino skrev den 2019-04-19 15:48:
sign_headers =
'from:to:subject:date:message-id:in-reply-to:references';
man 5 opendkim.conf
dont sign headers that are added or changed remotely
Bernardo,
yes, the problem is the defaults rspamd is using don't correspond to
RFC6376, which is itself from 2011 but rather respect 4871 which is
older and was obsoleted by RFC6376.
Of course one is responsible himself but more sane defaults would be
nice here...
I will change that accordingly
On Fri, 19 Apr 2019, TG Servers wrote:
Yes thanks Nick I am signing with rspamd and will have to check the
signed headers there
as this seems not compliant, I already checked that from the other
mails, thanks for the hint to you, too
I also use rspamd, and had exactly the same problem you're
Yes thanks Nick I am signing with rspamd and will have to check the
signed headers there
as this seems not compliant, I already checked that from the other
mails, thanks for the hint to you, too
On 19/04/2019 13:16, Nick wrote:
> On 2019-04-19 10:43 BST, TG Servers wrote:
>>
>>
TG Servers skrev den 2019-04-19 13:50:
The problem is the header that is appended by majordomo it seems
according to this
https://outofcontrol.ca/blog/patch-majordomo-to-work-with-dmarc
and you still sign sender header ?
no more help from me
I am signing with rspamd, will have to check the options there
# If true, multiple from headers are allowed (but only first is used)
allow_hdrfrom_multiple = false;
# Domain to use for DKIM signing: can be "header" (MIME From),
"envelope" (SMTP From) or "auth" (SMTP username)
use_domain =
The problem is the header that is appended by majordomo it seems
according to this
https://outofcontrol.ca/blog/patch-majordomo-to-work-with-dmarc
The postfix sender IP from my mail server is 116.203.154.189 which is
verified correctly against DKIM and SPF
Then majordomo forwards the mails to the
TG Servers skrev den 2019-04-19 12:45:
thanks for your reply.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=prvtmail.net;
s=def; t=1555670709;
h=from:from:sender:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:mime-version:mime-version:
Wietse Venema skrev den 2019-04-19 13:05:
Sign your email with DKIM. The Postfix list is DKIM-safe.
is there a diff on postfix sender ips ?
on 2604:8d00:0:1::7 i get DKIM_ADSP_ALL
on 168.100.1.3 i get DKIM_VALID_AU
TG Servers skrev den 2019-04-19 12:45:
thanks for your reply.
I get dmarc pass from everywhere normally and also from every tool.
this
is a majordomo problem
well i dont care :=)
# cat /etc/postfix/smtpd_milters_map.cidr
#
# postfix maillist disable all milters
168.100.1.3
On 2019-04-19 10:43 BST, TG Servers wrote:
>
> prvtmail.net
> fail
>
You might want to consider reducing the list of headers in your DKIM
signatures. E.g. your signed-headers list includes 'sender' but the
mailing list adds its own 'sender', which is enough to invalidate your
Sign your email with DKIM. The Postfix list is DKIM-safe.
Wietse
thanks for your reply.
I get dmarc pass from everywhere normally and also from every tool. this
is a majordomo problem because with other lists that are not on
majordomo there is no problem I can see. there are also articles
existing regarding this "bug" I saw now. it just does not rewrite the
change to dmarc policy away from reject
i get dmarc pass from my own posts, but i have now dissabled milters from
trusted maillists ips
all the best, problem is solved if and when openarc and opendmarc test if
its openarc sealed
Hi,
since I first tposted yesterday to this mailing list I got 100s of
rejected DMARC reports because Majordomo is not able to or configured
correctly to handle DMARC records.
The headers are not re-written correctly and so DKIM from my mail is
expected in 100s of mails from different IPs
48 matches
Mail list logo
