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 non-list-mumbl
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 th
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 b
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 app
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 prote
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 maj
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 g
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 t
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
>> signatur
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 be
Viktor Dukhovni:
> > Cert revocation is not needed, as long as there is an an explicit
> > mapping like:
> >
> >certificate identity -> permit/etc action
> >certificate identity -> ersatz SASL login name
> >
> > By removing such a mapping, one can 'revoke' the privileges that
> > were ass
On 4/20/19 1:09 AM, Viktor Dukhovni wrote:
On Apr 19, 2019, at 6:42 PM, Michael Ströder wrote:
If a cert's key get compromised (e.g. laptop lost/stolen) I expect
the user's cert to be revoked and a new cert to be issued for the
*same* subject name. How to deal with that without revocation
check
On Fri, Apr 19, 2019 at 03:35:03PM -0700, Daniel Miller wrote:
> I've setup a new server - and it *was* working fine...but then I enabled
> a few more settings... I was attempting to make hardenize.com happy
> (and I'm glad I did - it exposed some stupid mistakes on my part).
But now your serv
> On Apr 19, 2019, at 6:42 PM, Michael Ströder wrote:
>
> If a cert's key get compromised (e.g. laptop lost/stolen) I expect the user's
> cert to be revoked and a new cert to be issued for the *same* subject name.
> How to deal with that without revocation check?
Delete the name match, and
On 4/19/2019 3:35 PM, Daniel Miller wrote:
If anyone wants to test - please try sending to the address "pubtest at
danmarkreps.com".
Well...I've gotten at least one test message (thank you Lazy G!) so I
can't be *completely* broken.
Which leaves me with two likely possibilities - either
On 4/19/19 7:10 PM, Wietse Venema wrote:
Michael Str?der:
On 4/18/19 9:45 PM, Viktor Dukhovni wrote:
On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).
I am not convinc
I've setup a new server - and it *was* working fine...but then I enabled
a few more settings... I was attempting to make hardenize.com happy
(and I'm glad I did - it exposed some stupid mistakes on my part).
I'm able to send without issue and receive from most other servers. But
in particular
Hi,
I am using a letsencrypt tls cert and whenever I receive email, I get
the following error. Is this a problem with my certificate? Or with
the configuration or something??
postfix/smtpd[526]: warning: TLS library problem:
error:060A209F:digital envelope routines:EVP_MD_size:message digest is
n
> On Apr 19, 2019, at 1:10 PM, Wietse Venema wrote:
>
>> Using a name instead of cert fingerprint also requires revocation checking.
>
> Cert revocation is not needed, as long as there is an an explicit
> mapping like:
>
>certificate identity -> permit/etc action
>certificate identity -
Michael Str?der:
> On 4/18/19 9:45 PM, Viktor Dukhovni wrote:
> >> On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
> >>
> >> Eventually there will be a postfix--nonprod release that combines
> >> all the code (jay) and none of the guarantees (bleh).
> >>
> >> I am not convinced that stuffin
On 4/18/19 9:45 PM, Viktor Dukhovni wrote:
On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).
I am not convinced that stuffing arbitrary PKI identities into a
SASL identi
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 rfc
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:\
>> to:cc:resent-to
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. AF
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: > be
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 pro
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,
in-reply
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, B
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 mentione
lst_ho...@kwsoft.de:
>
> Zitat von Wietse Venema :
>
> > lst_ho...@kwsoft.de:
> >> What is the way to go to take part of the feature development? I looks
> >> like we need a slight modification of the auth external as described.
> >
> > Mailin glist discussions.
> >
> > Eventually there will be a
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 to
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 f
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:
>>
>> prvtmail.ne
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 = "header";
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:
content-
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
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
from
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 (forward
Le 18/04/2019 à 21:45, Viktor Dukhovni a écrit :
On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).
I am not convinced that stuffing arbitrary PKI identities into a
SASL
I am subscribed to the mailing list. I was using the web interface
because errors in my mail system
ate most of today's list traffic to me and I wanted to be sure I was up
to date. It should have occurred
to me that the replacements weren't the list's doing (I probably
reasoned that the hiding m
On 2019-04-19 00:28:31 (-0700), Eric Dynamic wrote:
Ok, it's nabble doing it (suppressing anything that could be an email when
viewing the postfix archives on their service.) People receiving the email
(half dozen or so by now) have probably received the markup I intended.
Sorry for my confusion.
Ok, it's nabble doing it (suppressing anything that could be an email when
viewing the postfix archives on their service.) People receiving the email
(half dozen or so by now) have probably received the markup I intended.
Sorry for my confusion.
--
Sent from: http://postfix.1071664.n5.nabble.com
God Dammit, what do I have to do to list human-parseable text in contexts
where email addresses would be found? I feel like I'm dealing with an editor
that writes "e" in place of any vowel I use. My diagnostics are not
understandable if I can't write things out. I've never seen such a pest of a
cen
Sorry for the repost, but "[mail hidden]" wiped out what I was trying to
show from the logs.
Damn, the thing is insistent. I have replaced "@" with " at " and then "
xx " to no avail!
I am going to replace all "<>" with "[]" and all @ with ?! in hopes to
defeat the scanner.
==
This happens
Sorry for the repost, but [mail hidden] wiped out what I was trying to
show from the logs.
I have replaced all email addresses with "user xx domain".
==
This happens
Apr 18 19:34:15 transbay postfix/qmgr[88661]: CC13326F54D2:
from=bounce.email.vimeo.com>, size=33062, nrcpt=1 (queue active)
Ap
55 matches
Mail list logo
