Re: Misconfiguration and documentation clarification help
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) Apr 18 19:34:21 transbay postfix/local[89631]: CC13326F54D2: to=<*carla xx localhost.transbay.net*>, orig_to=<*carla xx transpacific.net*>, relay=local, delay=606, delays=601/0.01/0/5.5, dsn=4.3.0, status=*deferred* (temporary failure) And that is with this in the tables (virtual users, local recipients, domains_we_host): transbay[729]# grep carla virtusers (virtual_alias_map) *carla xx transpacific.net carla@localhost* carla xx transbay.net carlax@localhost carla xx mail.transbay.net carlax@localhost transbay[730]# grep carla postfix.users (local_recipient_map) *carla@localhost user* carlax@localhost user *carla xx localhost.transbay.net user* carlax xx localhost.transbay.net user transbay[732]# grep trans domains_we_host (virtual_alias_domains) transbay.net mail.transbay.net lists.transbay.net smtp.transbay.net *transpacific.net* carla xx transbay.net goes to carlax@localhost, a phony user whose .forward says "|/usr/local/bin/slidemail carla", and "slidemail carla" takes stdin and appends it to /var/mail/carla. This is how I've had to fake delivery to users postfix is refusing to deliver to. carla@localhost (from carla xx transpacific.net) does NOT get piped though slidemail, instead it is supposed to be delivering directly to carla (user on the machine), and it seems unable to. As shown, "carla@localhost" and "carla xx localhost.transbay.net" are defined as valid existing recipients, so why is the mail being deferred? from postqueue -p: CC13326F54D2 33062 Thu Apr 18 19:24:14 bounce-46244_HTML-10579582-3993451-6167586-165793 xx bounce.email.vimeo.com (temporary failure) carla xx localhost.transbay.net This is affecting SOME users, but not all. == I am also getting this: B623A26F54C8 63627 Thu Apr 18 12:58:06 561-ZNP-897.0.10724.0.0.9819.9.4028766 xx bounce.restaurantbusinessonline.com *(User unknown in virtual alias table)* *lbafwd xx transbay.net* despite this: (local recipient map: the lbafwd items are stale from when "lbafwd" was in aliases => tec, gmail.) lbafwd@localhost user lbafwd xx localhost.transbay.net user *tec@localhos**t* *user** **tec xx localhost.transbay.net user* *(virtual alias map:)* *lbafwd xx transbay.net* *tec@localhost*,someone xx gmail.com The item will not flush from the queue, despite "lbafwd xx transbay.net" being available.
Re: Misconfiguration and documentation clarification help
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 Apr 18 19:34:15 transbay postfix/qmgr[88661]: CC13326F54D2: from=[bounce-46244_HTML-10579582-3993451-6167586-165793 ?! bounce.email.vimeo.com], size=33062, nrcpt=1 (queue active) Apr 18 19:34:21 transbay postfix/local[89631]: CC13326F54D2: to=[*carla ?! localhost.transbay.net*], orig_to=[*carla ?! transpacific.net*], relay=local, delay=606, delays=601/0.01/0/5.5, dsn=4.3.0, status=*deferred* (temporary failure) And that is with this in the tables (virtual users, local recipients, domains_we_host): transbay[729]# grep carla virtusers (virtual_alias_map) *carla ?! transpacific.net carla@localhost* carla ?! transbay.net carlax@localhost carla ?! mail.transbay.net carlax@localhost transbay[730]# grep carla postfix.users (local_recipient_map) *carla@localhost user* carlax@localhost user *carla ?! localhost.transbay.net user* carlax ?! localhost.transbay.net user transbay[732]# grep trans domains_we_host (virtual_alias_domains) transbay.net mail.transbay.net lists.transbay.net smtp.transbay.net *transpacific.net* carla ?! transbay.net goes to carlax@localhost, a phony user whose .forward says "|/usr/local/bin/slidemail carla", and "slidemail carla" takes stdin and appends it to /var/mail/carla. This is how I've had to fake delivery to users postfix is refusing to deliver to. carla@localhost (from carla ?! transpacific.net) does NOT get piped though slidemail, instead it is supposed to be delivering directly to carla (user on the machine), and it seems unable to. As shown, "carla@localhost" and "carla ?! localhost.transbay.net" are defined as valid existing recipients, so why is the mail being deferred? from postqueue -p: CC13326F54D2 33062 Thu Apr 18 19:24:14 bounce-46244_HTML-10579582-3993451-6167586-165793 ?! bounce.email.vimeo.com (temporary failure) carla ?! localhost.transbay.net This is affecting SOME users, but not all. == I am also getting this: B623A26F54C8 63627 Thu Apr 18 12:58:06 561-ZNP-897.0.10724.0.0.9819.9.4028766 ?! bounce.restaurantbusinessonline.com *(User unknown in virtual alias table)* *lbafwd ?! transbay.net* despite this: (local recipient map: the lbafwd items are stale from when "lbafwd" was in aliases =] tec, gmail.) lbafwd@localhost user lbafwd ?! localhost.transbay.net user *tec@localhos**t* *user** **tec ?! localhost.transbay.net user* *(virtual alias map:)* *lbafwd ?! transbay.net* *tec@localhost*,someone ?! gmail.com The item will not flush from the queue, despite "lbafwd ?! transbay.net" being available.
Re: Misconfiguration and documentation clarification help
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 censor. Maybe the thing is just so so clever that if I use "useratexample.com" it will leave me alone. Or did it eat that too? I should try that. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Misconfiguration and documentation clarification help
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/Postfix-Users-f2.html
Re: Misconfiguration and documentation clarification help
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. Yes ... it would be a lot easier if you simply subscribed to the mailing list instead of using a web frontend. After all, email is what you're trying to configure so a mailing list seems like an appropriate interface? Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Misconfiguration and documentation clarification help
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 might be due to the web interface being very public while the mailing list is more private.) It was when I found that the "hidden"s were clickable and popped up some odd interface offering to email the user that I figured it out. On 4/19/19 12:48 AM, Philip Paeps wrote: 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. Yes ... it would be a lot easier if you simply subscribed to the mailing list instead of using a web frontend. After all, email is what you're trying to configure so a mailing list seems like an appropriate interface? Philip
Re: TLS client certificates and auth external
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 identity is necessarily a good idea. Maybe it is safer to solve this problem without PKI-to-SASL cross-talk. I would expect the mapping to be indirect. That is, a table lookup key of either the client public key fingerprint to a SASL name (roughly what we have now, but with an explicit RHS indicating the desired SASL identity), or else the client's subject name in a standard (likely RFC2254) form, again mapped to the desired identity, provided the client certificate is from a trusted PKI issuer. Yes I agree. The proposed sasl provider dance is for a quick hack to not have to implement the client subject name table lookup. Emmanuel.
Big problem with this mailing list and Majordomo regarding DMARC
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 (forwarded) but not mine, with the SPF of postfix.org This looks something like this then : 168.100.1.7 ... NOT MY IP 1 reject fail fail prvtmail.net ... BUT MY HEADER postfix.org SPF FROM POSTFIX.ORG none prvtmail.net fail This is totally wrong and so my mails don't get delivered correctly it seems. Can you please get back to me on that?
Re: Big problem with this mailing list and Majordomo regarding DMARC
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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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-address header "correctly" to come from postfix list rather than my domain. so my posts are rejected by a lot of users. I am not sure if I want to change my policy and open world for spoofing just for a piece of software which cannot handle this correctly in 2019. but maybe I have to. how you mean you get dmarc pass from your own posts? you mean the one mail(post) itself you send or? because all other "forwarded" by majordomo should fail also if I correctly understand the problem that lies underneath. so you have dmarc to report only? On 19/04/2019 12:12, Benny Pedersen wrote: > 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
Re: Big problem with this mailing list and Majordomo regarding DMARC
Sign your email with DKIM. The Postfix list is DKIM-safe. Wietse
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 signature. -- Nick
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 DISABLE 168.100.1.4 DISABLE 168.100.1.7 DISABLE 2604:8d00:0:1::3DISABLE 2604:8d00:0:1::4DISABLE 2604:8d00:0:1::7DISABLE # grep milter main.cf smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_maps.cidr add ips to postscreen whitelist if you use rbl that block posstfix maillist
Re: Big problem with this mailing list and Majordomo regarding DMARC
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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=RFjoFU2lJVzkjZeWBGwFSeilqzQF8lu0j7X2EyRnK4U=; b=aLZdpa23z8loA2H4r1JNojxvVUuvddV5lYrQFfw4kQjbhLUXEu16ZKegbUiIQRLysy+eJ/ aaMKjIF7ySs2RnZxclXw5QioNE1e7tuz26owsY2fDP2di2qiYLlocXNyZv0YOWxqCxnQ+A S/b6tNvNa4yRAE5reMi79GgiosooHfTmZhNKh0y8FzN5WMSJ/eIBjcnHl3OkNy4tC5R2wKUy y7YgJoy+8eippeZlU6kurUo/neZ5np+DzLcNU8wlpIdhHOmrj57NMGC6woiYU+gxaBJvPW s7tMDQm3vaWFjcrgDR+Ff2HmfKwIkLTRiQhdA9wCtZ4ZYxFfnVTt3l5Cbubdkw== where is the other From ? and mime-version ? reducuce signed headers to what opendkim use, dont oversign all headers
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 list users with postfix sender IP 168.100.1.3, 168.100.1.4 or 168.100.1.7but applies the header from of my server, which of course does not validate anymore My mail 116.203.154.189 THIS IS MY SERVER IP, CORRECT 1 none pass pass prvtmail.net prvtmail.net pass def prvtmail.net pass MAJORDOMO FORWARDED 168.100.1.7 ... MAJORDOMO IP 1 reject fail fail prvtmail.net ... BUT MY HEADER postfix.org SPF FROM POSTFIX.ORG none prvtmail.net ... DKIM failed of course fail On 19/04/2019 13:36, Benny Pedersen wrote: > 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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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"; sign_headers = '(o)from:(o)sender:(o)reply-to:(o)subject:(o)date:(o)message-id:\ (o)to:(o)cc:(o)mime-version:(o)content-type:(o)content-transfer-encoding:\ resent-to:resent-cc:resent-from:resent-sender:resent-message-id:\ (o)in-reply-to:(o)references:list-id:list-owner:list-unsubscribe:\ list-subscribe:list-post:(o)openpgp:(o)autocrypt'; ... o are oversigned headers I will have to check this against opendkim then, thanks On 19/04/2019 13:42, Benny Pedersen wrote: > 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-type:content-type: > content-transfer-encoding:content-transfer-encoding: > in-reply-to:in-reply-to:references:references:openpgp:autocrypt; > bh=RFjoFU2lJVzkjZeWBGwFSeilqzQF8lu0j7X2EyRnK4U=; > b=aLZdpa23z8loA2H4r1JNojxvVUuvddV5lYrQFfw4kQjbhLUXEu16ZKegbUiIQRLysy+eJ/ > > aaMKjIF7ySs2RnZxclXw5QioNE1e7tuz26owsY2fDP2di2qiYLlocXNyZv0YOWxqCxnQ+A > > S/b6tNvNa4yRAE5reMi79GgiosooHfTmZhNKh0y8FzN5WMSJ/eIBjcnHl3OkNy4tC5R2wKUy > > y7YgJoy+8eippeZlU6kurUo/neZ5np+DzLcNU8wlpIdhHOmrj57NMGC6woiYU+gxaBJvPW > > s7tMDQm3vaWFjcrgDR+Ff2HmfKwIkLTRiQhdA9wCtZ4ZYxFfnVTt3l5Cbubdkw== > > where is the other From ? > > and mime-version ? > > reducuce signed headers to what opendkim use, dont oversign all headers
Re: Big problem with this mailing list and Majordomo regarding DMARC
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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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.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 > signature.
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 facing now. I now (for some time already) use a more relaxed sign_headers in my local.d/dkim_signing.conf sign_headers = 'from:to:subject:date:message-id:in-reply-to:references'; i.e. no oversigning and no "sender" in there. (I also have policy=none and send received reports to /dev/null but don't tell anyone! :) Cheers, Bernardo.
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 RFC6376 (opendkim standard) now and the problem should be gone here, too. /dev/null is always the nice way :) Cheers On 19/04/2019 15:48, B. Reino wrote: > 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 facing now. > I now (for some time already) use a more relaxed sign_headers in my > local.d/dkim_signing.conf > > sign_headers = 'from:to:subject:date:message-id:in-reply-to:references'; > > i.e. no oversigning and no "sender" in there. > > (I also have policy=none and send received reports to /dev/null but > don't tell anyone! :) > > Cheers, > Bernardo. >
Re: Big problem with this mailing list and Majordomo regarding DMARC
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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 here... I will change that accordingly to RFC6376 (opendkim standard) now and the problem should be gone here, too. /dev/null is always the nice way :) please reopen this one https://github.com/rspamd/rspamd/issues/1691 its not fixed yet
Re: TLS client certificates and auth external
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 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 identity is necessarily a good idea. Maybe it is safer to solve > > this problem without PKI-to-SASL cross-talk. > > At least in my case no SASL would be needed. For me a > relay_clientcerts able to list allowed validated CNs would be enough. > The SASL stuff will be handy for tie a "identity" to certificates and > assign additional rights/limits of course. One SASL-less option that I can think of is check_cname_access: map the CNAME to an action. Requires that the certificate is verified. Would that work? Thius approach avoids the mixing of PKI identities and SASL identities. Implementation note: this would require that check_cname_access looks up a quoted string if the CNAME contains spaces. The postnap command understands quoted strings as of Postfix 3.2. Wietse
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 mentioned above are user/MUA generated (.. I know Message-ID can be generated by MTA if the MUA sucks and doesn't do it itself). Care to clarify?
Re: Big problem with this mailing list and Majordomo regarding DMARC
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, 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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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-to and references Thanks for the clarification! Yet, "subjective" (or trade-off, etc.) does not mean "will be changed remotely", so I fail to see the issue here (and man 5 opendkim.conf does not mention it AFAICT..) Cheers.
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 problems ?
Re: Big problem with this mailing list and Majordomo regarding DMARC
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: > because the mailing list interprets them as commands :) and blocks the > > message>'; > > > > although they leave it open as "subjective" regarding message-id, > > in-reply-to and references > > Thanks for the clarification! > > Yet, "subjective" (or trade-off, etc.) does not mean "will be changed > remotely", so I fail to see the issue here (and man 5 opendkim.conf does > not mention it AFAICT..) 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. Scott K [1] https://tools.ietf.org/html/rfc6376#section-5
Re: Big problem with this mailing list and Majordomo regarding DMARC
* 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. AFAIK all of the headers I mentioned above > are user/MUA generated (.. I know Message-ID can be generated by MTA > if the MUA sucks and doesn't do it itself). Your header selection is quite alright, if a bit shorter than my own preferred list: Autocrypt, From, To, Subject, Date, Content-Language, Content-Type, In-Reply-To, Message-ID, References, User-Agent, X-Mailer The message ID should definitely be signed. Even if it is generated by the MTA, that should happen before the DKIM signature is crated. Otherwise I'd consider the MTA/DKIM pair misconfigured by the admin. -Ralph
Re: Big problem with this mailing list and Majordomo regarding DMARC
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
Re: Big problem with this mailing list and Majordomo regarding DMARC
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:resent-cc:resent-from:resent-date\ >> in-reply-to:references:> because the mailing list interprets them as commands :) and blocks the >> message>'; > > mailman changes reply-to, no ? > > is it time to let rspamd solve its own problems ?
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 then, if > changing reply-to > Or that RFC break Mailman, and many other long established methods of operation for mailing list. >From what I have seen from DKIM is that domains that implement it really should be required to tell their users that they should not be using any remailing service (like most mailing list) that don't adhere to some new DKIM rules, needed to avoid breaking the DKIM signature, even though following these rules will break some traditionally provided features, and may even force the list to break some laws (laws on mass mailings that REQUIRE instructions on how to unsubscribe be included in the message) -- Richard Damon
Re: TLS client certificates and auth external
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 identity is necessarily a good idea. Maybe it is safer to solve this problem without PKI-to-SASL cross-talk. I would expect the mapping to be indirect. That is, a table lookup key of either the client public key fingerprint to a SASL name (roughly what we have now, but with an explicit RHS indicating the desired SASL identity), or else the client's subject name in a standard (likely RFC2254) form, again mapped to the desired identity, provided the client certificate is from a trusted PKI issuer. Using a name instead of cert fingerprint also requires revocation checking. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: TLS client certificates and auth external
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 stuffing arbitrary PKI identities into a > >> SASL identity is necessarily a good idea. Maybe it is safer to solve > >> this problem without PKI-to-SASL cross-talk. > > > > I would expect the mapping to be indirect. That is, a table lookup > > key of either the client public key fingerprint to a SASL name (roughly > > what we have now, but with an explicit RHS indicating the desired SASL > > identity), or else the client's subject name in a standard (likely > > RFC2254) form, again mapped to the desired identity, provided the > > client certificate is from a trusted PKI issuer. > > 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 -> ersatz SASL login name By removing such a mapping, one can 'revoke' the privileges that were associated with the certificate. Wietse
Re: TLS client certificates and auth external
> 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 -> ersatz SASL login name > > By removing such a mapping, one can 'revoke' the privileges that > were associated with the certificate.' My thoughts exactly! We should probably document this: Note: No revocation checks are performed. To revoke privileges, remove the table entry matching a given certificate or "subject". As for "CN" matching, I'm concerned that multiple certificates can have the same CN, which is not required unique, especially if the certificates have different "O" or "OU" values. What's more likely to be unique is an rfc822Name subjectAlternative name, or the full subject DN. More recently, we also have SmtpUTF8Mailbox: https://tools.ietf.org/html/rfc8398#section-3 So I think that more thought needs to go into what lookup key or keys are extract from the candidate certificates. This may need to be configurable, or we could try: 1. The full subject DN (in RFC2854 form, suitably quoted). 2. Each rfc822Name SAN. 3. Each SmtpUTF8Mailbox (note U-label domain part). -- Viktor.
unknown tls certificate problem: EVP_MD_size:message digest is null
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 null:crypto/evp/evp_lib.c:316: I have tried to search google for this error, but I haven't been able to find anything. Can anybody explain it or knows what it means? Chris
Testing new server
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, Google & Outlook seem unable to connect via TLS. It looks like the initial handshakes are fine...but then nothing happens. If anyone wants to test - please try sending to the address "pubtest at danmarkreps.com". Thank you. -- Daniel
Re: TLS client certificates and auth external
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 convinced that stuffing arbitrary PKI identities into a SASL identity is necessarily a good idea. Maybe it is safer to solve this problem without PKI-to-SASL cross-talk. I would expect the mapping to be indirect. That is, a table lookup key of either the client public key fingerprint to a SASL name (roughly what we have now, but with an explicit RHS indicating the desired SASL identity), or else the client's subject name in a standard (likely RFC2254) form, again mapped to the desired identity, provided the client certificate is from a trusted PKI issuer. 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 -> ersatz SASL login name By removing such a mapping, one can 'revoke' the privileges that were associated with the certificate. 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? I think that people are asking for this feature because they just want to issue a new cert and *not* deal with any postfix map update. Maybe I'm missing something though. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: Testing new server
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 Gmail/Hotmail, unique to themselves, are expecting some responses from my server that they aren't getting...or I must have something filtering them at a lower level. This server was setup partially as a testbed for a new config. In particular, I'm trying ASSP in the "proper" manner, where ASSP only directly listens on port 25 - ports 465/587 are handled by Postfix initially. And that's been working fine - but now that I've actually enabled TLS in ASSP... brief deviation - I thought I had TLS enabled previously...trying to make hardenize happy showed that ASSP didn't have access to my certificates. Apparently my installation of certbot didn't allow read access to the necessary folders. Note to all - if you're going to use the "live" certs directly from any other program make sure you have proper read/enter access to the "live" and "archive" folders. Now that I've corrected that and am actually supporting STARTTLS...I have this problem. Does anyone see anything wrong via their logs or telnet? Otherwise either Gmail/Hotmail must have me blocked...or I'm blocking them and have to find where it's hiding. -- Daniel
Re: TLS client certificates and auth external
> 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 match by the key fingerprint until the old certificate is expired. Then go back to name checks. > I think that people are asking for this feature because they just want to > issue > a new cert and *not* deal with any postfix map update. CRLs don't make for reliable infrastructure. My view is that, pretending otherwise would be disservice to the Postfix user community. It is much easier to update the Postfix tables than to provision a working CRL infrastructure. I have no plans to spend any time working on CRL support to Postfix. -- -- Viktor.
Re: Testing new server
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 server no longer responds at all after the TLS handshake completes. Perhaps a firewall issue? You can ignore the certificate verification warnings, an empty list of trusted CAs means that no verification is expected. $ posttls-finger danmarkreps.com posttls-finger: Connected to smtp.danmarkreps.com[107.175.220.136]:25 posttls-finger: < 220 mail.danmarkreps.com ESMTP Postfix posttls-finger: > EHLO amnesiac.invalid posttls-finger: < 250-mail.danmarkreps.com posttls-finger: < 250-STARTTLS posttls-finger: < 250-SIZE 7 posttls-finger: < 250-VRFY posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250-DSN posttls-finger: < 250 NOOP posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: Matched subjectAltName: danmarkreps.com posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: subjectAltName: host.danmarkreps.com posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: subjectAltName: imap.danmarkreps.com posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: subjectAltName: mail.danmarkreps.com posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: Matched subjectAltName: smtp.danmarkreps.com posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: subjectAltName: www.danmarkreps.com posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25 CommonName danmarkreps.com posttls-finger: certificate verification failed for smtp.danmarkreps.com[107.175.220.136]:25: untrusted issuer /O=Digital Signature Trust Co./CN=DST Root CA X3 posttls-finger: smtp.danmarkreps.com[107.175.220.136]:25: subject_CN=danmarkreps.com, issuer_CN=Let's Encrypt Authority X3, fingerprint=E2:D2:9F:04:A5:1B:E8:8A:EA:1C:DA:67:81:01:D4:FD:01:97:6B:33, pkey_fingerprint=A0:52:8A:C6:88:89:C0:C1:43:72:9D:29:D5:C2:0D:BD:5F:9B:BC:D6 posttls-finger: Untrusted TLS connection established to smtp.danmarkreps.com[107.175.220.136]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 posttls-finger: > EHLO amnesiac.invalid posttls-finger: timeout while sending EHLO posttls-finger: > QUIT posttls-finger: warning: timeout while sending QUIT command -- Viktor.
Re: TLS client certificates and auth external
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? > Delete the name match, and match by the key fingerprint until the old certificate is expired. Then go back to name checks. Sounds complicated to get that right. I think that people are asking for this feature because they just want to issue a new cert and *not* deal with any postfix map update. CRLs don't make for reliable infrastructure. My view is that, pretending otherwise would be disservice to the Postfix user community. It is much easier to update the Postfix tables than to provision a working CRL infrastructure. I have no plans to spend any time working on CRL support to Postfix. Fair enough. Personally I'd continue to use fingerprints anyway. I'm rather questioning whether it's worth the effort to implement something else. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: TLS client certificates and auth external
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 associated with the certificate.'
>
> My thoughts exactly! We should probably document this:
>
> Note: No revocation checks are performed. To revoke privileges,
> remove the table entry matching a given certificate or "subject".
>
> As for "CN" matching, I'm concerned that multiple certificates can have
> the same CN, which is not required unique, especially if the certificates
> have different "O" or "OU" values. What's more likely to be unique is
> an rfc822Name subjectAlternative name, or the full subject DN. More
> recently, we also have SmtpUTF8Mailbox:
>
> https://tools.ietf.org/html/rfc8398#section-3
>
> So I think that more thought needs to go into what lookup key or
> keys are extract from the candidate certificates. This may need
> to be configurable, or we could try:
>
> 1. The full subject DN (in RFC2854 form, suitably quoted).
> 2. Each rfc822Name SAN.
> 3. Each SmtpUTF8Mailbox (note U-label domain part).
Here is a strawman user interface, similar to smtpd_milters:
smtpd_mumble_restrictions =
...
check_access { maptype:mapname, { search = rfc822name, cccert_dn } }
...
where the 'search' attribute specifies a list with one or more of
rfc822name, cccert_dn, ccert_key_fingerprint, and so on.
The check_access 'search' attribute would not need to be specific
to TLS at all; the search list could specify other things:
check_access { maptype:mapname, search=client }
which is equivalent to "check_client_access maptype:mapname".
Or we could ignore the opportunity for generalization and call
it check_tls_access.
The only real work is to implement support for a set of named
integers (internally, a vector of NAME_CODE results). The rest of
the work would be writing trivial wrappers, and documenting this.
Wietse
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 because RFC6376 actually recommends including the Sender header: From 5.4 INFORMATIVE OPERATIONS NOTE: "For this reason, signing fields present in the message such as Date, Subject, Reply-To, *Sender*, and all MIME header fields are highly advised." (emphasis mine)
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 >> signature. > > This is going to be an ongoing problem because RFC6376 actually > recommends including the Sender header: > > From 5.4 INFORMATIVE OPERATIONS NOTE: > > "For this reason, signing fields present in the message such as Date, > Subject, Reply-To, *Sender*, and all MIME header fields are highly > advised." (emphasis mine) > 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 through mailing lists. Effectively, if you decide to use DKIM to protect your domain's outgoing email, then you really need to tell your users about the issue with mailing lists, as the choice to use DKIM basically says that most mailing list should be off limits to your users, as it is very common for mailing lists to break the DKIM signature, so it really is YOUR problem to adjust your DKIM settings and Authorized Usage Policy to make your system work for your users. I have to regularly tell users of a mailing list that I run that the reason the list removes their email address out of the From: field is that they are using a broken email system that isn't compatible with the use of mailing list. 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 general emails with traditional mailing lists. -- Richard Damon
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 through mailing lists. Effectively, if you decide to use DKIM to protect your domain's outgoing email, then you really need to tell your users about the issue with mailing lists, as the choice to use DKIM basically says that most mailing list should be off limits to your users, as it is very common for mailing lists to break the DKIM signature, so it really is YOUR problem to adjust your DKIM settings and Authorized Usage Policy to make your system work for your users. I have to regularly tell users of a mailing list that I run that the reason the list removes their email address out of the From: field is that they are using a broken email system that isn't compatible with the use of mailing list. 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 general emails with traditional mailing lists. 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 major ESPs that enforce DMARC will end up either not getting a large portion of messages sent to the list, or have to hunt through Spam to find them. At the end of the day this means that the practical implications of this are problematic at best. It means that I also take issue when Wietse ways that the mailing list is DKIM compliant, because clearly that statement is based on the DKIM signature not including certain headers that the mailing list alters. What might be more accurate is to say that the mailing list is DKIM compliant just as long as the DKIM signature doesn't include certain headers, some of which are actually recommended to be included by the relevant RFCs. When looked at in that light it becomes more clear that the DKIM compliance of the mailing list is spotty at best. Peter
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 general emails with traditional mailing lists. Sadly, no. See https://www.rfc-editor.org/info/std76 -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 major ESPs that enforce DMARC will end up either not getting a large portion of messages sent to the list, or have to hunt through Spam to find them. At the end of the day this means that the practical implications of this are problematic at best. It means that I also take issue when Wietse ways that the mailing list is DKIM compliant, because clearly that statement is based on the DKIM signature not including certain headers that the mailing list alters. What might be more accurate is to say that the mailing list is DKIM compliant just as long as the DKIM signature doesn't include certain headers, some of which are actually recommended to be included by the relevant RFCs. When looked at in that light it becomes more clear that the DKIM compliance of the mailing list is spotty at best. Just as a follow on, I've been finding that taking the approach of trying to pass on messages in a mailing list unaltered without them being marked as SPAM is in this day and age becoming increasingly difficult and perhaps this approach should be abandoned as I believe the situation will only get worse in the future. Instead of taking the approach that we can pass on these messages unaltered and keep the original authenticity intact, perhaps we should intead take the approach that we are not just passing these messages on, but rather re-authoring the messages so that they originate from the mailing list itself rather than from the original sender. This essentially requires taking ownership of the messages so that it becomes the mailing lists own reputation that defines deliver-ability rather than that of the original sender. This is the approach being taken by an increasing number of MLMs (such as GNU MailMan). Fortunately we don't actually have to switch to a modern MLM in order to take this approach as it can be achieved largely through the postfix backend without the help of the MLM: * Use header_checks to strip out any existing DKIM signatures and rewrite the From: header. * Use canonical_maps or sender_canonical_maps to rewrite the envelope sender (probably not needed here or already implemented as the envelope sender is indeed already rewritten for this list). * DKIM: sign the resulting messages with our own DKIM signature, after making any changes to the message. * Anti-SPAM: I have yet to see much of any SPAM sent through this list, so I assume that the Anti-SPAM solution on it is already quite good, but as a general rule, since we would be taking complete ownership of any posts sent to the list it pays to not be doing so for a bunch of SPAM. While I do understand the ideal of keeping messages pristine and unaltered, I think the current and future email landscapes with major ESPs is simply going to make that approach increasingly impractical. Peter
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 protection makes >> sense. These sorts of emails also aren't sent through mailing lists. >> >> Effectively, if you decide to use DKIM to protect your domain's >outgoing >> email, then you really need to tell your users about the issue with >> mailing lists, as the choice to use DKIM basically says that most >> mailing list should be off limits to your users, as it is very common >> for mailing lists to break the DKIM signature, so it really is YOUR >> problem to adjust your DKIM settings and Authorized Usage Policy to >make >> your system work for your users. I have to regularly tell users of a >> mailing list that I run that the reason the list removes their email >> address out of the From: field is that they are using a broken email >> system that isn't compatible with the use of mailing list. >> >> 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 general emails with traditional mailing >lists. > >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 major ESPs that enforce DMARC > >will end up either not getting a large portion of messages sent to the >list, or have to hunt through Spam to find them. At the end of the day > >this means that the practical implications of this are problematic at >best. > >It means that I also take issue when Wietse ways that the mailing list >is DKIM compliant, because clearly that statement is based on the DKIM >signature not including certain headers that the mailing list alters. >What might be more accurate is to say that the mailing list is DKIM >compliant just as long as the DKIM signature doesn't include certain >headers, some of which are actually recommended to be included by the >relevant RFCs. When looked at in that light it becomes more clear that > >the DKIM compliance of the mailing list is spotty at best. 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. Scott K
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 appropriate standards documents, and when they don't it's their fault for actually following the standards? Ummm, ok. Peter
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 best practice instead > >of what is recommended in the appropriate standards documents, and when > >they don't it's their fault for actually following the standards? >Ummm, ok. Sigh. No. That's not what I wrote at all. 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 there. Scott K
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 there. ...and I never said anything about adding it either. We're talking about what fields to sign, not whether they should be added or exist in the message prior to signing. RFC 6376 does go on to say that headers can be signed that are not present to enforce that they not be added later. 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. But this is just one example of where a header might be signed and then is later added or altered by the mailing list, thereby invalidating the signature. I'm sure there have been others as I regularly see mail from this list end up in Spam and my point remains that this seems to be an issue that will only get worse in the future, not better. At the end of the day, messages from this list are ending up in people's Spam folder, or are not being delivered at all. We can go on all day pointing the finger at the sender but that really won't solve the issue in general, because there will always be another sender who breaks the rules or doesn't get it, or can't actually control this stuff for their email. Peter
Re: Big problem with this mailing list and Majordomo regarding DMARC
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 transmitting mails to a mailing list on your > > behalf, it shouldn't be there. > ...and I never said anything about adding it either. We're talking > about what fields to sign, not whether they should be added or exist in > the message prior to signing. RFC 6376 does go on to say that headers > can be signed that are not present to enforce that they not be added later. > > 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. > > But this is just one example of where a header might be signed and then > is later added or altered by the mailing list, thereby invalidating the > signature. I'm sure there have been others as I regularly see mail from > this list end up in Spam and my point remains that this seems to be an > issue that will only get worse in the future, not better. > > At the end of the day, messages from this list are ending up in people's > Spam folder, or are not being delivered at all. We can go on all day > pointing the finger at the sender but that really won't solve the issue > in general, because there will always be another sender who breaks the > rules or doesn't get it, or can't actually control this stuff for their > email. If you signed a non-existent sender field and send mail to a mailing list that (not atypically adds it) and your signature is broken, look in the mirror for the source of the problem. It's neither the mailing list nor the RFCs. I'm done. Scott K
Re: Big problem with this mailing list and Majordomo regarding DMARC
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-mumble header they add generally is sender. Ig you are signing a non-existent sender in a message to a list, that is a mistake. If you are adding a sender header to a message to a list and signing with that header, that is a mistake. Or, you can insist you are right and break list messages. Your call. -- Major Strasser has been shot. Round up the usual suspects.
