[pfx] Re: DNSBL rank log messages after HANGUP
Thursday, March 7, 2024, 3:58:26 PM, Viktor Dukhovni via Postfix-users wrote: > On Thu, Mar 07, 2024 at 01:06:53PM +1100, Phil Biggs via Postfix-users wrote: >> Today I noticed that, occasionally, I see a syslog message stating "blocked >> using zen.spamhaus..." but no matching "DNSBL rank ..." message. >> >> A couple of examples from the past two days: >> >> postfix/postscreen 84893 - - CONNECT from [43.157.61.211]:30092 to >> [192.168.11.2]:25 >> postfix/dnsblog 84894 - - addr 43.157.61.211 listed by domain >> zen.spamhaus.org as 127.0.0.11 >> postfix/postscreen 84893 - - HANGUP after 3.2 from [43.157.61.211]:30092 in >> tests before SMTP handshake > > - >> postfix/postscreen 84893 - - DISCONNECT [43.157.61.211]:30092 >> >> Some other syslog records do have the DNSBL rank. For example: >> >> postfix/postscreen 86907 - - CONNECT from [185.242.226.22]:49012 to >> [192.168.11.2]:25 >> postfix/dnsblog 86910 - - addr 185.242.226.22 listed by domain >> zen.spamhaus.org as 127.0.0.3 >> postfix/postscreen 86907 - - DNSBL rank 2 for [185.242.226.22]:49012 >> postfix/postscreen 86907 - - HANGUP after 0.8 from [185.242.226.22]:49012 in >> tests after SMTP handshake > > > The client hung up too early for a rank to be logged. Thank you, Viktor. I completely missed that before/after difference. -- Cheers, Phil ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
On Wed, Mar 06, 2024, Wietse Venema via Postfix-users wrote: > > Again, Postfix does not store line terminators, not when email comes > > from UNIX tool with \n, via SMTP with \r\n, or encapsulated as > > netstrings which uses neither. > In headers that Postfix sends to a milter. I may want to change that > or at least make it configurable with an appropriate default. AFAICT the libmilter docs define the line endings: libmilter/docs/xxfi_header.html |headerv |Header field value. The content of the header may | ||include folded white space, i.e., multiple lines| ||with following white space where lines are separated| ||by LF (not CRLF). The trailing line terminator | ||(CRLF) is removed. Changing that would probably break compatibility for milters. > I just checked what happens with bodies. There, the Postfix Milter > client is hard coded to send lines ending in "\r\n". libmilter/docs/xxfi_body.html * End-of-lines are represented as received from SMTP (normally CRLF). ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: improving SRS support
On Wed, Mar 06, 2024 at 07:30:01PM -0500, Christophe Kalt via Postfix-users wrote: > Hi, > > The two options I've seen for implementing SRS are milter and > [sender_]canonical_maps but it seems to me that neither are a good fit when > rewriting the envelope From as they happen early on (smtpd and cleanup > specifically) and before Postfix knows where the mail is going. > > That's a bit of a problem as rewriting the sender only makes sense if the > mail is being sent over SMTP (and even then, it would be great to have more > control as it is not always desirable). Looking for another option, the > closest seems to be smtp_generic_maps except that it rewrites both envelope > and header Froms. > > I suspect this could easily be adjusted with a new smtp_generic_classes > parameter (similar to [sender_]canonical_classes) ? You might already know about this, but postforward is good for doing SRS for specific addresses but there is static config (in /etc/aliases) so it's only good for setups that don't change much (unless you automate config updates). postsrsd wants to rewrite everything, even local delivery, but postforward can limit it to just things that get sent to remote servers. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DNSBL rank log messages after HANGUP
On Thu, Mar 07, 2024 at 01:06:53PM +1100, Phil Biggs via Postfix-users wrote: > Today I noticed that, occasionally, I see a syslog message stating "blocked > using zen.spamhaus..." but no matching "DNSBL rank ..." message. > > A couple of examples from the past two days: > > postfix/postscreen 84893 - - CONNECT from [43.157.61.211]:30092 to > [192.168.11.2]:25 > postfix/dnsblog 84894 - - addr 43.157.61.211 listed by domain > zen.spamhaus.org as 127.0.0.11 > postfix/postscreen 84893 - - HANGUP after 3.2 from [43.157.61.211]:30092 in > tests before SMTP handshake - > postfix/postscreen 84893 - - DISCONNECT [43.157.61.211]:30092 > > Some other syslog records do have the DNSBL rank. For example: > > postfix/postscreen 86907 - - CONNECT from [185.242.226.22]:49012 to > [192.168.11.2]:25 > postfix/dnsblog 86910 - - addr 185.242.226.22 listed by domain > zen.spamhaus.org as 127.0.0.3 > postfix/postscreen 86907 - - DNSBL rank 2 for [185.242.226.22]:49012 > postfix/postscreen 86907 - - HANGUP after 0.8 from [185.242.226.22]:49012 in > tests after SMTP handshake The client hung up too early for a rank to be logged. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: improving SRS support
On Wed, Mar 06, 2024 at 07:30:01PM -0500, Christophe Kalt via Postfix-users wrote: > The two options I've seen for implementing SRS are milter and > [sender_]canonical_maps but it seems to me that neither are a good fit when > rewriting the envelope From as they happen early on (smtpd and cleanup > specifically) and before Postfix knows where the mail is going. > > That's a bit of a problem as rewriting the sender only makes sense if the > mail is being sent over SMTP (and even then, it would be great to have more > control as it is not always desirable). Looking for another option, the > closest seems to be smtp_generic_maps except that it rewrites both envelope > and header Froms. > > I suspect this could easily be adjusted with a new smtp_generic_classes > parameter (similar to [sender_]canonical_classes) ? Yes, but I'm somewhat concerned about lack of "orthogonality" of features. What if one wants both generic mapping of interal addresses in headers, and SRS for remote envelopes? Perhaps SRS should be using a feature that (like virtual aliases for recipient addresses) transforms only the envelope sender address and does not preclude generic(5) rewriting? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: improving SRS support
On Wed, Mar 6, 2024 at 8:18 PM Wietse Venema via Postfix-users < postfix-users@postfix.org> wrote: > This location in the message flow seems right to me. And we already > have an example for implementing an address rewriting _classes > feature. This can even be configured in master.cf if one also needs > to send messages with non-SRSed envelope.from, for example to > internal systems. > Great, that's what I was thinking too. Now, just to make sure I'm not missing anything, transport_maps are the only way to choose between 2 differently configured smtp(8), right? As a bonus point, I'd really like the ability to do so based on other signals (header, origin of the mail). > I won't have time for new code in the coming weeks. But if someone > can contribute then I'll look at it. > This is a bit of a nice to have for me right now, but I expect I'll eventually get to it. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] DNSBL rank log messages after HANGUP
Today I noticed that, occasionally, I see a syslog message stating "blocked using zen.spamhaus..." but no matching "DNSBL rank ..." message. A couple of examples from the past two days: postfix/postscreen 84893 - - CONNECT from [43.157.61.211]:30092 to [192.168.11.2]:25 postfix/dnsblog 84894 - - addr 43.157.61.211 listed by domain zen.spamhaus.org as 127.0.0.11 postfix/postscreen 84893 - - HANGUP after 3.2 from [43.157.61.211]:30092 in tests before SMTP handshake postfix/postscreen 84893 - - DISCONNECT [43.157.61.211]:30092 postfix/postscreen 1274 - - CONNECT from [45.83.66.127]:42402 to [192.168.11.2]:25 postfix/dnsblog 1276 - - addr 45.83.66.127 listed by domain zen.spamhaus.org as 127.0.0.11 postfix/postscreen 1274 - - HANGUP after 5.3 from [45.83.66.127]:42402 in tests before SMTP handshake postfix/postscreen 1274 - - DISCONNECT [45.83.66.127]:42402 postfix/postscreen 1292 - - CONNECT from [64.62.197.225]:56707 to [192.168.11.2]:25 postfix/dnsblog 1294 - - addr 64.62.197.225 listed by domain zen.spamhaus.org as 127.0.0.4 postfix/postscreen 1292 - - HANGUP after 4.5 from [64.62.197.225]:56707 in tests before SMTP handshake postfix/postscreen 1292 - - DISCONNECT [64.62.197.225]:56707 My postscreen_dnsbl_* settings are: postscreen_dnsbl_action = enforce postscreen_dnsbl_allowlist_threshold = -1 postscreen_dnsbl_sites = zen.spamhaus.org*2, list.dnswl.org*-6 postscreen_dnsbl_threshold = 2 Some other syslog records do have the DNSBL rank. For example: postfix/postscreen 86907 - - CONNECT from [185.242.226.22]:49012 to [192.168.11.2]:25 postfix/dnsblog 86910 - - addr 185.242.226.22 listed by domain zen.spamhaus.org as 127.0.0.3 postfix/postscreen 86907 - - DNSBL rank 2 for [185.242.226.22]:49012 postfix/postscreen 86907 - - HANGUP after 0.8 from [185.242.226.22]:49012 in tests after SMTP handshake postfix/postscreen 86907 - - DISCONNECT [185.242.226.22]:49012 My syslogd (and system as a whole) is far from busy. Postfix 3.8.4 on FreeBSD 13.2-RELEASE-p8 -- Cheers, Phil ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
Wietse Venema via Postfix-users: > Again, Postfix does not store line terminators, not when email comes > from UNIX tool with \n, via SMTP with \r\n, or encapsulated as > netstrings which uses neither. > > Instead, Postfix generates line terminators upon output, and until > now they are always \n. In headers that Postfix sends to a milter. I may want to change that or at least make it configurable with an appropriate default. I just checked what happens with bodies. There, the Postfix Milter client is hard coded to send lines ending in "\r\n". Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: improving SRS support
Christophe Kalt via Postfix-users: > Hi, > > The two options I've seen for implementing SRS are milter and > [sender_]canonical_maps but it seems to me that neither are a good fit when > rewriting the envelope From as they happen early on (smtpd and cleanup > specifically) and before Postfix knows where the mail is going. > > That's a bit of a problem as rewriting the sender only makes sense if the > mail is being sent over SMTP (and even then, it would be great to have more > control as it is not always desirable). Looking for another option, the > closest seems to be smtp_generic_maps except that it rewrites both envelope > and header Froms. > > I suspect this could easily be adjusted with a new smtp_generic_classes > parameter (similar to [sender_]canonical_classes) ? This location in the message flow seems right to me. And we already have an example for implementing an address rewriting _classes feature. This can even be configured in master.cf if one also needs to send messages with non-SRSed envelope.from, for example to internal systems. I won't have time for new code in the coming weeks. But if someone can contribute then I'll look at it. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pushing changes to remote system
> On Mar 6, 2024, at 16:52, Wietse Venema via Postfix-users > wrote: > > Alex via Postfix-users: >> Hi, >> I have a few postfix systems on fedora38 with nearly identical >> configurations. I'd like to be able to push changes to them from a third >> system without having to login to them directly to do so. What's the >> best/most secure way to do this? >> >> For example, I'd like to push the recipient access file to both systems >> since they both relay mail for the same domains. Currently I'm doing this >> with rsync/ssh as root but would like to use a regular user. > > rsync renames files into place. That is good, because there is no > risk that it overwrites a file while some program reads from it. > > But if an unprivileged user can replace files in /etc/postfix, they > they are root equivalent. That is not the improvement that you > appear to be looking for. > > Maybe you can use a pull model instead, like curl and a REST server. This is a solved problem, using tools like ansible, chef, or puppet. Puppet specifically can be configured to do periodic pulls without having to login. -Dan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pushing changes to remote system
Alex via Postfix-users: > Hi, > I have a few postfix systems on fedora38 with nearly identical > configurations. I'd like to be able to push changes to them from a third > system without having to login to them directly to do so. What's the > best/most secure way to do this? > > For example, I'd like to push the recipient access file to both systems > since they both relay mail for the same domains. Currently I'm doing this > with rsync/ssh as root but would like to use a regular user. rsync renames files into place. That is good, because there is no risk that it overwrites a file while some program reads from it. But if an unprivileged user can replace files in /etc/postfix, they they are root equivalent. That is not the improvement that you appear to be looking for. Maybe you can use a pull model instead, like curl and a REST server. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: pushing changes to remote system
On Wed, Mar 06, 2024 at 07:12:18PM -0500, Alex via Postfix-users wrote: > I have a few postfix systems on fedora38 with nearly identical > configurations. I'd like to be able to push changes to them from a third > system without having to login to them directly to do so. What's the > best/most secure way to do this? Keep the configurations in a git repository and pull them as root, using an SSH key in batch mode with a preseeded known-hosts file. Pull only the source files for tables, and then run "make" to run "postmap", ... You could use an 'https' git remote URL, but without additional configuration that trusts too many CAs, so SSH is better. > For example, I'd like to push the recipient access file to both systems > since they both relay mail for the same domains. Currently I'm doing this > with rsync/ssh as root but would like to use a regular user. That'd be a mistake, Postfix configuration files should belong to root. > Postifx complains when changing ownership of these files to a regular > user, so I thought of using setfacl on the individual files I need. Will > that cause a problem? > > # setfacl -m g:appuser:rwx /etc/postfix > # setfacl -m g:appuser:wx /etc/postfix/client_checks.cidr > # setfacl -m g:appuser:wx /etc/postfix/recipient_checks > > $ postmap recipient_checks > $ ls -l recipient_checks* > -rw-rwxr--+ 1 rootroot1065 Nov 15 2020 recipient_checks > -rw-r--r-- 1 appuser appuser 2305 Mar 6 18:37 recipient_checks.cdb Avoid pushing computed binary artefacts, pull the source and run make.. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] improving SRS support
Hi, The two options I've seen for implementing SRS are milter and [sender_]canonical_maps but it seems to me that neither are a good fit when rewriting the envelope From as they happen early on (smtpd and cleanup specifically) and before Postfix knows where the mail is going. That's a bit of a problem as rewriting the sender only makes sense if the mail is being sent over SMTP (and even then, it would be great to have more control as it is not always desirable). Looking for another option, the closest seems to be smtp_generic_maps except that it rewrites both envelope and header Froms. I suspect this could easily be adjusted with a new smtp_generic_classes parameter (similar to [sender_]canonical_classes) ? ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] pushing changes to remote system
Hi, I have a few postfix systems on fedora38 with nearly identical configurations. I'd like to be able to push changes to them from a third system without having to login to them directly to do so. What's the best/most secure way to do this? For example, I'd like to push the recipient access file to both systems since they both relay mail for the same domains. Currently I'm doing this with rsync/ssh as root but would like to use a regular user. Postifx complains when changing ownership of these files to a regular user, so I thought of using setfacl on the individual files I need. Will that cause a problem? # setfacl -m g:appuser:rwx /etc/postfix # setfacl -m g:appuser:wx /etc/postfix/client_checks.cidr # setfacl -m g:appuser:wx /etc/postfix/recipient_checks $ postmap recipient_checks $ ls -l recipient_checks* -rw-rwxr--+ 1 rootroot1065 Nov 15 2020 recipient_checks -rw-r--r-- 1 appuser appuser 2305 Mar 6 18:37 recipient_checks.cdb ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Misunderstanging on masquerade_domains and rewriting in master.conf
Hello. One more i just had forgotten. I tried to enable easy
[pfx] Re: Recommendation for dkim signing
One. Last. Message. Of mine. And sorry for all this mostly off-topic noise. Steffen Nurpmeso wrote in <20240306214948.V5gSjSiU@steffen%sdaoden.eu>: |Steffen Nurpmeso via Postfix-users wrote in | <20231030191124.5ou-x%stef...@sdaoden.eu>: ||It seems to me there is not much interest of mail operators in ||stepping to ed25519, reducing the payload of DNS and email? ||I know dkimpy supports it (and more -- but is python, uuuh!) for ||long, but OpenDKIM is unchanged for eight years. (At least my ||sf.net import from 2017-09-23 still stands.) | |So now that i have DKIM myself i tested. |And *no* verification software i can reach actually supports |Ed25519-sha256 as of RFC 8463 from September 2018! |It is even *worse* than that. | | - Google: at least reaches out to the RSA signature and verifies |that, it ignores the other one saying "no key". | | - Microsoft: fails the DKIM test if a RFC 8463 signature is |present, no matter whether first or last!!! |Is this *really* true? That is really bad. + It even actively fails SHA1 DKIM signatures. I know these are deprecated, but if i use a rsa-sha1 and a rsa-sha256 signature in that order: Authentication-Results: spf=pass (sender IP is 217.144.132.164) smtp.mailfrom=sdaoden.eu; dkim=fail (body hash did not verify) header.d=sdaoden.eu;dmarc=bestguesspass action=none header.from=sdaoden.eu;compauth=pass reason=109 The *very*same* message/-checkum passes Google: Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@sdaoden.eu header.s=lemon header.b=meYlPkTE; dkim=pass (test mode) header.i=@sdaoden.eu header.s=citron header.b=Cehr1W9z; spf=pass (google.com: domain of stef...@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=stef...@sdaoden.eu Looking at that. Say, the Microsoft Authentication-Results: does not denote its own domain name, no? Ie i could not strip it. I have not read RFC 8601 for very too long to know, though. They do not look at the h=sha1 of the DNS record, do they. They do not look at the a= of the DKIM signature. | - The software this list uses (rspamd i think): fails if the |Ed25519 signature is first, aka does not reach out. (Which it |should, says DKIM, does it. The DKIM standard is |*fantastic*!) It at least succeeds if the RSA is first. | |What a mess. Even though explicitly envisioned in the DKIM |standard, it seems to me one cannot simply create two signatures, |as i wanted to do. (For a while, at least; until i see Ed is |supported anywhere. I had no plan, actually.) | |So as of today DKIM interoperability seems to mean: | | - Place a single signature. | | - It must be RSA-sha256. And exactly only that. |RFC 6376 surely would have deserved something better. Good night, greetings, and Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommendation for dkim signing
Steffen Nurpmeso via Postfix-users wrote in <20231030191124.5ou-x%stef...@sdaoden.eu>: |It seems to me there is not much interest of mail operators in |stepping to ed25519, reducing the payload of DNS and email? |I know dkimpy supports it (and more -- but is python, uuuh!) for |long, but OpenDKIM is unchanged for eight years. (At least my |sf.net import from 2017-09-23 still stands.) So now that i have DKIM myself i tested. And *no* verification software i can reach actually supports Ed25519-sha256 as of RFC 8463 from September 2018! It is even *worse* than that. - Google: at least reaches out to the RSA signature and verifies that, it ignores the other one saying "no key". - Microsoft: fails the DKIM test if a RFC 8463 signature is present, no matter whether first or last!!! Is this *really* true? That is really bad. - The software this list uses (rspamd i think): fails if the Ed25519 signature is first, aka does not reach out. (Which it should, says DKIM, does it. The DKIM standard is *fantastic*!) It at least succeeds if the RSA is first. What a mess. Even though explicitly envisioned in the DKIM standard, it seems to me one cannot simply create two signatures, as i wanted to do. (For a while, at least; until i see Ed is supported anywhere. I had no plan, actually.) So as of today DKIM interoperability seems to mean: - Place a single signature. - It must be RSA-sha256. RFC 6376 surely would have deserved something better. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] An even longer line to overcome the dwarfs (Was: Re: SOLVED: Escaping of braces {} in configuration (master(5)))
Steffen Nurpmeso via Postfix-users wrote in <20240306200252.7CXzMIAH@steffen%sdaoden.eu>: |Steffen Nurpmeso via Postfix-users wrote in | <20240306195734.nj_iAyWy@steffen%sdaoden.eu>: ||A last check. ||Thank you, postfix-users@. I am deeply sorry and am now stopping this, but somehow the subject was no longer folded at all. Sorry for all the distress!! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
Hello Scott Kitterman. Scott Kitterman via Postfix-users wrote in : .. |As far as I know, we're doing it mostly correctly I'm dkimpy (see below). \ | It's used in lots of ways that have nothing to do with postfix, so \ |I am strongly inclined to believe it's right or there would have been \ |lots of reports of interoperability issues. I am up to my eyeballs \ |in other stuff at the moment, so there's no way I can even contemplate \ |time for a code review in the absence of a known issue. | |One thing that may be a factor is the canonicalization algorithm being \ |used. I tried simple early on, but it proved to be fragile. I suspect \ |(but equally haven't recently checked) most are using relaxed canonicali\ |zation. For the header, line endings don't matter for it since you \ |unfold everything. The 'simple' canonicalization is easy to implement, \ |but very fragile. It is, in fact, bad enough that even if you tell \ |dkimpy to use simple for the header, it does relaxed anyway. For the \ |body it will do whichever is specified. I only support relaxed/relaxed (for now). Yes; i do not know, you know? My change was to treat LF and CR outside of CRLF the same as SP and HT, and now it works. Thank you! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Hello. Steffen Nurpmeso via Postfix-users wrote in <20240306195734.nj_iAyWy@steffen%sdaoden.eu>: |A last check. |Thank you, postfix-users@. Authentication-Results: list.sys4.de; dkim=pass header.d=sdaoden.eu; arc=none (Message is not ARC signed); dmarc=none So it seems to me the ML drivers have also a problem with their software. When i place the RSA signature first, dkim=pass'es, but when i place the ed25519 signature first we see dkim=fail. Now it *could* be that i generate the ed25519 signature the false way, i have no means of testing whether this is true or not. The mentioned DKIM service does not support it, and Google also does not it seems. I have not tried Microsoft yet. Then again the code paths are absolutely identical, it is just a single function call that differs. (I even have potential for more optimization, actually.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
On March 6, 2024 7:37:47 PM UTC, Steffen Nurpmeso via Postfix-users wrote: >Hello Wietse Venema :) > >Wietse Venema via Postfix-users wrote in > <4tqhxw0ksyzj...@spike.porcupine.org>: > |Steffen Nurpmeso via Postfix-users: > |> Wietse Venema via Postfix-users wrote in > |> <4tqh100n6pzj...@spike.porcupine.org>: > |>|Are you trying to say that Postfix represents a multiline message > |>|header as text with \n instead of \r\n? > |> > |> Yes. > ... > |>|I agree that \r\n would be better, but I'm surprised that this has > |>|not come up before. > .. > |Every Received: header is multiline, and it is not unusual to have > >These are not "usually" DKIM signed i'd say. > > |multiline Subject:, To:, and other common headers. > >Yes. > > |Again, Postfix does not store line terminators, not when email comes > |from UNIX tool with \n, via SMTP with \r\n, or encapsulated as > |netstrings which uses neither. > >OK then there is nothing i can do on the MUA side. > > |Instead, Postfix generates line terminators upon output, and until > |now they are always \n. > | > |Postfix systems have been signing with Milters since Postfix Milter > |support was added in 2006. I'm just surprised that the non-canoncal > |line endings in a multiline header have not been a problem before. > >My milter now treats LF and CR not in a CRLF as real whitespace. >The email i just sent was accepted by Google, this one should also >wrap, and we see what this software does (rspamd is it i think). > >So it seems to me, without having looked what OpenDKIM does, and >maybe i should explicitly Cc: Scott Kitterman for his dkimpy, but >i know he is on this list, just let's wait a bit, that all these >DKIM milters do it falsely, and treat LF and CR other than the >combination of CRLF as whitespace. Even though WSP is defined by >"RFC 5234, B.1. Core Rules:" as "WSP= SP / HT; white space", >and that is what the DKIM and email standards go for. For the >latter i explicitly asked a month or so ago. >So they break the email standard, postfix does, too, and in >combination all is fine again. As far as I know, we're doing it mostly correctly I'm dkimpy (see below). It's used in lots of ways that have nothing to do with postfix, so I am strongly inclined to believe it's right or there would have been lots of reports of interoperability issues. I am up to my eyeballs in other stuff at the moment, so there's no way I can even contemplate time for a code review in the absence of a known issue. One thing that may be a factor is the canonicalization algorithm being used. I tried simple early on, but it proved to be fragile. I suspect (but equally haven't recently checked) most are using relaxed canonicalization. For the header, line endings don't matter for it since you unfold everything. The 'simple' canonicalization is easy to implement, but very fragile. It is, in fact, bad enough that even if you tell dkimpy to use simple for the header, it does relaxed anyway. For the body it will do whichever is specified. Scott K ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
A last check. Thank you, postfix-users@. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Short subject (Was Re: ...)
Steffen Nurpmeso via Postfix-users wrote in <20240306194657.5KGvOP2Q@steffen%sdaoden.eu>: |Ah, please. |Let me please reply to this thread once more, to be sure. (The |other did not have folded.) |(Pressing thumbs!) That failed. But i replied to that again to a Google account, and Google succeeds: Authentication-Results: mx.google.com; dkim=neutral (no key) header.i=@sdaoden.eu header.s=orange; dkim=pass (test mode) header.i=@sdaoden.eu header.s=citron header.b=WXhz00qC; spf=pass (google.com: domain of stef...@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=stef...@sdaoden.eu For the moment i do not know. I switch keys again (rsa first, not ed), and please let me try once again. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Ah, please. Let me please reply to this thread once more, to be sure. (The other did not have folded.) (Pressing thumbs!) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
Steffen Nurpmeso via Postfix-users wrote in <20240306193747.mAtzRjYs@steffen%sdaoden.eu>: ... |My milter now treats LF and CR not in a CRLF as real whitespace. |The email i just sent was accepted by Google, this one should also |wrap, and we see what this software does (rspamd is it i think). | |So it seems to me, without having looked what OpenDKIM does, and |maybe i should explicitly Cc: Scott Kitterman for his dkimpy, but |i know he is on this list, just let's wait a bit, that all these |DKIM milters do it falsely, and treat LF and CR other than the |combination of CRLF as whitespace. Even though WSP is defined by |"RFC 5234, B.1. Core Rules:" as "WSP= SP / HT; white space", |and that is what the DKIM and email standards go for. For the |latter i explicitly asked a month or so ago. |So they break the email standard, postfix does, too, and in |combination all is fine again. Authentication-Results: list.sys4.de; dkim=pass header.d=sdaoden.eu; arc=none (Message is not ARC signed); dmarc=none Hahahaha! What a mess!!! ;-) Btw it seems Google does not support Ed25519 keys at all?? And if anyone else is writing a DKIM thing. I am thankful i could contact https://www.appmaildev.com/de/dkim for testing purposes. (If you read this: your service is broken, it does not support continuation lines in DKIM signatures *at*all*. But thank you!) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Milter multiline header formatting
Hello Wietse Venema :) Wietse Venema via Postfix-users wrote in <4tqhxw0ksyzj...@spike.porcupine.org>: |Steffen Nurpmeso via Postfix-users: |> Wietse Venema via Postfix-users wrote in |> <4tqh100n6pzj...@spike.porcupine.org>: |>|Are you trying to say that Postfix represents a multiline message |>|header as text with \n instead of \r\n? |> |> Yes. ... |>|I agree that \r\n would be better, but I'm surprised that this has |>|not come up before. .. |Every Received: header is multiline, and it is not unusual to have These are not "usually" DKIM signed i'd say. |multiline Subject:, To:, and other common headers. Yes. |Again, Postfix does not store line terminators, not when email comes |from UNIX tool with \n, via SMTP with \r\n, or encapsulated as |netstrings which uses neither. OK then there is nothing i can do on the MUA side. |Instead, Postfix generates line terminators upon output, and until |now they are always \n. | |Postfix systems have been signing with Milters since Postfix Milter |support was added in 2006. I'm just surprised that the non-canoncal |line endings in a multiline header have not been a problem before. My milter now treats LF and CR not in a CRLF as real whitespace. The email i just sent was accepted by Google, this one should also wrap, and we see what this software does (rspamd is it i think). So it seems to me, without having looked what OpenDKIM does, and maybe i should explicitly Cc: Scott Kitterman for his dkimpy, but i know he is on this list, just let's wait a bit, that all these DKIM milters do it falsely, and treat LF and CR other than the combination of CRLF as whitespace. Even though WSP is defined by "RFC 5234, B.1. Core Rules:" as "WSP= SP / HT; white space", and that is what the DKIM and email standards go for. For the latter i explicitly asked a month or so ago. So they break the email standard, postfix does, too, and in combination all is fine again. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Milter multiline header formatting
Steffen Nurpmeso via Postfix-users:
> Wietse Venema via Postfix-users wrote in
> <4tqh100n6pzj...@spike.porcupine.org>:
> |Are you trying to say that Postfix represents a multiline message
> |header as text with \n instead of \r\n?
>
> Yes.
>
> |That is very well possible. Postfix strips \n and \r\n line terminators
> |on input, and the MIME parser synthesizes multiline headers with
> |\n boundaries thusly, before they are sent to header_checks or
> |Milter:
> |
> |if (IS_SPACE_TAB(*text)) {
> |if (LEN(state->output_buffer) < var_header_limit) {
> |vstring_strcat(state->output_buffer, "\n");
> |vstring_strncat(state->output_buffer, text, len);
> |
> |That code was written years before Postfix Milter support and DKIM
> |plugins.
> |
> |I agree that \r\n would be better, but I'm surprised that this has
> |not come up before.
>
> Maybe other MUAs create valid emails with only CRLF when passing
> over to the MTA, or simply do not use line continuation when the
> email is to be passed to the MTA.
> Plus DKIM is maybe not used widely by the my-MUA-is-a-shell-script
> folks yet.
Every Received: header is multiline, and it is not unusual to have
multiline Subject:, To:, and other common headers.
Again, Postfix does not store line terminators, not when email comes
from UNIX tool with \n, via SMTP with \r\n, or encapsulated as
netstrings which uses neither.
Instead, Postfix generates line terminators upon output, and until
now they are always \n.
Postfix systems have been signing with Milters since Postfix Milter
support was added in 2006. I'm just surprised that the non-canoncal
line endings in a multiline header have not been a problem before.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Wietse Venema via Postfix-users wrote in
<4tqh100n6pzj...@spike.porcupine.org>:
|Are you trying to say that Postfix represents a multiline message
|header as text with \n instead of \r\n?
Yes.
|That is very well possible. Postfix strips \n and \r\n line terminators
|on input, and the MIME parser synthesizes multiline headers with
|\n boundaries thusly, before they are sent to header_checks or
|Milter:
|
|if (IS_SPACE_TAB(*text)) {
|if (LEN(state->output_buffer) < var_header_limit) {
|vstring_strcat(state->output_buffer, "\n");
|vstring_strncat(state->output_buffer, text, len);
|
|That code was written years before Postfix Milter support and DKIM
|plugins.
|
|I agree that \r\n would be better, but I'm surprised that this has
|not come up before.
Maybe other MUAs create valid emails with only CRLF when passing
over to the MTA, or simply do not use line continuation when the
email is to be passed to the MTA.
Plus DKIM is maybe not used widely by the my-MUA-is-a-shell-script
folks yet.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Are you trying to say that Postfix represents a multiline message
header as text with \n instead of \r\n?
That is very well possible. Postfix strips \n and \r\n line terminators
on input, and the MIME parser synthesizes multiline headers with
\n boundaries thusly, before they are sent to header_checks or
Milter:
if (IS_SPACE_TAB(*text)) {
if (LEN(state->output_buffer) < var_header_limit) {
vstring_strcat(state->output_buffer, "\n");
vstring_strncat(state->output_buffer, text, len);
That code was written years before Postfix Milter support and DKIM
plugins.
I agree that \r\n would be better, but I'm surprised that this has
not come up before.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Wietse Venema via Postfix-users wrote in
<4tqwct4jgczj...@spike.porcupine.org>:
|Wietse Venema via Postfix-users:
|> The text should have said:
|>
|> Other command-line arguments
|> Specify "{" and "}" around command arguments that must start
|> with "{" or that must contain whitespace (Postfix 3.0 and
|> later). These outer "{" and "}" are removed from the input,
|> together with any leading or trailing whitespace.
|>
|> Basically, Postfix strips one level of {} around any command-line
|> argument that starts with "{".
|>
|> In that light, if you want "{daemon_name},sign", you need to specify
|> {{daemon_name},sign} like this:
|>
|> dkim-sign unix - n n - 0 spawn
|> user=_postfix_xlocal argv=/tmp/s-dkim-sign
|> --milter-macro-sign {{daemon_name},sign}
|> --key rsa-sha256,rsa,/tmp/pri-rsa.pem
|
|Or, as you're using "long" options:
|
| dkim-sign unix - n n - 0 spawn
| user=_postfix_xlocal argv=/tmp/s-dkim-sign
| --milter-macro-sign={daemon_name},sign
| --key=rsa-sha256,rsa,/tmp/pri-rsa.pem
|
|should also be valid.
Yes. Now i know why i have not tried, because i have
vpnsub_cleanup unix n - n - 0 cleanup
-o {header_checks=regexp:{{/^Received:/ IGNORE}}}
in there, too. Likely because of this.
(((It is not a getopt thing, but, yes.)))
|In this form, no argument starts with "{", and you can avoid the
|extra "{" and "}"
Dear Wietse Venema, i think postfix's sendmail (?) has a bug in
handling line ending normalization in header continuation lines.
I have updated the postfix-lmdb package i maintain, but just
started up today just now, not yet using it, so i do not know
whether there was any change.
My DKIM failure from last night, it is due to this.
Ie, the MUA i maintain, it practically "does MBOX" (it is older
than the first real email RFC, and much stuff is still not
changed, in effect, at least). This means it passes (but for
SMTP) an MBOX down the line, with only LF line endings.
So when responding in this thread last night, the line was so long
that it was folded to two lines. Now it happens that postfix has
recognized it as a continuation (otherwise further headers would
not have been recognized as headers i'd say), and it does
recognize LF as the used line ending (otherwise the entire message
would have been treated as a single line), but the milter has seen
the header like this (chars as decimal):
Mar 6 02:41:29 s-dkim-sign: [2124][crit]: TO IS
Mar 6 02:41:29 s-dkim-sign: [2124][crit]: [.] 111 110 10 32 40 109 [.]
The line continuation is passed as LF (10). Therefore my milter
passes the LF through literally (i had asked for that on the IETF
list, explicitly), but this causes this list and Google to fail.
I also simply removed it, but ditto. It was to late to try to
treat it as normal whitespace, 'will do this evening. This would
be bogus and not according to the IETF email and DKIM standards,
but it effectively would be the only remaining option to make DKIM
pass, so i actually expect that variant to work out this evening.
Anyway, i felt that it is a bug of postfix in that the line
continuation should also be normalized to CRLF before passing the
header to the milter. I actually have a hard time, as, as things
stand, any non-SMTP usage of the MUA i maintain in conjunction
with postfix does result in bad DKIM signatures when line
continuation is involved, and that part of the program is due to
be rewritten in the upcoming years, it is quite an effort to get
there regulary. (As it simply thinks of emails as LF lines.)
I could only hack that in (and thought of offering a switch to
enable this via on-the-fly adjusting when passing data out to the
MTA) for the next release.
I looked at Scott Kitterman's dkimpy, and this did not make me
more happy. (Even though he uses trim() that eats anything, that
only as a last step, before it is plain \r\n and [\t ].) Ie, this
would really mean those emails would have broken DKIM signatures
for at least Google and the DKIM verifier of this list here, i had
no time to test Microsoft yet. (Or other lists.)
Thank you.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: dmarc reports from Microsoft (possibly off topic)
Alan Munday: > As of the 22 Feb 2024 I have been seeing invalid MAIL FROM address from > Microsoft: > > In: MAIL FROM: XATTRDIRECT=Originating > XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848 Wietse: > When I send the above as one line into Postfix, the response is: > > 555 5.5.4 Unsupported option: XATTRDIRECT=Originating There is no need for Postfix workarounds, they have rolled out a fix. https://techcommunity.microsoft.com/t5/exchange/microsoft-dmarc-aggregate-report-smtp-issues/m-p/4072531 Wietse >/etc/postfix/main.cf: >smtpd_command_filter = pcre:/etc/postfix/command_filter > >/etc/postfix/command_filter: ># Work around clients that send XATTRDIRECT or XATTRORGID ># when Postfix announces no such support in the EHLO response. >/^(MAIL FROM:\s*<.*>.*)\s+XATTRDIRECT=\S+\s+XATTRORGID=\S+(.*)/ $1$2 > > This pattern seems to work with light testing. Do not omit the (.*) > at the end of the pattern, or the $2 in the result. These are for > supported options that they might send after XATTRORGID. > > Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: dmarc reports from Microsoft (possibly off topic)
Alan Munday via Postfix-users: > As of the 22 Feb 2024 I have been seeing invalid MAIL FROM address from > Microsoft: > > In: MAIL FROM: XATTRDIRECT=Originating > XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848 > > Clearly an issue with line termination, but one I have yet to find > reported online. Postfix "chat history" will fold long lines for readability (note that there is only one "In:" above). When I send the above as one line into Postfix, the response is: 555 5.5.4 Unsupported option: XATTRDIRECT=Originating And Postfix is correct. The Postfix EHLO response does not announce support for XATTRDIRECT or XATTRORGID, therefore the client must not send such arguments in MAIL FROM. There is no second "554" reponse (for XATTRORGID) because that would break SMTP. If this is a problem then you could use smtpd_command_filter to remove these options. /etc/postfix/main.cf: smtpd_command_filter = pcre:/etc/postfix/command_filter /etc/postfix/command_filter: # Work around clients that send XATTRDIRECT or XATTRORGID # when Postfix announces no such support in the EHLO response. /^(MAIL FROM:\s*<.*>.*)\s+XATTRDIRECT=\S+\s+XATTRORGID=\S+(.*)/ $1$2 This pattern seems to work with light testing. Do not omit the (.*) at the end of the pattern, or the $2 in the result. These are for supported options that they might send after XATTRORGID. Wietse > I have seen a couple of reports where the Reporting Organization is set > to "Enterprise Outlook" but none from "Outlook.com" > > Has anyone else seen this behaviour and could this be related to SMTP > smuggling? Huh? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SOLVED: Escaping of braces {} in configuration (master(5))
Wietse Venema via Postfix-users:
> The text should have said:
>
> Other command-line arguments
> Specify "{" and "}" around command arguments that must start
> with "{" or that must contain whitespace (Postfix 3.0 and
> later). These outer "{" and "}" are removed from the input,
> together with any leading or trailing whitespace.
>
> Basically, Postfix strips one level of {} around any command-line
> argument that starts with "{".
>
> In that light, if you want "{daemon_name},sign", you need to specify
> {{daemon_name},sign} like this:
>
> dkim-sign unix - n n - 0 spawn
> user=_postfix_xlocal argv=/tmp/s-dkim-sign
> --milter-macro-sign {{daemon_name},sign}
> --key rsa-sha256,rsa,/tmp/pri-rsa.pem
Or, as you're using "long" options:
dkim-sign unix - n n - 0 spawn
user=_postfix_xlocal argv=/tmp/s-dkim-sign
--milter-macro-sign={daemon_name},sign
--key=rsa-sha256,rsa,/tmp/pri-rsa.pem
should also be valid.
In this form, no argument starts with "{", and you can avoid the
extra "{" and "}"
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] dmarc reports from Microsoft (possibly off topic)
As of the 22 Feb 2024 I have been seeing invalid MAIL FROM address from Microsoft: In: MAIL FROM: XATTRDIRECT=Originating XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848 Clearly an issue with line termination, but one I have yet to find reported online. I have seen a couple of reports where the Reporting Organization is set to "Enterprise Outlook" but none from "Outlook.com" Has anyone else seen this behaviour and could this be related to SMTP smuggling? Thanks Alan ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: filter header from on forwarded mail
> From: Ralph Seichter via Postfix-users > > I heartily recommend milter-regex [1]. It serves me well by allowing me > to configure all kinds of complex antispam rules. > > [1] https://www.benzedrine.ch/milter-regex.html > > -Ralph Thanks Ralph, that looks interesting and it's even Swiss made :). It seems that my approach is not capable of filtering the header From:, but only the envelope sender. Juerg smime.p7s Description: S/MIME cryptographic signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
