[pfx] Re: ssl/tls error in mail.log
On Tue, Sep 24, 2024 at 09:54:27PM +0800, Wesley via Postfix-users wrote: > I have a backup MX server which shows this error in its mail.log: > > Sep 24 21:49:18 mxback postfix/smtps/smtpd[24711]: connect from > unknown[165.154.138.57] > Sep 24 21:49:18 mxback postfix/smtps/smtpd[24711]: SSL_accept error from > unknown[165.154.138.57]: -1 > Sep 24 21:49:18 mxback postfix/smtps/smtpd[24711]: warning: TLS library > problem: error:0A6C:SSL routines::bad key > share:../ssl/statem/extensions_srvr.c:646: > Sep 24 21:49:18 mxback postfix/smtps/smtpd[24711]: lost connection after > CONNECT from unknown[165.154.138.57] > Sep 24 21:49:18 mxback postfix/smtps/smtpd[24711]: disconnect from > unknown[165.154.138.57] commands=0/0 > > do you know what are "SSL_accept error" and "TLS library problem" in above > statements? > > Thanks. I might indicate that someone has been running tests against the mail server to determine which versions of protocols it supports. If that's the case, there will probably be lots of failures in a short timespan, unless the scan is scanning for a single thing across many IP addresses. Or it might indicate that the mail server refuses to support something that an old client is trying to use (i.e., TLS 1.0 or 1.1). But I'm not sure what "bad key" means specifically so I might be wrong. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and STS
On Wed, Jul 03, 2024 at 05:12:35PM -0700, Matt Kinni via Postfix-users wrote: > On 2024-06-27 05:24, Viktor Dukhovni via Postfix-users wrote: > > > Publishing just "R10" will soon fail, when you get a cert from "R11" or > > one of the backup issuers R12, R13 or R14. You MUST publish them all to > > avoid sudden breakage surprises. > > Isn't it easier to just used self-signed certificates in this case? I > really don't understand the benefits of letsencrypt in the mail server > use case, when DANE works just fine with certificates that you can > generate yourself and don't have to deal with LE's high turnover > intermediaries nonsense. > > -- > Matt Letsencrypt is fine if you prevent the key itself changing all the time, and if you use 3 1 1 TLSA records. Having the key signed by them means that you can use the same key for ports 465 and 587 as you do for port 25 (and for any web server on the same host). There are email clients that don't like self-signed certificates for submission. And 3 1 1 means that the intermediaries are irrelevant for the purposes of DANE verification on port 25. They are only relevant for CA verification on other ports. So it's not really easier to just used self-signed certificates since you'll want a CA-signed certificate for submission anyway, and you can have the same key for both. cheers, raf ___ 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: 25 years today
On Tue, Dec 19, 2023 at 10:56:58AM +0100, "Jan P. Kessler via Postfix-users" wrote: > > As a few on this list may recall, it is 25 years ago today that the > > "IBM secure mailer" had its public beta release. This was accompanied > > by a nice article in the New York Times business section. > > I just wanted to say THANK YOU to you and any other contributors for a great > piece of software and tons of good advice! Postfix always successfully > combined rock-solid operations, precise documentation, modern features and > great backward compatibility - a rock in the surf of mailadmin's life :) > > Best regards > Jan Indeed! One of the things that impresses me most about Postfix is Wietse's dedication to backwards compatibility. The way Postfix achieves it is unique as far as I am aware. Obviously, for a mail system, backwards compatibility should/must be of the utmost importance to prevent massive breakage in the face of inattention by system administrators, but I think that should be true of any system that people might come to depend on. Others seem happy to break things regularly. Not cool. If it's not broken, don't break it. :-) cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: 25 years today
On Thu, Dec 14, 2023 at 08:20:26AM -0500, Wietse Venema via Postfix-users wrote: > As a few on this list may recall, it is 25 years ago today that the > "IBM secure mailer" had its public beta release. This was accompanied > by a nice article in the New York Times business section. > > There is some literature at https://www.postfix.org/press.html that > attests how this project accelerated open-source adoption by a very > large company. > > At the time there were several efforts by people inside IBM to do > open-source projects, but it was the NY Times article that brought > open source on the radar of the CEO. He then tasked people to come > up with an open-source strategy for IBM. > > As for the name Postfix, my colleagues and I had come up with > multiple names that were rejected each time (I still have some > Internet domains names from that time). We decided that this was > not going to work, released it as "IBM secure mailer", and then, > after IBM was no longer in control, changed the name to Postfix. > > That was a long time ago. Postfix has evolved as the Internet has > changed. I am continuing the overhaul of this software, motivated > by people like you on this mailing list. > > Wietse Thanks so much for Postfix. Nietzsche once said that hell is other people. I've often thought that hell is other people's software. But not Postfix. :-) The design considerations and implementation are brilliant. How it stayed so good for 25 years is a testament to your great judgement. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE 3: Upcoming new Let's Encrypt intemediate issuer CAs.
On Fri, Dec 08, 2023 at 02:00:55PM -0500, Viktor Dukhovni via Postfix-users wrote: > My previous post on this topic noted that covered Let's Encrypt are > planning to *randomise* the choice of intermediate issuer CA used with > each renewal. > > It now turns out that they will also be switching to new underlying > intermediate CAs. So you'll a random choice of *new* issuers. > > > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/L7XoAXt_s1c/m/k_vdk9rQAwAJ > > - We will be generating 5 RSA and 5 ECDSA intermediates, instead of 2 > each. We plan to automatically rotate issuance between multiple > intermediates for improved redundancy. > > - We will be shortening their validity period from 5 years to 3 years, > to reflect our commitment to issue new intermediates every 2 years. > > So anyone relying on DANE-TA(2) (certificate usage 2) needs to closely > watch for upcoming announcements from LE, and be prepared to add TLSA > records for the new intemediates soon. Or stop playing their game, and > switch to a robust "3 1 1" + "3 1 1" model with a stable by default > key during certificate renewals. > > -- > Viktor. You know it makes sense. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TAKE NOTE: "2 1 1" TLSA records vs. apparent change of Let's Encrypt default certificate chain
On Wed, Nov 15, 2023 at 09:44:18PM +0900, Byung-Hee HWANG via Postfix-users wrote: > Thank you for notifying us. Also i'm using 211 TLSA record. > > Honestly, 311 it was not easy to set up to me. > > Sincerely, Byung-Hee As Viktor pointed out, you're not affected, but if you want to use "3 1 1", and you use certbot for your LetsEncrypt certificates, as well as Viktor's danebot program (https://github.com/tlsaware/danebot), my danectl program makes it easy (https://github.com/raforg/danectl). With danectl, you still have to publish/remove the DNS records it tells you to, but it comes with a couple of DNS output adapters to help (for Bind9 zonefiles and for nsupdate). I'm happy to add more DNS output adapters if anyone needs them (and can supply it or help me write and test it). It seems there's another danebot program (https://github.com/stuvusIT/danebot) that (only) works with nsupdate. I don't know enough about it to recommend it or not. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: FOLLOW-UP Re: Re: [ext] list.sys4.de fails with starttls
On Tue, Nov 14, 2023 at 03:56:25PM +0100, Patrick Ben Koetter via Postfix-users wrote: > * Viktor Dukhovni via Postfix-users : > > On Mon, Sep 25, 2023 at 04:24:55PM +0200, Patrick Ben Koetter via > > Postfix-users wrote: > > > > > > Do you have SMTP client TLS connection reuse enabled? If so, TLS > > > > connections are made via tlsproxy(8), with the smtp(8) client > > > > unaware of any initialisation issues until STARTTLS. > > > > > > Well spotted and that was the reason Postfix failed. We've added a SELinux > > > policy to let tlsproxy do what it wants and things went back to normal. > > > > Thanks for the confirmation. I feel some pride in intuiting the cause > > in this case, the link with the reported symptoms was fairly subtle. > > After some more investigation and testing… > > It turned out that RedHat's SELinux policy does not cover Postfix' tlsproxy > and whenever tlsproxy takes out to do what Postfix wants it to do SELinux will > interfere and prohibit it from doing that. That in consequence made the SMTP > service throttle and so it came to a stillstand. > > For the moment we decided to do without TLS session caching in Postfix > smtp-client *and* sending client side x509 certificates on demand in favor of > running a more secure platform. > > Our long-term goal is to re-enable the Postfix features *and* use SELinux. > (RedHat if you're on this list and following this thread ping me offlist and > I'll be happy to share all information we can provide.) > > Regards > > p@rick This might be because tlsproxy is not active by default. Perhaps the default selinux policy for postfix is based only on the default configuration of postfix, when really, the default selinux policy for postfix should probably be based on all possible postfix behaviour. Talk to redhat about that. It must be possible to adapt the selinux policy to allow tlsproxy (but I can't help you with that). cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: FW: Wrong email in DMARC dns
On Mon, Oct 30, 2023 at 02:36:33PM +0100, Szymon Malinowski via Postfix-users wrote: > Hello > > We've just launched postfix with Mailscanner and spamassasin on our mail > server. > > Everything is working great, but we've encountered very funny and strange > problem. > > We've recieved an email which was classified as spamm by it's sender IP > address by RBL list. > > Additionally sender address didn't pass DMARC verification and had RUF email > in it's DNS record. > > Our mail system based on DMARC DNS record send a DMARC report to that email. > > However email in that record was invalid, and the destination server bounced > it with reason that the user is unknown. > > This bounced email was sent to us and was also classified as SPAM and was > rejected + again didn't pass DMARC verification which resulted in another > email with report to the invalid email adress which is in RUF DNS record. > > You see the point? We got stuck in a loop of sending DMARC reports which are > beeing bounced because of unknown user. > > Is there any way to prevent such situations? > > Right now we simply blocked that IP address on mail server firewall but this > could happen any time again in the future. > > Anyone every encountered this kind of situation? I've had this happen with one domain. I ended up with megabytes of bounce messages. You can try reporting the problem to the domain with the bad records, but if that fails to fix the problem, you need to stop sending report emails (or arrange to send that domain's DMARC reports to /dev/null or similar). And then submit a bug report for whatever software is sending the DMARC report. If the bug is fixed, you can turn reporting back on. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: forward_path setting not being processed correctly after upgrade
On Thu, Oct 26, 2023 at 03:16:04PM -0400, Viktor Dukhovni via Postfix-users wrote: > What's notable here, is how rare actual compatibility breaks are in > Postfix. Wietse has managed to maintain essentially backwards > compatible behaviour for over 20 years, which speaks to both design > quality and care for the users. > > You've stumbled over a rare exception, congratulations on the find. > > -- > Viktor. Well said. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Tue, Sep 26, 2023 at 02:01:24PM -0400, Wietse Venema via Postfix-users wrote: > Wietse Venema via Postfix-users: > > Wietse Venema via Postfix-users: > > > It's a rather long explanation for "why not do X". like several > > > times longer than the text that explains what protocol preferences > > > do. And this is the only place where adding that text would help. > > > > I updated the text a little: > > I'm adding a section to smtp_address_preferences, about when not > to use this setting. > > Wietse > > Notes for mail delivery between sites that have both IPv4 and IPv6 > connectivity: > > * Some remote SMTP servers will flag messages received over IPv6 > as more 'spammy' than messages received over IPv4. This may be > because the Postfix SMTP client's IPv6 address lacks a proper > PTR record, or because the client shares an IPv6 address block > with bad users. > > To achieve consistent delivery performance, don't tweak the > smtp_address_preference setting; instead, receive mail over > both IPv4 and IPv6, and deliver mail only over IPv4. > > /etc/postfix/main.cf: > inet_protocols = all > > /etc/postfix/master.cf > smtp ...other fields... smtp -o inet_protocols=ipv4 > > * The setting "smtp_address_preference = ipv6" is unsafe. [Existing > text omitted for brevity] Should -o inet_protocols=ipv4 also be added to the relay directive? cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Tue, Sep 26, 2023 at 10:35:39AM -0400, Wietse Venema via Postfix-users wrote: > > Sadly, I need smtp_address_preference = ipv4 because some > > reputation systems (spamhaus, I think) don't realise > > that an entity might only have a single ipv6 address. > > Then you should disable IPv6, in the PostfiX SMTP client > (master.cf: smtp -o inet_protocols=ipv4) or globally > (main.cf:inet_protocols=ipv4). > > Wietse Yes, I'm sure you're right, but I want to be able to receive mail via ipv6, and if sending via ipv4 is ever impossible, I'd rather attempt ipv6 and risk a rejection. I haven't gotten any bounce messages since favouring ipv4 in the client, but if I do I'll make this change for the client. Thanks. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
On Sun, Sep 24, 2023 at 06:25:36PM -0400, Wietse Venema via Postfix-users wrote: > Wietse Venema via Postfix-users: > > It's a rather long explanation for "why not do X". like several > > times longer than the text that explains what protocol preferences > > do. And this is the only place where adding that text would help. > > I updated the text a little: > > Notes for mail delivery between sites that have both IPv4 and IPv6 > connectivity: > > * The setting "smtp_address_preference = ipv6" is unsafe. All > deliveries will suffer delays when IPv6 is not available even > while the destination is still reachable over IPv4. Mail may > be stuck in the queue with Postfix versions < 3.3 that do > not implement "smtp_balance_inet_protocols". For similar reasons, > the setting "smtp_address_preference = ipv4" is also unsafe. > > * The setting "smtp_address_preference = any" is safe. With this, > and "smtp_balance_inet_protocols = yes" (the default), only > half of deliveries will suffer delays if there is an outage > that affects IPv6 or IPv4, as long as it does not affect both. > > I added smtp_balance_inet_protocols to the discussion, because it > mitigates the safety issue somewhat, perhaps to the point that some > people with low email volume are willing to suffer the delays. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org Sadly, I need smtp_address_preference = ipv4 because some reputation systems (spamhaus, I think) don't realise that an entity might only have a single ipv6 address. They seem to think that everyone has at least 64 addresses. So, when an unrelated tenant near my VPS sent spam from their ipv6 address, it tainted my ipv6 address's reputation. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Troubleshooting mail loop issue
On Tue, Aug 15, 2023 at 08:48:35AM -0400, Bill Cole via Postfix-users wrote: > Your task is to fix Microsoft's mishandling of email. (giggles insanely...) :-) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: server does not pick up new certificates
On Mon, Jul 24, 2023 at 09:49:58AM -0400, Wietse Venema via Postfix-users wrote: > Bernardo Reino via Postfix-users: > > >> I cannot imagine why/when the cerbot client would fail to run the > > >> post-hooks (in a sane environment). > > > > > > Systems crash. What are the reliability guarantees from the certbot > > > client: will it run once, or will it somehow maintain state and > > > recover when a run was interrupted by a system crash? > > > > In such cases, and/or just "on top" of the certbot renewal hooks, > > one could have a cron job doing "postmap" and/or "postfix reload" > > or whatever, as Viktor wrote. (but again, then your cron job must > > make sure that certbot is not (con)currently running). > > In other words, reliable execution requires a cron job, idempotent > actions, and a locking mechanism. > > Wietse I once wrote a nice little tool called "noexcuses" (https://github.com/raforg/noexcuses) that can be used in crontabs to ensure that a cronjob would run until it succeeded. It would run the cronjob, and if it failed, it would become a daemon retrying occasionally until someone fixed whatever the problem was so that the cronjob could succeed. If the cronhost was down when the cronjob was supposed to run (or crashed before success), it would detect that when the cronhost came back up. It could even migrate lost cronjobs to a new cronhost if the old cronhost couldn't be brought back up in time (if its state is stored on a remote fileserver). It's each cronjob's responsibility to indicate success/failure by its exit code, and to be idempotent. It was very handy when I had system administrators who were careless in the machine room. It could probably be used without cron, but it was really aimed at making cronjobs reliable. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] opendmarc question about many Undeliverable messages
Hi, I use OpenDMARC and I have it sending failure reports with "FailureReports true". Unfortunately, one organisation that sends me emails has a bug in their SPF record, and they no longer have the postmaster@ email address needed to receive DMARC reports, and I'm not sure that they know how to update their DNS records, so I end up with hundreds and hundreds of "Undeliverable" mail messages for each message that they send me. Does anyone know how to tell OpenDMARC to limit the number of attempts to send a failure report (ideally, to one)? It's like each undeliverable message is resulting in a new undeliverable message, with the subject header getting longer and longer as each new "FW: Undeliverable:" is prepended to it. I've turned off FailureReports, but I'm wondering if anyone knows a better way to deal with this. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 09:11:41AM -0400, Viktor Dukhovni via Postfix-users wrote: > On Thu, May 18, 2023 at 09:22:34PM +0900, Byung-Hee HWANG via Postfix-users > wrote: > > > And now i added TLSA record for only *outbond* smtp server, > > . > > It is also your secondary MX host: > > https://stats.dnssec-tools.org/explore/?doraji.xyz > > the primary MX host does not yet have TLSA records. The detailed > status is: > > doraji.xyz. IN MX 1871 yw-0919.doraji.xyz. > doraji.xyz. IN MX 1895 yw-1204.doraji.xyz. > _25._tcp.yw-0919.doraji.xyz. IN TLSA ? ; NXDOMAIN > _25._tcp.yw-1204.doraji.xyz. IN TLSA 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > yw-1204.doraji.xyz[185.17.255.72]: pass: TLSA match: depth = 0, name = > yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > yw-1204.doraji.xyz[2a03:ebc0:5000:12::10]: pass: TLSA match: depth = 0, > name = yw-1204.doraji.xyz > TLS = TLS13 with AES256GCM-SHA384,X25519,PubKeyALG_RSA > name = yw-1204.doraji.xyz > depth = 0 > Issuer CommonName = R3 > Issuer Organization = Let's Encrypt > notBefore = 2023-03-20T06:03:54Z > notAfter = 2023-06-18T06:03:53Z > Subject CommonName = yw-1204.doraji.xyz > pkey sha256 [matched] <- 3 1 1 > b4b06c36727808cb3e272f438cc6f1a77ee370c50dfb24eb5774a6113e4c6c0f > depth = 1 > Issuer CommonName = ISRG Root X1 > Issuer Organization = Internet Security Research Group > notBefore = 2020-09-04T00:00:00Z > notAfter = 2025-09-15T16:00:00Z > Subject CommonName = R3 > Subject Organization = Let's Encrypt > pkey sha256 [nomatch] <- 2 1 1 > 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d > depth = 2 > Issuer CommonName = DST Root CA X3 > Issuer Organization = Digital Signature Trust Co. > notBefore = 2021-01-20T19:14:03Z > notAfter = 2024-09-30T18:14:03Z > Subject CommonName = ISRG Root X1 > Subject Organization = Internet Security Research Group > pkey sha256 [nomatch] <- 2 1 1 > 0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3 > > Since your certificate is from Let's Encrypt, you've probably configured > automatic renewal. If you haven't also implemented *monitoring* of your > DANE TLSA configuration that checks whether the TLSA records match the > certificate chain, you should do that immediately, and ideally before > publishing TLSA records for any servers carrying "non-test" traffic. > > You can publish TLSA records for some test host with a self-signed > cert, and check monitoring detects incorrect TLSA records when > mismatched TLSA records are configured (and is not complaining > when the TLSA records are correct). With my danectl program, TLSA monitoring is a cronjob: danectl check If you have done a key rollover, but you haven't updated the TLSA records yet, it'll report (in zonefile format) that the old "current" TLSA record needs to be removed from the DNS, and that the new "next" TLSA record needs to be published. Also, if your DNSSEC zones are configured to automatically rollover every so often, you need to set up monitoring for that as well, so that you can communicate the new DS record to your registrar. I'm not sure what the best method for that is. I just wrote and cronned a script to report whenever the output of the following changes: host -t dnskey $domain | sort | grep 'DNSKEY record 257'; \ host -t cds $domain | sort | grep -v 'has no'; \ host -t cdnskey $domain | sort | grep -v 'has no' With BIND, that g
[pfx] Re: DANE and DNSSEC
On Thu, May 18, 2023 at 08:54:16PM +0200, Joachim Lindenberg via Postfix-users wrote: > For Letsencrypt certificates I´d definitely go with 2 1 1 > 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D and > optionally the R4 derivate and add their successors when these are about to > expire, rather than 3 1 1 and change every two months. > Best Regards, > Joachim The certificate might change every few months, but that doesn't mean that the key has to change at the same time. As Viktor pointed out, with certbot you can configure reuse_key = True which prevents the renewal from creating a new key. That way, the user can decide when they want the key to rollover. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: A strange DMARC failure
On Tue, May 16, 2023 at 10:15:35PM -0400, Bill Cole via Postfix-users wrote: > On 2023-05-16 at 21:09:35 UTC-0400 (Wed, 17 May 2023 09:09:35 +0800) > Tom Reed via Postfix-users > is rumored to have said: > [...] > > Since the message was sent to mailing list which rewrites envelope > > address > > and adds list signature, so: > > > > 1) SPF for header From: address won't get pass due to SRS. > > 2) DKIM won't get pass due to list signature. > > > > So the DMARC failed totally and the message was rejected. > > > > How to improve this? > > Do not reject mail solely based on DMARC failure. > > DMARC is fragile and unreliable. It has WELL-KNOWN incompatibilities with > traditional mailing list practices. The fact that DMARC exists does not > imply that it is entirely usable as deployed. > > -- > Bill Cole > b...@scconsult.com or billc...@apache.org > (AKA @grumpybozo and many *@billmail.scconsult.com addresses) > Not Currently Available For Hire Yes, it's best to let receiving MUAs deal with DMARC failures, rather than mail servers (which should just add Authentication headers). Then individual mail users can decide how they personally want to deal with it. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postsrsd question
On Mon, May 15, 2023 at 08:40:50PM +0800, Tom Reed via Postfix-users wrote: > Hello list, > > for Postsrsd, it rewrite all the sender addresses even if messages should > be delivered locally. > > how to setup it to not rewrite sender for local addresses? > > Thanks If you only forward emails for a small, fixed number of addresses, you can use github.com/zoni/postforward in combination with postsrsd, but it requires an entry for each affected address in /etc/aliases. It's not appropriate for more complex needs. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: how to implement plus address
On Fri, May 12, 2023 at 07:09:41PM +0800, Tom Reed via Postfix-users wrote: > Hello > > How can I implement the following feature? > the messages sent to: > > foo+la...@sample.com > foo+lab...@sample.com > ... > > all them will be delivered into: > f...@sample.com > > Thanks. > Tom Hi, Put the following in /etc/postfix/main.cf: recipient_delimiter = + cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
On Thu, May 11, 2023 at 03:17:21PM +0900, Byung-Hee HWANG via Postfix-users wrote: > Hellow Postfix hackers, > > I have a questions while reading DANE docs. Is DNSSEC mandotary? For > making DANE mail server. > > For now i'm running two postfix servers in public. Actually i'm beginner > in both DANE and DNSSEC. > > Any comments welcome! > > Sincerely, Byung-Hee Hi Byung-Hee, As others have said, if you want incoming DANE, you need DNSSEC. Bind9 makes it incredibly easy to enable DNSSEC. It's literally two extra lines in your configuration (unless you get fancy with automatic expiry and rollover - and that's easy too), plus you need to supply some information to your domain registrar for them to put into their servers. If your domain registrar doesn't support DNSSEC, or doesn't make it easy, find one that does. You'll need to interact with them every time you rollover your DNSSEC keys (e.g., maybe annually). As for the TLSA records you need to create for your mail servers, I recommend my "danectl" program which can generate TLSA records for you to publish in the DNS, and you can use it to monitor that they have been published. Recent versions include a couple of adapters to help publish the TLSA records in the DNS, but only if you edit your own bind9 zone files or use nsupdate for a dynamic zone. A big prerequisite of danectl is certbot to handle the actual key/certificate generation. danectl doesn't work with any other ACME client. There are technically many ways to do TLSA DANE but only one great way (TLSA 3 1 1 current + next) which is what danectl supports. The idea is to always have two keys/certificates and their corresponding TLSA records available for use all the time: the current one, and the next one. Whenever you want to rollover your key, you can immediately switch to the next one which is already published in the DNS and ready to go while you prepare the new next key/certificate and its corresponding TLSA record (for the next rollover). This ensures that every rollover works seamlessly because you never have the situation where things aren't working while your TLSA records are propagating around the DNS because they were published well before they were required. Here are some wikis that might help: https://github.com/baknu/DANE-for-SMTP/wiki https://github.com/internetstandards/toolbox-wiki cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: www.postfix.org certificate expired
On Sat, Apr 22, 2023 at 11:25:14AM -0400, Viktor Dukhovni via Postfix-users wrote: > On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via > Postfix-users wrote: > > > >You should set a POST_HOOK in certbot renew (assuming you're using > > >certbot, that is) that restarts or reloads the web server. > > > > I guess this exactly what failed. > > The "post hooks" in certbot are not *reliable*. If for some reason they > don't succeed, they're not retried on the next scheduled certbot run. This > is a design flaw. > > -- > Viktor. The same is true of cronjobs. I once wrote a program called "noexcuses" to solve this problem (https://raf.org/noexcuses) for cronjobs whose success depended on remote servers being up and working. It runs the command given on its command line repeatedly until it succeeds. It was very helpful for important jobs that had to run successfully when faced with sysadmins who had a tendency to overload a UPS in the machine room and accidentally shutdown lots of servers at the same time. But it's very cron-specific, even handling the case where the cron server itself was down when jobs needed to run. But it (or a similar approach) might be helpful for (non-cron) certbook hooks. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: invalid and non-fqdn hostname
On Thu, Apr 06, 2023 at 11:28:07AM +1000, Sean Gallagher wrote: > On 6/04/2023 10:39 am, raf via Postfix-users wrote: > > On Thu, Apr 06, 2023 at 07:33:28AM +0800, Corey Hickman via Postfix-users > > wrote: > > > > > Hello > > > > > > for these two statements, > > > > > > reject_invalid_helo_hostname > > > reject_non_fqdn_helo_hostname > > > > > > what are the differences between them? does the second one hold the first > > > one already? > > > > > > Thanks. > > reject_invalid_helo_hostname rejects malformed HELO or > > EHLO hostnames. > > > > reject_non_fqdn_helo_hostname rejects non > > fully-qualified domain (or address) HELO or EHLO > > hostnames. > > > > I would assume that the second one subsumes the first, > > since a malformed hostname can't be a fully-qualified > > domain name. > > > > cheers, > > raf > > From reading the code, these two restrictions seem equivalent except when > SMTPUTF8 extension is used. > when the SMTPUTF8 is in play, reject_non_fqdn_helo_hostname will convert a > hostname containing UTF to an internationalized domain name > before checking. https://en.wikipedia.org/wiki/Internationalized_domain_name > > So reject_invalid_helo_hostname will reject hostnames that contain UTF8 but > are otherwise valid. > It seems likely that reject_non_fqdn_helo_hostname was added to postfix to > replace reject_invalid_helo_hostname when emails containing UTF8 became a > thing. > > Intuitively, you might think that reject_non_fqdn_helo_hostname is MORE > restrictive than reject_invalid_helo_hostname, > but in fact reject_non_fqdn_helo_hostname is LESS restrictive than > reject_invalid_helo_hostname. > > At least, this is my understanding from reading the code. I may be wrong.. > > Sean. Hi Sean, I based my comments only on the documentation, not the code. But looking at the code, they both check that the hostname is valid, but reject_non_fqdn_hostname() also checks that there is a '.' character in the hostname (strchr(test_name, '.')). That's the additional fqdn check. But you are right that reject_invalid_hostname() calls valid_hostname() while reject_non_fqdn_hostname() calls valid_utf8_hostname(). I wonder if that is correct, or if they should both be calling valid_utf8_hostname(). It's probably correct and probably more efficient the way it is. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: invalid and non-fqdn hostname
On Thu, Apr 06, 2023 at 07:33:28AM +0800, Corey Hickman via Postfix-users wrote: > Hello > > for these two statements, > > reject_invalid_helo_hostname > reject_non_fqdn_helo_hostname > > what are the differences between them? does the second one hold the first > one already? > > Thanks. reject_invalid_helo_hostname rejects malformed HELO or EHLO hostnames. reject_non_fqdn_helo_hostname rejects non fully-qualified domain (or address) HELO or EHLO hostnames. I would assume that the second one subsumes the first, since a malformed hostname can't be a fully-qualified domain name. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Requesting A Sanity Check, Please, + A Couple Of Qs
qmgr > relay unix - - - - - smtp > -o smtp_connect_timeout=5 > -o smtp_helo_timeout=5 > -o syslog_name=postfix/$service_name > retry unix - - - - - error > rewrite unix - - - - - > trivial-rewrite > scache unix - - - - 1 scache > showq unix n - - - - showq > smtp inet n - - - 1 postscreen > -o postscreen_upstream_proxy_protocol=haproxy > -o postscreen_upstream_proxy_timeout=50s > smtp unix - - - - - smtp > smtpd pass - - - - - smtpd > submission inet n - - - - smtpd > -o milter_macro_daemon_name=ORIGINATING > -o smtpd_relay_restrictions=permit_sasl_authenticated,reject > -o smtpd_reject_unlisted_recipient=no > -o smtpd_sasl_auth_enable=yes > -o smtpd_sender_restrictions=reject_sender_login_mismatch > -o smtpd_tls_auth_only=yes > -o smtpd_tls_security_level=encrypt > -o syslog_name=postfix/submission > tlsmgr unix - - - 1000? 1 tlsmgr > tlsproxy unix - - - - 0 tlsproxy > trace unix - - - - 0 bounce > verify unix - - - - 1 verify > virtual unix - n - - - virtual > ~~~ I haven't examined your master.cf much, but since you have enabled tlsproxy, you might want to consider setting smtp_tls_connection_reuse=yes in main.cf. Since all mail is being relayed to the same server (sendinblue), reusing TLS connections should be more efficient. It requires tlsproxy which isn't enabled by default, but you have enabled it, so you might as well get the most benefit from it. > Further Questions > - > > 1) Do we need to add the mail.example.local's FreeIPA certificate to the > sni_maps? I don't think so. I don't think the sni_maps are needed at all but I could be wrong about that. If so, ignore this answer. Most SMTP clients don't care about the domain names in SMTP server certificates. But all of your incoming connections are from your own infrastructure so maybe you know something unusual about your internal clients that you haven't mentioned. > 2) Does it matter which external LE certificate we use for > smtp_tls_chain_files and/or smtpd_tls_chain_files? See above comments on these two parameters. smtp_tls_chain_files isn't needed at all because all outgoing mail is going to sendinblue which will not be requiring specific client certificates from you. As for smtpd_tls_chain_files, all incoming connections are coming from your own infrastructure (e.g. haproxy) which (like most SMTP clients) probably won't care what domain is used in your SMTP server certificate. > 3) Instead of using example.local for mydomain should we instead be using > example.com (or whichever of the external domain names we decide to use)? No. I think example.local is correct because it's the default value given that myhostname = mail.example.com. It's not supposed (necessarily) to reflect any of the domains whose mail is being handled. It's the domain name of the mail server itself, which is just whatever it is. When the internal and the external don't match, it's important to tell postfix by setting the proxy_interfaces parameter to the external IP address, and you have done that. > Thanks in advance > > Dulux-Oz Good luck! cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [P-U] Re: New List Host and Reply-to Header
On Sun, Mar 26, 2023 at 01:05:10PM +1300, Peter via Postfix-users wrote: > On 25/03/23 11:50, raf via Postfix-users wrote: > > On Fri, Mar 10, 2023 at 09:11:58AM +1300, Peter via Postfix-users > > wrote: > > > > > * Don't add a Reply-To:. I actually question if this is really needed as > > > we > > > likely want replies to go to the list the vast majority of time anyways. > > > I > > > have seen other lists explicitly exclude this step and it works well. > > > > > > Peter > > > > Removing Reply-To would remove functionality that is > > important, even if it is only occasionally required. > > Off-list replies would become impossible. That is a > > loss of functionality. Just because something is wanted > > the vast majority of the time, it doesn't mean that > > it's OK to enforce it 100% of the time. > > Mailman has a setting that addresses this, reply_goes_to_list. According to > mm docs, this adds the original From: address as a CC instead of Reply-To. > This means that an ordinary reply should go to the list (as it's listed in > From:) and Reply All will include the original sender. An off-list reply > could easily be done by Reply All then removing the list address. > considering that off list replies are much less common than list replies the > additional action of removing the list address should not be of great > concern. > > Peter That's OK since it remains possible to reply off-list. It's not as easy as single-letter actions to reply versus reply-to-list, but not all MUAs have a reply-to-list command. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [P-U] Re: New List Host and Reply-to Header
On Fri, Mar 10, 2023 at 09:11:58AM +1300, Peter via Postfix-users wrote: > * Don't add a Reply-To:. I actually question if this is really needed as we > likely want replies to go to the list the vast majority of time anyways. I > have seen other lists explicitly exclude this step and it works well. > > Peter Removing Reply-To would remove functionality that is important, even if it is only occasionally required. Off-list replies would become impossible. That is a loss of functionality. Just because something is wanted the vast majority of the time, it doesn't mean that it's OK to enforce it 100% of the time. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [P-U] Re: Postfix lists are migrating to a new list server
On Thu, Mar 09, 2023 at 01:21:02PM -0500, postfix--- via Postfix-users wrote: > > I am still seeing DKIM fails and two DKIM-Signatures. > > Is this correct? Haven´t seen this with other mails but I cannot rule out a > > config issue on my side. Is someone else observing that? > > Yes there will be two DKIM signatures due to the configuration of the mailing > list. > The first DKIM signature is from the email author to the mailing list. > The second DKIM signature is added by the mailing list when it is resent to > everyone on the list. > > The SPF will pass, because the email is from the list and matches the SPF > records. > The first DKIM signature created by the author will fail because the mailing > list altered the email adding a footer and reply-to headers. > The second DKIM signature will pass because it was signed by the list before > sending to you. > > With the SPF pass, and one DKIM pass, DMARC should pass and the email should > be accepted as legit. That's not exactly right. The DMARC policy of the original sender no longer applies because the From: header address is no longer that of the original sender. The From: header address is now postfix-mum...@postfix.org. If the postfix.com domain had a DMARC policy, then it would apply, but it doesn't have one. There is only SPF and DKIM. But that should suffice unless there are mail providers that annoyingly distrust anything without DMARC. cheers, raf ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: [SOLVED] Re: Submission runs very slowly
Apologies in advance if this is too off-topic (pass phrases, not postfix). On Mon, Feb 13, 2023 at 11:22:24PM +, Allen Coates wrote: > On 13/02/2023 22:43, raf wrote: > > And for diceware style passphrases to be meaningful, > > it's important that none of the words are "picked" by a > > human. They must be random. Then, it doesn't matter if > > they are common words or not. > A human can throw in a misspelt or foreign-language word. Probably > optimum if (s)he doctors a truly random selection. True, but it sounds manual. The best solution should just happen. Randomness is crucial. Any manual contribution is not random. > Also, don't forget numbers and special characters etc. I think a > human would need to add those, too. Yes, but only if fewer words were chosen (e.g., four). And of course, many websites insist on digits and/or special/punctuation characters (and some don't accept spaces as special/punctuation) even if the passphase is 50 characters in length, so manual nonsense is generally required. But it's not required for security. It's required by websites implemented by people that don't get it (sufficiently). > It occurs to me that, once "the enemy" gets past dictionary searches, > they won't know the actual password length. They > would have to explore random character sequences of EVERY length - and > not just that of YOUR password... That's right. That's why length is really the most important thing. If you have a 50 character pass phrase, it doesn't matter what it is. EXCEPT, please don't use a quote from literature (even manga! or twitter!) - ever. > Allen C Yes, the entropy I quoted assumes that the attacker knows exactly which dictionary was used. If that prior knowledge doesn't exist, then the apparent entropy (is that a thing?) would be much higher (I assume, but I know nothing). The short bit of advice is "the longer, the better". If a password is 20 characters in length, it's fairly safe. If it's 50 characters in length, it's awesome. cheers, raf
Re: [SOLVED] Re: Submission runs very slowly
On Mon, Feb 13, 2023 at 04:07:33PM -0500, Phil Stracchino wrote: > On 2/13/23 15:18, Daniele Nicolodi wrote: > > Isn't this estimate based on the assumption that the scheme used to > > generate the password is known? > > Well, sort of. But what it means in practice is that after the common > dictionary attack pass, you do a pass of permuting 3-4 common dictionary > words. Because most people who are going to use that password scheme aren't > going to pick words like floccinoccipilification. The target of > dictionary-based attacks is the low-hanging fruit. Apologies in advance if this is a lesson in how to suck eggs. :-) Dictionary-based attacks being for low-hanging fruit is predicated on a single-word password. It's no longer low-hanging fruit if, after trying 8000 single-word password guesses (the actual low-hanging fruit), you then need to check another 4 quadrillion guesses (8000^4) for the exactly-4-word pass phrases. And for diceware style passphrases to be meaningful, it's important that none of the words are "picked" by a human. They must be random. Then, it doesn't matter if they are common words or not. This page explains it well: https://diceware.rempe.us/#eff With a dictionary of ~8K words, each word has ~12.92 bits of entropy. i.e. Six words is pretty good. Ten words is very good. Four words is probably good enough for most website logins, but not for private key encryption passphrases. The page above links to more explanation here: https://theintercept.com/2015/03/26/passphrases-can-memorize-attackers-cant-guess/ cheers, raf
Re: Checking configuration files in advance
On Thu, Jan 26, 2023 at 05:47:32PM +, Pedro David Marco wrote: > Hi all, > Is there anyway to check for potential errors in Postifx confiuration files > before movig them to /etc/postfix > Thanks in advance! > Pete. Kind of. You can run "postconf -n" and "postconf -M" which show explicitly set configuration parameters and services in main.cf and master.cf, respectively, and as a side-effect, they will report any syntax errors, but that's all. There's nothing that checks for semantic errors. And of course, nothing can ever check that your configuration matches your intentions. postconf's -c option directs it to look at files somewhere other than /etc/postfix. Another thing to do is to monitor log output for a while after making configuration changes to look for fatal errors and useful warnings. cheers, raf
Re: Assist with a spam message, check_sender_access and check_client_access targets
On Fri, Jan 20, 2023 at 03:53:25PM -0600, Noel Jones wrote: > On 1/20/2023 3:25 PM, Scott Techlist wrote: > > I'm fuzzy on if I can block a message like the one below one using > > check_sender_access or check_client_access. > > check_sender_access is the envelope sender address, the > person/company/program who sent the mail. You can use the full email address > or just the domain. Note this may not be the same as the From: header. > check_sender_access is always an email address, or an email domain. > > check_client_access is for the computer that connect and send the mail. It > is identified by an IP address or a hostname. Note the hostname may not have > any obvious connection to the envelop sender or to the From: header. > check_client_access is always an IP address or a computer hostname, never an > email address. In other words, check_sender_access tests the address that ended up being stored in the From_ mbox pseudo header: From bounce-91040_html-994996332-142678-514026815-45...@bounce.s11.mc.pd25.com Fri Jan 20 12:40:11 2023 And check_client_access doesn't check any headers at all. It checks the IP address of the client making the SMTP connection. There is also the $header_checks parameter which lets you match content in arbitrary headers. See postconf(5) and header_checks(5). There is also spamassassin(1) and rspamd(1) for milter-based content inspection and spam detection. cheers, raf
Re: relay transport ignore
On Fri, Jan 20, 2023 at 03:25:39PM +0100, Matteo Cazzador
wrote:
> Hi, this is the postconf -n (i'm using virtualmin with virtual domain)
>
> *# postconf*
>
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> allow_percent_hack = no
> append_dot_mydomain = no
> biff = no
> broken_sasl_auth_clients = yes
> compatibility_level = 2
> header_checks = pcre:/etc/postfix/header_checks.pcre
> home_mailbox = Maildir/
> inet_interfaces = all
> inet_protocols = all
> mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
> mailbox_size_limit = 0
> message_size_limit = 3072
> milter_default_action = accept
> milter_protocol = 3
> mydestination = $myhostname, virtualmin.domain.it , localhost
> myhostname = virtualmin.domain.it
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> myorigin = /etc/mailname
> non_smtpd_milters =
> unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
Not relevant, but: The above line performs greylisting on
locally originating mail. I don't think that's usually done.
Greylisting is usually for mail that arrives over the network.
That's handled by the smtpd_milters below.
> readme_directory = no
> recipient_delimiter = +
> sender_bcc_maps = hash:/etc/postfix/bcc
> sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay
> smtp_dns_support_level = dnssec
> smtp_host_lookup = dns
> smtp_tls_loglevel = 0
> smtp_tls_mandatory_ciphers = medium
> smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
> smtpd_milters =
> unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
> smtpd_recipient_restrictions = check_recipient_access
> regexp:/etc/postfix/pcre_reject, permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination, check_policy_service,
> inet:127.0.0.1:10023 check_policy_service inet:127.0.0.1:10023
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
> defer_unauth_destination
> smtpd_sasl_auth_enable = yes
> smtpd_sender_restrictions = check_sender_access
> regexp:/etc/postfix/pcre_reject, permit_sasl_authenticated
> smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
> smtpd_tls_auth_only = no
> smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
> smtpd_tls_key_file = /etc/postfix/postfix.key.pem
> smtpd_tls_mandatory_ciphers = medium
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_received_header = yes
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = yes
> tls_medium_cipherlist =
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHA
> CHA20_POLY1305_SHA256
> tls_preempt_cipherlist = yes
> tls_random_source = dev:/dev/urandom
> tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
> transport_maps = hash:/etc/postfix/transport
> virtual_alias_maps = hash:/etc/postfix/virtual
>
> *# Transport (*/etc/postfix/transport*)
> *
>
> "domainname" relay:[oldhost IP] (i try smtp:[] too)
>
>
> domainname is the domain i refer.
>
> Thanks
If the double quote characters are really in the
transport file, remove them.
But I think the real problem is that you haven't
specified anywhere what domains the server will accept
for relaying. By default, the server will accept mail
for itself (i.e., $mydestination).
If you want it to accept mail for any other domains, you
need to specify them in one of these parameters:
relay_domains
virtual_alias_domains
virtual_mailbox_domains
See the postconf(5) manual entry for details. I suspect
that adding this might help:
relay_domains = domainname
with "domainname" replaced by the actual domain.
You can remove it when you later change the postfix
configuration on the second server to handle domainname
as a virtual domain (unless I've misunderstood your
intentions).
I'd recommend reading:
http://www.postfix.org/VIRTUAL_README.html
http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/SMTPD_ACCESS_README.html
cheers,
raf
> Il 17/01/2023 03:02, raf ha scritto:
> > On Fri, Jan 13, 2023 at 02:25:0
Re: SPF fail and domain fail, why?
On Tue, Jan 17, 2023 at 07:55:08PM +0100, Maurizio Caloro wrote: > > Am 17.01.2023 um 03:34 schrieb Scott Kitterman: > > > > On January 17, 2023 2:25:34 AM UTC, raf wrote: > > > On Mon, Jan 16, 2023 at 08:01:10PM +0100, Maurizio > > > Caloro wrote: > > > > > > > Hello > > > > > > > > Please one more thing about Opendmarc, if send any email to any where > > > > i see in log SPF fail, domain.ch fail ? > > > > > > > > Jan 16 19:43:39 nmail opendkim[16490]: B6090404C3: DKIM-Signature field > > > > added (s=nmail, d=caloro.ch) > > > > Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: SPF(mailfrom): > > > > caloro.ch > > > > fail > > > > Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: caloro.ch fail > > > > > > > > if recieve any mail from any where, any thing pass > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: mailc-bb.linkedin.com > > > > [A.B.C.D] not internal > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: not authenticated > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: message has > > > > signatures > > > > from linkedin.com, mailc.linkedin.com > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: signature=muv88Rcz > > > > domain=linkedin.com selector=d2048-201806-01 result="no signature > > > > error"; > > > > signature=IKaXoyzS domain=mailc.linkedin.com selector=proddkim1024 > > > > result="no signature error" > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: DKIM verification > > > > successful > > > > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: s=d2048-201806-01 > > > > d=linkedin.com SSL > > > > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3 ignoring > > > > Authentication-Results at 2 from nmail.caloro.ch > > > > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: SPF(mailfrom): > > > > bounce.linkedin.com pass > > > > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: linkedin.com pass > > > > > > > > -- > > > > on the header from any mail that i send will appair following > > > > Authentication-Results-Original: caloro.ch, calm-ness.ch; spf=fail > > > > > > > > # cat opendmarc.conf > > > > AuthservID caloro.ch, calm-ness.ch > > > > AuthservIDWithJobID false > > > > AutoRestart false > > > > AutoRestartRate 10/1h > > > > Background true > > > > DNSTimeout 5 > > > > HistoryFile > > > > /var/spool/postfix/opendmarc/opendmarc.dat > > > > *IgnoreAuthenticatedClients true* > > > > IgnoreHosts /etc/opendmarc/ignore.hosts > > > > PidFile /var/run/opendmarc/opendmarc.pid > > > > RejectFailures false > > > > RequiredHeaders true > > > > PublicSuffixList /etc/opendmarc/effective_tld_names.dat > > > > Socketinet:8892@127.0.0.1 > > > > SoftwareHeader true > > > > SPFSelfValidate true > > > > SPFIgnoreResults false > > > > Syslog true > > > > SyslogFacility mail > > > > # TrustedAuthservIDs nmail.caloro.ch, nmail.calm-ness.ch > > > > TrustedAuthservIDs caloro.ch, calm-ness.ch > > > > UMask 077 > > > > UserID opendmarc:opendmarc > > > > > > > > if checking online dmarc, dkim, spf from domain appair anything correct! > > > > please why me email will fail? > > > > > > > > thanks for any hint > > > > Mauri > > > I could be wrong, but I suspect that the problem is > > > that you haven't configured OpenDMARC to not check > > > locally originating mail. According to the first > > > Received: header, the mail is coming from 37.120.190.188 > > > (which is mentioned in multiple ways in the SPF record), > > > but your mail server at that IP address shouldn't be > > > performing this check on outgoing mail. > > > > > > Perhaps you need to add this to your /etc/opendmarc.co
Re: Enabling both redirection and local (virtual) delivery for catch-all email addresses?
On Tue, Jan 17, 2023 at 03:31:43PM +, sa212+post...@cyconix.com wrote: > I've been doing some tests with normal (foo@domain), catch-all (@domain), > and plussed (foo+foo@domain) addresses, with the virtual(8) delivery agent, > and virtual_alias_maps and virtual_mailbox_maps. > > The idea is to check the setup of users who want both redirection and > delivery to a local mailbox (with Dovecot, and Maildir format). > This worked as I expected, except in one case: when mail is sent to an > unknown recipient, and the catch-all setup is used, it's not possible to > both redirect the incoming mail, *and* have it delivered to a local mailbox. > Is this expected? It looks like a bug, because the destination MTA (the one > that receives the redirect) gets a badly-formed RCPT. > Tests as follows, with the virtual_alias_maps file being 'valias', and the > virtual_mailbox_maps file being 'vmailbox', and the local domain being > example.com: > > (1) Mail to known user 'f...@example.com': > > valias: "f...@example.com f...@example.com, f...@external.org" > vmailbox: "f...@example.com example.com/foo/" > > This works: external.org gets the mail, and Dovecot also gets the mail from > mailbox 'foo/'. > > (2) Mail to unknown user 'unkn...@example.com': > > valias: "@example.com @example.com, f...@external.org" > vmailbox: "@example.com example.com/foo/" > > This fails: external.org doesn't get the mail, but Dovecot does get the mail > from mailbox 'foo/'. > > The mail log at external.org shows that Postfix did try to redirect the > mail, but sent it to an invalid address: > > Recipient address rejected: User unknown in virtual mailbox table; > from= to=<"unkn...@example.com, foo"@external.org> I'm not suprised that it didn't work. I would have thought that "@example.com" is not a valid alias target since it's not a valid email address. That might not be the reason that it didn't work, but it would make sense. > Second question: with my current setup, an entry is created in virtual_alias > maps even if the user doesn't want redirection, but only wants local > delivery. In other words, if user 'bar' wants local delivery, then the file > entries are: > > valias: "b...@example.com b...@example.com" > vmailbox: "b...@example.com example.com/bar/" > > This works, and doesn't seem to cause a problem. I don't really want to > change the software to remove this (unnecessary) entry in valias. Are there > likely to be any problems with this? I don't know, but if it works, it will probably continue to work. cheers, raf
Re: SPF fail and domain fail, why?
On Mon, Jan 16, 2023 at 08:01:10PM +0100, Maurizio Caloro wrote: > Hello > > Please one more thing about Opendmarc, if send any email to any where > i see in log SPF fail, domain.ch fail ? > > Jan 16 19:43:39 nmail opendkim[16490]: B6090404C3: DKIM-Signature field > added (s=nmail, d=caloro.ch) > Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: SPF(mailfrom): caloro.ch > fail > Jan 16 19:43:39 nmail opendmarc[16483]: B6090404C3: caloro.ch fail > > if recieve any mail from any where, any thing pass > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: mailc-bb.linkedin.com > [A.B.C.D] not internal > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: not authenticated > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: message has signatures > from linkedin.com, mailc.linkedin.com > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: signature=muv88Rcz > domain=linkedin.com selector=d2048-201806-01 result="no signature error"; > signature=IKaXoyzS domain=mailc.linkedin.com selector=proddkim1024 > result="no signature error" > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: DKIM verification > successful > Jan 16 19:37:10 nmail opendkim[13804]: 10003404C3: s=d2048-201806-01 > d=linkedin.com SSL > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3 ignoring > Authentication-Results at 2 from nmail.caloro.ch > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: SPF(mailfrom): > bounce.linkedin.com pass > Jan 16 19:37:10 nmail opendmarc[15095]: 10003404C3: linkedin.com pass > > -- > on the header from any mail that i send will appair following > Authentication-Results-Original: caloro.ch, calm-ness.ch; spf=fail > > # cat opendmarc.conf > AuthservID caloro.ch, calm-ness.ch > AuthservIDWithJobID false > AutoRestart false > AutoRestartRate 10/1h > Background true > DNSTimeout 5 > HistoryFile /var/spool/postfix/opendmarc/opendmarc.dat > IgnoreAuthenticatedClients true > IgnoreHosts /etc/opendmarc/ignore.hosts > PidFile /var/run/opendmarc/opendmarc.pid > RejectFailures false > RequiredHeaders true > PublicSuffixList /etc/opendmarc/effective_tld_names.dat > Socket inet:8892@127.0.0.1 > SoftwareHeader true > SPFSelfValidate true > SPFIgnoreResults false > Syslog true > SyslogFacility mail > # TrustedAuthservIDs nmail.caloro.ch, nmail.calm-ness.ch > TrustedAuthservIDs caloro.ch, calm-ness.ch > UMask 077 > UserID opendmarc:opendmarc > > if checking online dmarc, dkim, spf from domain appair anything correct! > please why me email will fail? > > thanks for any hint > Mauri I could be wrong, but I suspect that the problem is that you haven't configured OpenDMARC to not check locally originating mail. According to the first Received: header, the mail is coming from 37.120.190.188 (which is mentioned in multiple ways in the SPF record), but your mail server at that IP address shouldn't be performing this check on outgoing mail. Perhaps you need to add this to your /etc/opendmarc.conf: IgnoreAuthenticatedClients true Unfortunately, the code doing the SPF check doesn't explain why it failed. Some do. For example, the postfix-policyd-spf-perl package on debian would probably show the IP address that caused the failure. Maybe it's 127.0.0.1 (or the IP address of an authenticated submission client). cheers, raf
Re: relay transport ignore
On Fri, Jan 13, 2023 at 02:25:06PM +0100, Matteo Cazzador wrote: > Hi, i 've question, i need to migrate a virtual domain from 2 server (with > postfix). > > On the new server i define mail users and domain but it'isnt in production > now dns record defined. > > On the same new soerver i've other virtual domain. > > I want that , for a few days, if one user of other domain hosted on the same > new server send an email to the new migrate domain it will be relayed to the > orld server and not locally delivered. > > I try with transport without success. > > Can someone plese help me? > > Thanks Perhaps it would be best to show what you tried by sending the output of "postconf -n" and your transport table on the new host. Someone might be able to see what's wrong with it. cheers, raf
Re: Simple forwarder for postfix?
On Wed, Jan 11, 2023 at 04:17:31PM -0800, Dan Mahoney wrote: > The idea of a command line program you can pipe a mail to with a > command line arg that lets you specify a list of recipients in a > textfile, and have new messages injected, cleanly, with stripped > headers, into the queue, feels like something that ought to exist. I have two old programs that might possibly be piped together to do that. textmail can strip headers by name, and launchmail can send mail (via SMTP) to a list of addresses from a file. Their documentation is here: https://raf.org/textmail/manpages/textmail.1.html https://libslack.org/launchmail/manpages/launchmail.1.html However, I haven't compiled launchmail in decades. I just tried, and it needs some updating before it will compile. If you think these might be of any use, I'll get launchmail compiling again. I never really used it. It was just written as an exercise. So it's probably dangerous to use it. :-) cheers, raf
Re: RFC 5233 "Subaddresses" and LDAP lookups
On Wed, Jan 11, 2023 at 09:02:23PM +0100, Patrick Ben Koetter wrote: > * Viktor Dukhovni : > > On Wed, Jan 11, 2023 at 03:57:28PM +0100, Patrick Ben Koetter wrote: > > > > > Today I ran into a lookup problem where a sender (!) was using the RFC > > > 5233 > > > subaddress schema so send a message e.g. as > > > localpart+subaddress@domainpart > > > and lookups with smtpd_sender_login_maps failed because I was unable to > > > come > > > up with a LDAP query_filter that would look for localpart@domainpart a ka > > > strip the subaddress. > > > > http://www.postfix.org/postconf.5.html#recipient_delimiter > > > > The documentation isn't clear on whether extensions are handled in > > > > http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps > > > > but they are. You shouldn't need any LDAP-specific support here, > > Postfix will automatically generate a query with the extension elided. > > Thanks! Makes me wonder why the setup I was testing today failed to behave > like you wrote. I'll try to reconstruct this on a test machine as soon as I > find time and verify that. Do you have "recipient_delimiter = +" in main.cf? > p@rick cheers, raf
Re: Authenticated Receive Chain (ARC Sealing) in Postfix?
On Mon, Jan 02, 2023 at 08:32:42PM +, "Cooper, Robert A" wrote: > I have a request from my downstream Exchange admins to look into > implementing ARC sealing in some postfix relay servers we use for > address rewriting. From the bit of research I've done, it looks like > this would require being implemented in an external milter. I had not > even heard of ARC before today; it looks like it's an experimental RFC > from 2019 that Microsoft and Google have implemented in their systems. > Does anyone have experience with ARC or how to set it up with postfix? > > Thanks > RobertC You could look into OpenARC (https://github.com/trusteddomainproject/OpenARC). I was under the impression that it wasn't finished, but I think that's wrong. I've heard of people using it. It's written by the same group that wrote OpenDKIM. cheers, raf
Re: Spammer succeeded in relaying through my server
On Tue, Dec 27, 2022 at 06:06:50PM -0800, Dan Mahoney wrote: > (Speaking with my Trusted Domain Project hat on). > > Yes, we'll take help. > > I have commit access to all the Github repos, and am trying to push > out a new release of OpenDKIM. I've been meaning to do this for > months, but life and family stuff has been getting in the way. > > Here are the things I'd really like to focus on: > > * Making it work with a more current autoconf (we already did this for > OpenDMARC) > * Making it build cleanly with modern openSSLs. There's a new pull request yesterday that does that. > * Making it support the latest dkim key types (the version you can > build from "devel" already does this.) > * Defining a set of "what the current state of OSes we test this thing > are". > > What I don't have the access to fix is our mailing lists, but I'm > trying to get that (or at least get a list of the members and fork > them off). Yeah, I tried lists.opendkim.org today and it's not there. > Rather than drag this thread on *far* too long, I'd strongly suggest > starting this discussion elsewhere, and this mailing list may not be > the place. > > The chicken-and-egg problem is that there are a bunch of linuxes that > I don't normally use that someone always insists are important. A lot > of the submitted patches are "works for me" but break things on other > platforms. And there's a bunch of stuff that, honestly, just needs to > be ripped the hell out (like the GnuTLS support). It sounds like automated testing for PRs is needed. But github actions doesn't support very many operating systems. > If people want to get together on some chat platform and bang things > out, I'd love to work with anyone who can. Sure. I can probably be useful. I was about to create a fork and (blindly) apply lots of the existing pull requests, but I'd prefer to contribute to a more sane effort. :-) > -Dan cheers, raf > > On Dec 27, 2022, at 16:59, Peter wrote: > > > > On 28/12/22 12:12, raf wrote: > >> Actually, it's been nearly five years since the last > >> commit. But dead is a strong word. I expect there's > >> still a lot of people using it. And there are 21 pull > >> requests. I've emailed the trusted domain project to > >> ask if it's dead, and if they'd accept help. If not, a > >> fork might be a good idea. > > > > Hopefully something comes of this. Opendkim is indeed highly used > > throughout the email community in both individual and commercial > > landscapes. It deserves to be well maintained. > > > > > > Peter
Re: Spammer succeeded in relaying through my server
On Mon, Dec 26, 2022 at 11:45:52AM +0200, mailm...@ionos.gr wrote: > On Mon, 26 Dec 2022 20:22:19 +1100 raf wrote: > > > That issue hasn't had any response, so maybe they aren't interested. > > But I've just created a pull request to fix it: > > > > https://github.com/trusteddomainproject/OpenDKIM/pull/160 > > > > They still might not be interested, but hopefully, this > > will make it more likely to happen. > > isn't opendkim a dead project? I think their last commit was two years ago... > > last time I checked, the EPEL package maintainer had to apply patches > manually because the opendkim owners had stopped working on their > project. Actually, it's been nearly five years since the last commit. But dead is a strong word. I expect there's still a lot of people using it. And there are 21 pull requests. I've emailed the trusted domain project to ask if it's dead, and if they'd accept help. If not, a fork might be a good idea. cheers, raf
Re: Spammer succeeded in relaying through my server
On Sat, Dec 24, 2022 at 08:05:12AM +0400, Samer Afach wrote: > Dear Raf: > > Thank you for the hint about UNIX sockets. I'll keep them. My only fear > is/was that they're inappropriate to use across containers and something > will break in the future. I guess I'll have to wait and see. Probably the easiest thing is to configure all the sockets to be in the same directory so that only a single directory needs to be imported into all the containers. > There's actually an open issue in OpenDKIM github with this request from > months ago: https://github.com/trusteddomainproject/OpenDKIM/issues/153 > > Hopefully someone will find the time to do it. That issue hasn't had any response, so maybe they aren't interested. But I've just created a pull request to fix it: https://github.com/trusteddomainproject/OpenDKIM/pull/160 They still might not be interested, but hopefully, this will make it more likely to happen. > Cheers, > Sam cheers, raf > On 24/12/2022 7:38 AM, raf wrote: > > On Sat, Dec 24, 2022 at 06:28:29AM +0400, Samer Afach > > wrote: > > > > > On 24/12/2022 5:30 AM, raf wrote: > > > > On Fri, Dec 23, 2022 at 04:35:03PM +0400, Samer Afach > > > > wrote: > > > > > > > > > About your great loud thought, my containers are versioned but > > > > > there's > > > > > no CI in there, and every launch for them recreates them. > > > > > They're all > > > > > based on either Debian or Ubuntu (depending on support for my > > > > > applications), which means they'll be updated automatically. I > > > > > don't > > > > > use random images from untrusted sources. There's even plan to > > > > > run apt > > > > > update/upgrade on every launch to ensure everything is up to > > > > > date even > > > > > if I forget to recreate a container for any reason, and I'm > > > > > planning > > > > > cron jobs that'll restart the containers daily. I really > > > > > appreciate > > > > > your loud thoughts, keep 'em coming, and I hope I have it > > > > > covered that > > > > > one with my plan. > > > > One thing to consider, rather than restarting the > > > > containers daily, is to install the unattended-upgrades > > > > package in the container and a configuration for it > > > > that automatically installs at least all security > > > > upgrades. That way, the container can stay running for > > > > long periods of time without the need to restart it > > > > daily which presumably introduces tiny regular outages. > > > > > > > > cheers, > > > > raf > > > Dear Raf: > > > > > > That's actually what I do on all the bare-metal machines, but from my > > > understanding of how docker works, every container is made to run exactly > > > one service, and somehow default Linux images disable system services. > > > They > > > can be re-enabled, but it's not the way it's meant to work, and given that > > > I'm just a beginner in this whole docker thing, I'm trying not to jump > > > over > > > rooftops before some time passes by and I feel comfortable with everything > > > I've done so far and build the confidence of "It worked for a while, now > > > let's try changing that one thing". > > Ah, I didn't realise that. Thanks. It makes sense I > > suppose. A container can have any number of processes > > in it, but the default assumption is going to be > > immutable infrastructure, and it won't include any > > processes that you don't put in there explicitly. > > > > However, you could maybe have a cronjob outside the > > container that starts a process inside the container to > > perform security updates. But it sounds like a hassle. > > If the mail volume isn't huge, the tiny outages when > > restarting might not be a problem, and so they don't > > need to be eliminated. > > > > > This can get much worse for beginners, and it took me a while to get email > > > working properly. If you notice in my setup, you'll see that postfix, > > > dovecot and OpenDKIM each is running in its own container (and they all > > > must > > > be running in foreground mode to access logging). > > > Luckily, sharing sock
Re: Spammer succeeded in relaying through my server
On Sat, Dec 24, 2022 at 07:51:42AM +0400, Samer Afach wrote: > Dear Raf: > > Thank you very much. I just tested my server with mxtoolbox, and all seems > good. I didn't realize mxtoolbox works without MX records, thanks for that > hint. > > I applied 90% of your suggestions, and some I didn't out of fear. I'm > working on understanding them more. Good decision. :-) > I have two questions if you don't mind. > > 1. I see you're telling me to remove smtpd_client_restrictions (for both 465 > and 587?) and only keep smtpd_recipient_restrictions. Can you please > elaborate on the difference? I thought clients connecting to the server are > what we need to restrict. I kind of failed to understand why > smtpd_recipient_restrictions even exists. The reason is that the only important restriction that you need (In my opinion) for ports 465/587 is SASL-authentication. It doesn't matter what the source IP address is if the authentication succeeds (that's assuming that you are certain that brute-force guessing of passwords from around the world won't succeed). The main purpose for smtpd_client_restrictions is to be able to reject connections at the very earliest stage of an SMTP connection: when the connection first happens, and the only information that is available to Postfix is the IP address of the client. So it makes sense to only put criteria there that are based on the source IP address (i.e., things like permit_mynetworks and RBL checks). If you put anything else in smtpd_client_restrictions, its evaluation has to wait until later in the connection. It'll still work, it's just not the "ideal" place for other criteria. The reason that there are many smtpd_*_restrictions parameters is that they each apply to a particular point in time during the SMTP protocol (e.g., HELO/EHLO, MAIL FROM, RCPT TO, DATA). So, you can specify checks that make sense at each point in time. However, for the most part, you can actually put all of the restrictions in a single smtpd_*_restrictions parameter and it will be fine. By default, the decisions are delayed until it's possible to evaluate the restrictions. The only real advantage to splitting up the criteria into separate restrictions parameters is that it makes it possible to reject connections at the earliest possible time. But that probably only matters when the mail volume is very high, and you want to maximise efficiency when rejecting connections (i.e., why wait until the RCPT TO command or DATA command if the HELO/EHLO command is unacceptable). The only real requirement is that you either use smtpd_recipient_restrictions or smtpd_relay_restrictions, and one of a certain set of items must appear in either (or both) of them, or Postfix won't accept that you have tried to prevent being an open relay. See http://www.postfix.org/SMTPD_ACCESS_README.html and the entries in postconf(5) for all of the smtpd_*_restrictions parameters. > With that logic, I only removed > the smtp_* part of the enforced protocols. My fear, which is very paranoid, > is that a peer of mine gets hacked, and then their email server uses nothing > but unencrypted connection. Forcing encryption basically means this issue > will be noticeable. (and if you're wondering why port 25's encryption is > `may` in main.cf, it's because I still don't know how to get fetchmail to > deliver emails without that... another issue to be solved). The restrictions and whether or not encryption happens are not related to each other. Port 25's encryption should definitely be "may". I said that SASL-authentication shouldn't be enabled on port 25. That's not the same thing. Encryption/STARTTLS for incoming connections on port 25 is enabled with smtpd_tls_security_level=may in main.cf. That's great. Keep that. SASL-authenticated for incoming connections on port 25 is enabled with smtpd_sasl_auth_enable=yes in main.cf. That's not useful (other MTAs won't SASL-authenticate with your server on port 25), so it can be removed. The only place that smtpd_sasl_auth_enable=yes is useful is in master.cf when defining the services for ports 465 and 587. Also, you weren't forcing encryption. You you just excluding certain TLS versions from being used when encryption was used. The parameters with "mandatory" in their names excluded certain versions of TLS when *mandatory* encryption was in place. But there was nothing in your configuration that made encryption mandatory. Making encryption mandatory requires something like smtpd_tls_security_level=encrypt or smtpd_tls_wrappermode=yes but you can't do that for port 25. It's important to realise that for email, encryption is almost always opportunistic, not mandatory. Any encryption is better than none when it comes to opportunistic encryption. There can be case
Re: Spammer succeeded in relaying through my server
On Sat, Dec 24, 2022 at 06:28:29AM +0400, Samer Afach wrote: > On 24/12/2022 5:30 AM, raf wrote: > > On Fri, Dec 23, 2022 at 04:35:03PM +0400, Samer Afach > > wrote: > > > > > About your great loud thought, my containers are versioned but there's > > > no CI in there, and every launch for them recreates them. They're all > > > based on either Debian or Ubuntu (depending on support for my > > > applications), which means they'll be updated automatically. I don't > > > use random images from untrusted sources. There's even plan to run apt > > > update/upgrade on every launch to ensure everything is up to date even > > > if I forget to recreate a container for any reason, and I'm planning > > > cron jobs that'll restart the containers daily. I really appreciate > > > your loud thoughts, keep 'em coming, and I hope I have it covered that > > > one with my plan. > > One thing to consider, rather than restarting the > > containers daily, is to install the unattended-upgrades > > package in the container and a configuration for it > > that automatically installs at least all security > > upgrades. That way, the container can stay running for > > long periods of time without the need to restart it > > daily which presumably introduces tiny regular outages. > > > > cheers, > > raf > > Dear Raf: > > That's actually what I do on all the bare-metal machines, but from my > understanding of how docker works, every container is made to run exactly > one service, and somehow default Linux images disable system services. They > can be re-enabled, but it's not the way it's meant to work, and given that > I'm just a beginner in this whole docker thing, I'm trying not to jump over > rooftops before some time passes by and I feel comfortable with everything > I've done so far and build the confidence of "It worked for a while, now > let's try changing that one thing". Ah, I didn't realise that. Thanks. It makes sense I suppose. A container can have any number of processes in it, but the default assumption is going to be immutable infrastructure, and it won't include any processes that you don't put in there explicitly. However, you could maybe have a cronjob outside the container that starts a process inside the container to perform security updates. But it sounds like a hassle. If the mail volume isn't huge, the tiny outages when restarting might not be a problem, and so they don't need to be eliminated. > This can get much worse for beginners, and it took me a while to get email > working properly. If you notice in my setup, you'll see that postfix, > dovecot and OpenDKIM each is running in its own container (and they all must > be running in foreground mode to access logging). > Luckily, sharing socket > files in Linux is allowed among containers, and the reasoning there, if I > understand correctly, is that all these containers use the same kernel, and > that's the only required condition. This simplified my setup a lot. Over > time I'll have to move everything to inet and stop using socket files > because it sounds dirty. I wouldn't be too keen to do that. UNIX domain sockets are faster than TCP. There's nothing dirty about them. It's just another network address family. And they have some nice benefits. > The worst part in all this is OpenDKIM. It doesn't support stdout logging, > which means I have to force the rsyslog service to work to see any errors, > but given that its docker should start with exactly 1 program in the > foreground, I don't know how to print the logs with something like tail > since OpenDKIM is running in the foreground. Another problem to be looking > into soon when I'm done with all these more prior piling issues. > Too much unsolicited information. Apologies, but I wanted to make the > situation clear, because this is a typical problem in docker. I'd be tempted to see all of these related processes as a single service (i.e. mail), and putting them in the same container with rsyslog. :-) But that's probably silly. The OpenDKIM authors would probably accept a patch for an option that logs to stdout rather than via syslog() for use in Docker. It should be easy enough to do. If not, at least raise an issue with them. They'd probably be happy to make their software easier to use in Docker. > Cheers, > Sam cheers, raf
Re: Restrict access relay to single client
On Fri, Dec 23, 2022 at 01:14:26PM -0800, Jim Garrison wrote:
> I have Postfix running inside a private LAN as an outgoing relay via
> GMail (no incoming Internet connections). I have two goals
>
> 1. Relay only to one specific domain
> 2. Accept relay from only one specific LAN client
>
> So I configured the following (complete postconf -n appended below):
>
> myhostname = host.internal.lan
> mynetworks = 192.168.0.105
> 127.0.0.0/8
> [:::127.0.0.0]/104
> [::1]/128
> relay_domains = mydomain.com
> relayhost = [smtp.gmail.com]:587
> smtpd_relay_restrictions = permit_mynetworks
>reject_unauth_destination
>
> This works for the first objective, and blocks relaying to any address
> not in mydomain.com.
>
> Dec 23 12:21:16 janus postfix/smtpd[9974]: connect from
> unknown[192.168.0.175]
> Dec 23 12:22:10 janus postfix/smtpd[9974]: NOQUEUE: reject: RCPT from
> unknown[192.168.0.175]: 554 5.7.1 : Relay access denied;
> from= to= proto=SMTP
> helo=
>
>
> I was also expecting the $mynetworks setting to allow relaying from
> only that one specific host (.105) (as well as the local system) while
> blocking relaying from any other LAN host.
>
> What I actually see is that any host on the LAN is allowed to relay (I
> tested from 192.168.0.175). Here are the log entries:
>
> Dec 23 12:24:01 janus postfix/smtpd[9974]: CC31BC0281:
> client=unknown[192.168.0.175]
> Dec 23 12:24:17 janus postfix/cleanup[9984]: CC31BC0281: message-id=<>
> Dec 23 12:24:17 janus postfix/qmgr[9910]: CC31BC0281:
> from=, size=225, nrcpt=1 (queue active)
> Dec 23 12:24:18 janus postfix/relay/smtp[9992]: CC31BC0281:
> to=, relay=smtp.gmail.com[142.251.116.109]:587,
> delay=22, delays=21/0.03/0.69/0.53, dsn=2.0.0, status=sent (250 2.0.0 OK
> 1671827058 l14-20020a056870f14e00b0014b8347e1e3sm1987913oac.12 - gsmtp)
> Dec 23 12:24:18 janus postfix/qmgr[9910]: CC31BC0281: removed
>
>
> I've studied the excellent documentation thoroughly, and even found
> several how-to's on the web saying this is the way to restrict relaying
> to a specific client.
>
> What have I missed?
>
> postconf -n output (slightly redacted):
>
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> compatibility_level = 2
> html_directory = /usr/share/doc/postfix/html
> inet_interfaces = all
> inet_protocols = ipv4
Not relevant to your problem, but the above says that
only ipv4 is used but your config includes ipv6
addresses. You might want to delete it (and default to
"all"), or remove the ipv6 addresses from your config.
> mailbox_size_limit = 0
> mydestination = $myhostname, host, localhost.internal.lan, localhost
> myhostname = host.internal.lan
> mynetworks = 192.168.0.105 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> myorigin = $myhostname
> readme_directory = /usr/share/doc/postfix
> recipient_delimiter = +
> relay_domains = mydomain.com
> relayhost = [smtp.gmail.com]:587
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options =
> smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
You probably don't need smtp_tls_CAfile (but I could be wrong).
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
> smtpd_relay_restrictions = permit_mynetworks reject_unauth_destination
This is the problem. You need to add "reject" to the
end of smtpd_relay_restrictions. Without it, it
implicitly ends with "permit".
In http://www.postfix.org/SMTPD_ACCESS_README.html),
it says:
Each restriction list is evaluated from left to right
until some restriction produces a result of PERMIT,
REJECT or DEFER (try again later). The end of each
list is equivalent to a PERMIT result.
I recommend always having "permit" or "reject" at the
end of all smtpd_*_restrictions parameters. Even if
it's just to make the implicit "permit" explicit and
visible.
> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_database isn't needed (since Postfix 2.11)
> smtpd_use_tls = yes
It's not important, but smtpd_use_tls (and smtp_use_tls)
are obsolete and could be replaced with:
smtpd_tls_security_level = may
smtp_tls_security_level = may
cheers,
raf
Re: Spammer succeeded in relaying through my server
the contents of privkey.pem followed by the
contents of fullchain.pem. If the contents of these
files change on a regular schedule (such as via
LetsEncrypt), then you'd need to automate the creation
of such a file whenever the two source files change.
The benefit of doing this is that it eliminates the
slight chance of a race condition while the files are
being updated and Postfix might read the old version of
one file and the new version of the other file.
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
See the note above about the smtp_ versions of the above two.
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
The above parameter isn't needed anymore (since Postfix 2.11).
It should be removed.
> smtpd_use_tls = yes
The above is obsolete/redundant when smtpd_tls_security_level is set.
> virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
> virtual_gid_maps = static:5000
> virtual_mailbox_base = /var/vmail/
> virtual_mailbox_domains =
> proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = 0
> virtual_mailbox_maps =
> proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 104
> virtual_transport = lmtp:inet:docker-email-dovecot:10024
> virtual_uid_maps = static:5000
> ```
>
> I would really appreciate your input on this. Have a great day.
>
> Cheers,
> Sam
cheers,
raf
Re: Spammer succeeded in relaying through my server
On Fri, Dec 23, 2022 at 04:35:03PM +0400, Samer Afach wrote: >About your great loud thought, my containers are versioned but there's >no CI in there, and every launch for them recreates them. They're all >based on either Debian or Ubuntu (depending on support for my >applications), which means they'll be updated automatically. I don't >use random images from untrusted sources. There's even plan to run apt >update/upgrade on every launch to ensure everything is up to date even >if I forget to recreate a container for any reason, and I'm planning >cron jobs that'll restart the containers daily. I really appreciate >your loud thoughts, keep 'em coming, and I hope I have it covered that >one with my plan. One thing to consider, rather than restarting the containers daily, is to install the unattended-upgrades package in the container and a configuration for it that automatically installs at least all security upgrades. That way, the container can stay running for long periods of time without the need to restart it daily which presumably introduces tiny regular outages. cheers, raf
Re: Spammer succeeded in relaying through my server
On Fri, Dec 23, 2022 at 09:51:48AM +0400, Samer Afach wrote: > I see. Thank you for the explanation. So the right way to state this is that > HELO/EHLO requires a valid FQDN/hostname only for MTAs, and for MUAs it's > just ignored because authentication is what matters. > > Cheers, > Sam It's only ignored when configured to be ignored. The way that the difference between port 25 and port 587 is implemented is that main.cf has settings for smtpd_*_restrictions that are used for MTA-to-MTA traffic on port 25, e.g.: /etc/postfix/main.cf: smtpd_helo_restrictions = permit_mynetworks check_helo_access hash:/etc/postfix/helo-access reject_invalid_helo_hostname reject_non_fqdn_helo_hostname # The following is unwise without the check_helo_access # above and constant monitoring for false positives. reject_unknown_helo_hostname permit And then master.cf contains services with overrides to the settings in main.cf, and the overrides apply to the particular service, e.g. for port 587: /etc/postfix/master.cf: submission inet n - y - - smtpd -o syslog_name=postfix/$service_name -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject The above submission service contains smtpd_helo_restrictions= which replaces the smtpd_helo_restrictions setting in main.cf but only for connections that come in via port 587 which, thanks to the overriding smtpd_tls_security_level=encrypt must be encrypted, and thanks to the overriding smtpd_relay_restrictions setting, must be SASL-authenticated. cheers, raf
Re: Spammer succeeded in relaying through my server
On Fri, Dec 23, 2022 at 06:19:06AM +0400, Samer Afach wrote: > Btw, the relays happened because I actively changed mynetworks_style to > subnet, forgetting and not checking that all incoming connections will come > from the gateway of docker subnet. Still under research to identify how that > works. I'm not sure that that's right. I expect that the incoming connections that HAproxy sees have their original remote IP addresses (not the address of the "gateway of docker subnet"). It's just that the HAproxy is in the same Docker network as Postfix, so when it initiates a connection to Postfix in order to proxy the incoming connection, Postfix sees the internal IP address that HAproxy is using. By the way, it seems odd to me that HAproxy would be on the same physical host as the service being HAproxied. I wouldn't have thought that HAproxy could add any high-availability in that situation. cheers, raf
Re: Planning my migration: preventing open relay
arily aimed at things that communicate only via TCP. But take that with a grain of salt. I am barely a Docker novice. I don't doubt that Postfix could be packaged up with Docker, and that would make migration easier, but so would Ansible. I prefer apt and automated security upgrades to immutable infrastructure. In general, that's silly, but Docker (and immutable infrastucture) makes more sense when you need many equivalent transient VMs, not a single, stable MX host. But of course, that's just my opinion. > BTW, I mentioned traefik but I will not be running postfix behind > traefik. I want postscreen to be the doorman on port 25 traffic. > > Thanks for tips and suggestions. > > Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>) > R&A IT Strategy <https://ea.rna.nl/> (main site) > Book: Chess and the Art of Enterprise Architecture > <https://ea.rna.nl/the-book/> > Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/> cheers, raf
Re: Spammer succeeded in relaying through my server
On Thu, Dec 22, 2022 at 04:47:57AM +0400, Samer Afach wrote: > If I were you, I'd focus on my lack of understanding of the email protocol. > Now that, is a part that I still cannot fully understand, embarrassingly so. > I still don't know what ehlo means, except that it's the first message. I > don't know why it matters what address we put after it. That does make me > look like an idiot, doesn't it? :-) There are hundreds of RFCs (at least!) involved in all the facets of email. Nobody is born having already read them all. Learning anything takes time. And email is famously complex. There's an old quote from Sendmail's documentation that says: The world is complex, and the mail configuration reflects that. But you don't have to read all the RFCs, they are mostly for implementers. Although I recommend it whenever you really want to understand the details of formats and protocols that you are interested in. It might seem daunting, but it's worth the effort. Reading a fair amount of Postfix documentation is needed, though, if using Postfix to handle your email, and your requirements aren't simple. The http://www.postfix.org website has links to lots of documentation. Read what seems relevant to your needs. And look for tutorials relevant to your needs elsewhere on the internet as well. Back to EHLO... EHLO is the first client message in the SMTP protocol. Originally, the first message was HELO and it includes the hostname of the client (so the server knows who is saying hello). That matters because a lot of mail servers will check that that hostname is sensible. They do that because (presumably) a lot of spam comes from clients that don't provide a sensible hostname. Ideally, the hostname would be one that matches the public IP address of the mail server. EHLO is an extension to the SMTP protocol that causes the server to send back a list of features that it supports, so that the client knows what it can do with that server (e.g., STARTTLS, SMTPUTF8, 8BITMIME, etc.). cheers, raf
Re: Spammer succeeded in relaying through my server
On Thu, Dec 22, 2022 at 02:23:53PM -0500, post...@ptld.com wrote: > > On 12-22-2022 2:18 pm, mailm...@ionos.gr wrote: > > sorry to have to burst your bubble, but postfix does not have documentation > > > > at least not in the way we call documentation these days > > maybe you'd call them "notes" or a "reference guide" but not real > > documentation > > > > it is helpful to people who already know everything, but not helpful to > > people who are learning > > I would disagree. > Postfix has documentation, however it is not a tutorial which is what i think > you are describing. > Documentation isn't meant to be a how-to or tutorial. I disagree with both. I found that reading all of Postfix's documentation did help me to learn a lot about it, and to finally understand the configuration that I'd inherited from someone else that I'd been using for years only tweaking slightly for my needs. But that probably just suits my preferred way of learning. But not everyone has time to do that. There is a lot of documentation to read. But also, some of a system's documentation can definitely take the form of how-to guides and tutorials. Postfix has many How-To Guides. My favourite theory of documentation is explained here: https://documentation.divio.com/ There are four forms of documentation: Tutorials: Learning-oriented How-To Guides: Problem-oriented Explanation: Understanding-oriented Reference: Information-oriented Postfix itself provides Reference and How-To Guides, but not so much in the way of Tutorials (which others have written and they are available elsewhere online), or Explanation (hundreds of RFCs don't count unless you've really got a lot of time to spare). :-) Postfix's documentation could be improved with more "Explanation" documents, and "Tutorials" (not all that are out there give good advice), but someone has to have the time and desire and ability to write them. Actually, the "Explanation" part of the documentation is probably handled best by the Postfix book: Postfix: The Definitive Guide by Kyle D. Dent https://www.seaglass.com/postfix/ And there are good tutorials/how-tos out there. So maybe all four forms of documentation are well represented, they're just scattered around the internet. If there isn't a How-To for Postfix in Docker and/or behind HAProxy yet, then it would be great if someone who was setting that up and encountering and solving any problems along the way were able to write and publish a How-To Guide to benefit others. cheers, raf
Re: Spammer succeeded in relaying through my server
On Thu, Dec 22, 2022 at 09:18:07PM +0200, mailm...@ionos.gr wrote: > On Thu, 22 Dec 2022 19:05:47 +0100 Matthias Andree > wrote: > > > Postfix has been around for a quarter century, and it has always been > > *the* example of good design, documentation and compatibility with > > predecessor versions. > > sorry to have to burst your bubble, but postfix does not have documentation > at least not in the way we call documentation these days > maybe you'd call them "notes" or a "reference guide" but not real > documentation > it is helpful to people who already know everything, but not helpful to > people who are learning Postfix's documentation consists of about 129 documents. I'd call it a heroic effort of documentation. They do a fairly good job of explaining in precise detail what you need to know. It can be easy to miss some important detail in some cases, but once you realise that and go back to the documentation, what you needed to know is usually there. Once you realise that, you know to read them more carefully. cheers, raf
Re: Duplicate message delivery to always_bcc with dovecot and Simple Content Filter (Postfix)
On Mon, Dec 19, 2022 at 12:21:02PM -0500, Yanko Hernández Álvarez wrote: > On Mon, Dec 19, 2022 at 11:36 AM Matus UHLAR - fantomas > wrote: > > >#!/bin/sh > > > > > >/usr/bin/cat | /var/spool/filter/scripts/mailfilter | > > >/usr/sbin/sendmail -G -i "$@" > > > > > >exit $? > > > > this means that the always_bcc is executed again. > > usually the content_filter is supposed to inject mail on alternative port > > where option: > > receive_override_options = no_address_mappings > > > > is used: see http://www.postfix.org/FILTER_README.html > > > > Yes, I'm aware of that, but I was trying not to use the advanced filter. > > In the end it seems that there is no alternative to the advanced > filter. But I'm asking here in case I overlooked something or > misunderstood something. Perhaps I'm mistaken, but it sounds like mailfilter could be replaced with canonical addressing to rewrite sender addresses in outgoing emails. http://www.postfix.org/ADDRESS_REWRITING_README.html#canonical If so, it might simplify things. cheers, raf
Re: emails with s9b1.psmtp.com
On Fri, Dec 16, 2022 at 10:40:53AM +1100, raf wrote: > On Thu, Dec 15, 2022 at 03:54:38PM -0600, Richard Raether > wrote: > > > Dear users wiser than me (probably everyone), > > > > We have a legitimate domain, einsteintoolkit.org, but I'm getting mail for > > einsteintoolkit.org.s9b1.psmtp.com, which postfix doesn't allow through > > because it doesn't recognize it as a legitimate domain. What am I > > misunderstanding about psmtp and how it works, and does anyone know how I > > can get these emails properly delivered? > > > > Any advice is welcome. > > > > Thanks, > > > > Richard Raether > > Sysadmin > > Center for Computation and Technology > > Louisiana State University > > [Warning: Rhetorical questions ahead] > > Why do you want them to be delivered? > They are not for your domain. > > How are they getting to your server? > There is no MX record for that domain. > psmtp.com has NS/SOA/TXT(spf) records, > but that's it (I think). None of the > subdomains seem to have any records at all. > So no remote server should be sending > such emails to your server. > > Are those emails generated locally on your > server? If not, it could be a malicious server > targetting your server (bcause it's not following > the normal protocols for working out where to > send an email). > > And sorry, I have no idea how psmtp.com works > or what it's supposed to do. Googling shows these: > > The Science behind Mail Delivery > https://litmus.com/community/discussions/46-the-science-behind-mail-delivery > > Which mentions something called postini > > and: > > MX records explained > https://help.salesforce.com/s/articleView?id=000385607&type=1 > > Which shows an example where a similar domain is the name used > in salesforce.com's MX records, but in that case, the similar > domains had IP addresses (at the time). The domain you mentioned > doesn't. > > It looks like maybe postini (or your organisation's > instance) is defunct. Actually, googling postini shows > that it is probably globally dead: > > Why Postini is Moving to the Google Graveyard > https://sendgrid.com/blog/postini-moving-google-graveyard/ > > https://en.wikipedia.org/wiki/Postini > > So it looks like it's been dead since 2015. > > Perhaps that means that some server somewhere is using > seven year old cached DNS records. But that doesn't > sound possible. > > It might not be worth worrying about, unless it is, in > which case you should probably try to contact whoever > is sending them and get them to stop using seven year > old MX records. But you really shouldn't have to ask > someone to do that. Just letting the emails bounce > should server that purpose adequately. Whoever is > sending them will know that it's not working and can > contact their email administrator for help. > > Your logs should show the IP address or hostname of the > server that connected to your server and tried to send > those emails. Perhaps you can contact its postmaster > and alert them to the problem. > > cheers, > raf Actually, the sender can't just be using old old MX records since there's no corresponding A records that would point to your server. But something wierdly broken is happening at the sender end. cheers, raf
Re: emails with s9b1.psmtp.com
On Thu, Dec 15, 2022 at 03:54:38PM -0600, Richard Raether wrote: > Dear users wiser than me (probably everyone), > > We have a legitimate domain, einsteintoolkit.org, but I'm getting mail for > einsteintoolkit.org.s9b1.psmtp.com, which postfix doesn't allow through > because it doesn't recognize it as a legitimate domain. What am I > misunderstanding about psmtp and how it works, and does anyone know how I > can get these emails properly delivered? > > Any advice is welcome. > > Thanks, > > Richard Raether > Sysadmin > Center for Computation and Technology > Louisiana State University [Warning: Rhetorical questions ahead] Why do you want them to be delivered? They are not for your domain. How are they getting to your server? There is no MX record for that domain. psmtp.com has NS/SOA/TXT(spf) records, but that's it (I think). None of the subdomains seem to have any records at all. So no remote server should be sending such emails to your server. Are those emails generated locally on your server? If not, it could be a malicious server targetting your server (bcause it's not following the normal protocols for working out where to send an email). And sorry, I have no idea how psmtp.com works or what it's supposed to do. Googling shows these: The Science behind Mail Delivery https://litmus.com/community/discussions/46-the-science-behind-mail-delivery Which mentions something called postini and: MX records explained https://help.salesforce.com/s/articleView?id=000385607&type=1 Which shows an example where a similar domain is the name used in salesforce.com's MX records, but in that case, the similar domains had IP addresses (at the time). The domain you mentioned doesn't. It looks like maybe postini (or your organisation's instance) is defunct. Actually, googling postini shows that it is probably globally dead: Why Postini is Moving to the Google Graveyard https://sendgrid.com/blog/postini-moving-google-graveyard/ https://en.wikipedia.org/wiki/Postini So it looks like it's been dead since 2015. Perhaps that means that some server somewhere is using seven year old cached DNS records. But that doesn't sound possible. It might not be worth worrying about, unless it is, in which case you should probably try to contact whoever is sending them and get them to stop using seven year old MX records. But you really shouldn't have to ask someone to do that. Just letting the emails bounce should server that purpose adequately. Whoever is sending them will know that it's not working and can contact their email administrator for help. Your logs should show the IP address or hostname of the server that connected to your server and tried to send those emails. Perhaps you can contact its postmaster and alert them to the problem. cheers, raf
Re: remailer for alias lists?
On Sun, Dec 04, 2022 at 03:59:07PM -0800, Dan Mahoney wrote: > My needs are pretty much two things: > > 1) Only subscribed people may post. > 2) That post should not get killed by DMARC, which means forwarded > messages need to pass SPF/DKIM, which means remailing, not forwarding. > > The state of mailing list managers right now is also complex. Would > you rather have: > > The one that is based on a two-years EOL version of python with no > clean migration path to the current version (which still inexplicably > has a TON of open source stuff under it, including ISC, IETF, and > NANOG) (mailman2) > > Or the "current version" of that one that takes not only a database > but also four different packages plus a full nginx/django install to > set up (mailman3) > > Or the perl-based one written for perl 4 with the last release > sometime in 2000 (majordomo)? > > If there's a better piece of software, please let me know. Assuming that wasn't a rhetorical question, :-) I'd consider majordomo. It probably does what you need without being a hassle. It works in Perl 5 too, you know. :-) And it doesn't need a database or a web server. If memory serves, you need to set up enough aliases for each mailing list that it's worth automating their addition, but if it's a single list, you wouldn't need to. This is what I used to have in aliases for each list. # Majordomo template # (e.g. (LIST, DOMAIN, DOM, ME) = (firewall-users, fwup.org, fwup, raf)) # # majordomo-DOM: "| /opt/majordomo/wrapper majordomo -C /opt/majordomo/DOMAIN.cf" # owner-majordomo-DOM: ME # # Mailing List Template (with digest and archive) # # LIST: "| /opt/majordomo/wrapper resend -C /opt/majordomo/DOMAIN.cf -l LIST -h DOMAIN LIST-outgoing" # LIST-digest: LIST # LIST-outgoing: :include:/opt/majordomo/lists/DOMAIN/LIST, # "| /opt/majordomo/wrapper digest -c /opt/majordomo/DOMAIN.cf -r -C -l LIST-digest LIST-digest-outgoing", # "| /opt/majordomo/wrapper archive2.pl -C /opt/majordomo/DOMAIN.cf -a -m -f /opt/majordomo/lists/DOMAIN/LIST.archive" # LIST-digest-outgoing: :include:/opt/majordomo/lists/DOMAIN/LIST-digest # owner-LIST: owner-majordomo-DOM # owner-LIST-outgoing: owner-LIST # owner-LIST-digest: owner-LIST # owner-LIST-digest-outgoing: owner-LIST # LIST-request: "| /opt/majordomo/wrapper majordomo -C /opt/majordomo/DOMAIN.cf -l LIST" # LIST-digest-request: "| /opt/majordomo/wrapper majordomo -C /opt/majordomo/DOMAIN.cf -l LIST-digest" # LIST-approval: owner-LIST # LIST-digest-approval: owner-LIST The above creates digests and archives (both optional), but it does nothing to make the archives available on the web. Oh, actually majordomo.pl shouldn't work in perl5 since 5.10. It uses $* which was removed then (2007). That's wierd. It was still working for me in 2015. But here's a version that has that fixed for later perls: https://github.com/Distrotech/majordomo And here's a version of majordomo 2 (which I hadn't heard of before): https://github.com/jasontibbitts/majordomo cheers, raf
Re: helo command rejected
On Fri, Dec 02, 2022 at 09:47:03AM -0500, Wietse Venema wrote: > raf: > > On Fri, Dec 02, 2022 at 08:51:14AM -0500, Wietse Venema > > wrote: > > > > > David Dolan: > > > > I guess it's using the musl resolver in Alpine so we need to migrate OS > > > > to > > > > get past this issue? > > > > > > Yes. Don't use toy software in production. > > > > > > Wietse > > > > I suspect that alpine is used in many many > > docker images in production systems everywhere. :-) > > By that argument we should all eat shit because 50 billion flies > can't be wrong. > > Wietse It wasn't an argument. It was a scary observation. :-) cheers, raf
Re: Backup MX Take 2
On Fri, Dec 02, 2022 at 10:24:29AM -0500, Jonathan Capra wrote: > > OK this is weird. > > I have in main.cf: > > relayhost = helix.wtfayla.net I don't think you need the above line. The fact that helix is the primary MX server is enough for Postfix on caduceus to know to send mail for the relayed domains to it. The relayhost parameter applies to all non-local mail. See http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup But it might be OK if caduceus doesn't send any mail of its own anywhere, or if helix is willing to relay that mail on behalf of caduceus. cheers, raf
Re: helo command rejected
On Fri, Dec 02, 2022 at 08:51:14AM -0500, Wietse Venema wrote: > David Dolan: > > I guess it's using the musl resolver in Alpine so we need to migrate OS to > > get past this issue? > > Yes. Don't use toy software in production. > > Wietse I suspect that alpine is used in many many docker images in production systems everywhere. :-) cheers, raf
Re: Backup MX Take 2
On Thu, Dec 01, 2022 at 02:38:49PM -0500, Viktor Dukhovni wrote: > On Thu, Dec 01, 2022 at 11:32:01AM -0500, Jonathan Capra wrote: > > > However what I'm doing is having the primary server extract valid > > addresses (mailboxes and aliases) from MySQL, compile them into postfix > > format (OK), and then rsync it over the the > > secondary in the form of /etc/postfix/relay_recipients twice a day. > > > > Two minutes later, on the secondary side, it moves it to /etc/postfix, and > > runs postmap on the file to create /etc/postfix/relay_recipient_maps.db. > > It then restarts postfix. > > You DO NOT need to restart Postfix when the table changes. Just use > the safe table update instructions and leave Postfix as-is. > > https://www.postfix.org/DATABASE_README.html#safe_db > > > relay_recipient_maps = hash:/etc/postfix/relay_recipients > > > > relay_domains = ,,... > > > > However when I telnet to port 25, I feed it this, it accepts it just > > fine still, and forces my primary to generate a bounceback: > > > > # telnet caduceus.wtfayla.net 25 > > 220 caduceus.wtfayla.net ESMTP Postfix (Debian/GNU) > > helo fongaboo.com > > 250 caduceus.wtfayla.net > > mail from: jcapra@.com > > 250 2.1.0 Ok > > rcpt to: nonexistentaddr...@fongaboo.com > > 250 2.1.5 Ok > > data > > 354 End data with . > > this should not exist > > . > > 250 2.0.0 Ok: queued as 32F272E41F6 > > Either "relay_recipient_maps" is not configured as you report, the > domain is not a relay_domain (perhaps it is also listed in > mydestination? ...) or your virtual(5) aliases or canonical(5) maps have > wildcard entries for that recipient domain. > > > # See /usr/share/postfix/main.cf.dist for a commented, more complete version > > > > # Debian specific: Specifying a file name will cause the first > > # line of that file to be used as the name. The Debian default > > # is /etc/mailname. > > #myorigin = /etc/mailname > > [...] > > Valiant effort, but the correct way to report your configuration is > to include the verbatim outputs (no changes in whitespace, ...) of > > $ postconf -nf > $ postconf -Mf > > See https://www.postfix.org/DEBUG_README.html#mail > > -- > Viktor. The parameter smtpd_relay_restrictions was set twice in main.cf. You should decide which one you want, and delete the other (or combine what you want into a single version). The postconf -nf command shown above would just output the one that Postfix ends up using, which might or might not be the one you think it is using. This might matter, but probably not. The second, more detailed one, will override the first one. But note that only the first (unused) one contains permit_sasl_authenticated, so SASL-authenticated connections will be subject to all the checks in the second smtpd_relay_restrictions. But I don't think this is causing your problem. cheers, raf
Re: Backup MX with MySQL backend
On Tue, Nov 29, 2022 at 03:44:02PM -0500, Jonathan Capra
wrote:
>
> On Tue, 29 Nov 2022, raf wrote:
>
> > On Sun, Nov 27, 2022 at 11:40:01PM -0500, Jonathan Capra
> > wrote:
> >
> > > smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> >
> > Not relevant, but the above line isn't needed (since Postfix 2.11).
>
> I commented this out.
>
>
> > > mydestination = $myhostname, ca2ceus.wtfayla.net, localhost
> >
> > Does the value of $myhostname refer to the primary MX host by any chance?
> > If so, the above line would cause the secondary MX host to deliver locally.
> > But that's probably not it (if all occurrences of refer to the
> > same hostname). The certificate there is for the host name
> > ca2ceus.wtfayla.net (presumably, the secondary MX's public hostname).
>
> Just looks like I forgot to s/ca2ceus.wtfayla.net//g for
> one instant. Now that the cat is out of the bag, caduceus.wtfayla.net is
> $myhostname, and ca2ceus.wtfayla.net is just a CNAME to the former.
There goes that theory. Sorry, I'm out of ideas.
> > > relayhost = #mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> >
> > The line above looks wrong. Comments only start at the
> > start of a line (after spaces/tabs is ok). If this is
> > the cause of the problem (i.e., postfix trying to relay
> > to an incorrect hostname), there would probably be log
> > messages to indicate that. But that's probably not it
> > either. Postfix wouldn't deliver locally if it thought
> > it was supposed to relay but failed.
>
> Turns out it's just a case of carriage returns somehow getting lost when
> pasting into the email. It really looks like this:
>
> relayhost =
> #mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> #mynetworks = 127.0.0.0/8, 174.138.48.1/20
>
>
> But that means that relayhost is empty. Should it be set to $mynetworks?
No. It should be empty for an MX host. relayhost is mostly
used for home systems that send all outgoing email via
an ISP's SMTP server because they can't or don't want to
allow arbitrary outgoing connections to port 25.
> > > transport_maps = # hash:/etc/postfix/transport_maps,
> > > mysql:/etc/postfix/mysql_relay_transports.cf
> >
> > The apparent comment above is also wrong. Move it to a line
> > of its own. Perhaps that's relevant if transports are used
> > to relay to the primary MX host.
>
> Same deal with the email formatting. It really looks like this:
>
> transport_maps =
> # hash:/etc/postfix/transport_maps,
> mysql:/etc/postfix/mysql_relay_transports.cf
>
>
> > I hope that helps a bit. But it might not be enough to
> > solve the problem.
> >
> > cheers,
> > raf
> >
> >
Re: Backup MX with MySQL backend
tls_loglevel = 1 > smtpd_tls_received_header = yes > smtpd_sasl_type = dovecot > smtpd_sasl_path = private/auth > smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous > broken_sasl_auth_clients = yes > smtpd_sasl_auth_enable = yes > smtpd_recipient_restrictions = > permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination > > # relay_recipient_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf > > transport_maps = # hash:/etc/postfix/transport_maps, > mysql:/etc/postfix/mysql_relay_transports.cf The apparent comment above is also wrong. Move it to a line of its own. Perhaps that's relevant if transports are used to relay to the primary MX host. > relay_domains = mysql:/etc/postfix/mysql_relay_domain_maps.cf, > mysql:/etc/postfix/mysql_relay_alias_domain_maps.cf > relay_recipient_maps = >mysql:/etc/postfix/mysql_alias_maps.cf, >mysql:/etc/postfix/mysql_alias_domain_maps.cf, >mysql:/etc/postfix/mysql_alias_domain_catchall_maps.cf > > # Increase attachment size to 50 MB > message_size_limit = 52428800 I hope that helps a bit. But it might not be enough to solve the problem. cheers, raf
Re: secondary MX and SPF
On Sun, Nov 20, 2022 at 12:04:34PM +0100, Benny Pedersen wrote: > linux...@gmx.net skrev den 2022-11-20 09:49: > > > when secondary MX server forwards messages to primary MX, how can I > > setup SPF policy to make them not breaking SPF? > > "v=spf1 mx -all" :) > > all other variants is just more verbose I think it's more polite to use actual IP addresses so as to eliminate a DNS lookup. They take time, and there is a limit to the number of DNS lookups that an SPF checker will perform. Also, if you need to include: another domain's SPF record, that might incur more DNS lookups beyond your control, so the fewer you impose, the better. So, yes, it's more verbose, but it's also more efficient. Also, using "mx" isn't great if you have more than one MX host, and only the primary one sends mail. It's probably harmless, though, as long as you control all the MX hosts. cheers, raf
Re: local(8) and blocking delivery to system users?
On Sun, Nov 20, 2022 at 08:42:41PM +0100, Jaroslaw Rafa wrote: > Dnia 20.11.2022 o godz. 14:12:30 Viktor Dukhovni pisze: > > > If Postfix tries to create Maildirs in actual home directories specified > > > in > > > /etc/passwd, > > > > When you configure it to do so. The default setting is: > > > > $ postconf -d home_mailbox > > home_mailbox = > > I *want* to have mail stored in ~/Maildir (but only for actual human users > of course, not for system ones). Can I achieve that without setting > home_mailbox ? > > > Best practice is to not use home_mailbox, and store all mail in a common > > tree owned by the IMAP service. And use local(8) only for mailing lists > > and owned aliases, not mailbox delivery, which happens via LMTP, > > virtual(8) or a mailstore-specific LDA. > > IMAP is used marginally on my server. The primary method of accessing mail > is by old fashioned ssh'ing to the server and running a local mail client > that accesses directly the messages stored in Maildir (like mutt). Only when > mail can't be properly accessed this way (eg. it is HTML formatted or > contains attachments), I resort to IMAP client on my PC. > > Therefore I want to use local(8), as I understand it's best suited for this > "old fashioned" style of using mail, ie. real Unix users logging in to their > accounts and running a local mail client. It is simple and I don't have to > care about any delivery agent configuration details. > > Can I achieve the same using LMTP or virtual(8) without too much effort on > configuration? > -- > Regards, >Jaroslaw Rafa >r...@rafa.eu.org > -- > "In a million years, when kids go to school, they're gonna know: once there > was a Hushpuppy, and she lived with her daddy in the Bathtub." I ssh to a vm and read locally with mutt (local delivery, mbox format), and if I want to see the pretty pictures, I bounce it (a mutt action) to a separate IMAP account on the same vm (virtual delivery), and Thunderbird on my laptop connects to that account. That seemed to me to be the easiest way to view the occasional email in Thunderbird. Having said that, I think that dovecot can be configured to handle mail in home directories, but I haven't done that. The separate IMAP account sits alongside others in a dedicated dovecot directory. There's a commented out line in /etc/dovecot/conf.d/10-mail.conf that looks hopeful: mail_location = mbox:~/mail:INBOX=/var/mail/%u That parameter also accepts "maildir:" as a prefix instead of "mbox:". Anyway, just an idea to consider. cheers, raf
Re: How do check DKIM and SPF on incoming email?
On Mon, Nov 21, 2022 at 10:18:38PM +, Scott Kitterman wrote: > On November 21, 2022 8:50:51 PM UTC, raf wrote: > >On Mon, Nov 21, 2022 at 12:48:49AM +, Scott Kitterman > > wrote: > > > >> On November 20, 2022 11:47:02 PM UTC, raf wrote: > >> > > >> >There are also Debian packages for policy server versions: > >> > > >> > postfix-policyd-spf-perl > >> > postfix-policyd-spf-python > >> > >> The Perl implementation is very rudimentary. Unless one is completely > >> allergic to Python for some reason, I definitely recommend the Python > >> one. > >> > >> The backend logic/code in pyspf-milter is shared with the policy > >> server. For Postfix, I don't think it matters much if you use the > >> milter or the policy server. > >> > >> Scott K > > > >Thanks for the tip. If I remember correctly, I tried both > >and preferred the headers created by the perl version. > >They were more detailed and informative. > > > >In what way is the python version better? > > It's much more configurable, so covers more use cases. If the Perl one does > what you need, then there's nothing wrong with it. > > Here's a link to the section 5 man page that shows configuration options to > give you an idea of the details: > > https://git.launchpad.net/spf-engine/tree/policyd-spf.conf.5 > > Scott K Thanks for that. cheers, raf
Re: How do check DKIM and SPF on incoming email?
On Mon, Nov 21, 2022 at 12:48:49AM +, Scott Kitterman wrote: > On November 20, 2022 11:47:02 PM UTC, raf wrote: > > > >There are also Debian packages for policy server versions: > > > > postfix-policyd-spf-perl > > postfix-policyd-spf-python > > The Perl implementation is very rudimentary. Unless one is completely > allergic to Python for some reason, I definitely recommend the Python > one. > > The backend logic/code in pyspf-milter is shared with the policy > server. For Postfix, I don't think it matters much if you use the > milter or the policy server. > > Scott K Thanks for the tip. If I remember correctly, I tried both and preferred the headers created by the perl version. They were more detailed and informative. In what way is the python version better? cheers, raf
Re: How do check DKIM and SPF on incoming email?
On Sun, Nov 20, 2022 at 03:29:33PM +0100, Matus UHLAR - fantomas wrote: > > On 16/11/2022 11:45, Matus UHLAR - fantomas wrote: > > > I use: > > > spf-milter (the same source as policyd-spf-python) > > > opendkim > > > openarc > > > opendmarc > > > > > > so far in soft mode (no rejections) > > > > > > opendmarc can use results of previous three in its decisions. > > On 20.11.22 08:21, Dominic Raferd wrote: > > Does spf-milter have the same source as policyd-spf-python? It looks to > > me like a completely separate project, based on viaspf (both written in > > Rust). Or did you mean spf-milter-python (Debian package)? > > Sorry, you are correct. > > There was no other spf milter available in debian when I checked. > > Package: pyspf-milter > Source: spf-engine > > Package: postfix-policyd-spf-python > Source: spf-engine There are also Debian packages for policy server versions: postfix-policyd-spf-perl postfix-policyd-spf-python cheers, raf
Re: How do check DKIM and SPF on incoming email?
On Wed, Nov 16, 2022 at 08:39:48AM +, supp...@openmbox.net wrote:
> Sorry for inception.
> How can I configure postfix to cause an instant message returned,
> rather than 4xx code to make peer MTA retry many times?
>
> Thanks
I think it's OpenDMARC that needs to be configured to cause this
to happen.
In /etc/opendmarc.conf, you can change the default:
RejectFailures false
to:
RejectFailures true
But if you don't, I don't think there's any 4xx code,
it just adds the Authentication-Results header.
That config file says that temporary failures happen
when the evaluation could not be performed, not when
the evaluation fails.
/etc/opendmarc.conf:
## RejectFailures { true | false }
## default "false"
##
## If set, messages will be rejected if they fail the DMARC evaluation, or
## temp-failed if evaluation could not be completed. By default, no message
## will be rejected or temp-failed regardless of the outcome of the DMARC
## evaluation of the message. Instead, an Authentication-Results header
## field will be added.
cheers,
raf
Re: How do check DKIM and SPF on incoming email?
On Mon, Nov 14, 2022 at 12:33:02PM -0700, Bryan Arenal wrote: > Hi there, > > Is Postfix capable of checking DKIM and SPF records on incoming email > and adding headers based upon its findings? For example, an email > with a valid DKIM signature shows these headers sent to O365: > > ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass > smtp.mailfrom=example.com; dmarc=pass action=none header.from=example.com; > dkim=pass header.d=example.com; arc=none > > My google searches have only returned results on how to do DKIM > signing on outbound email and not how to verify them on inbound > emails. > > Thanks! That "ARC-Authentication-Results" header is actually ARC, not DKIM/SPF (i.e. a meta-DMARC for forwarders that modify what is being forwarded). I don't know what can create those headers. OpenARC seems defunct. I think OpenDMARC checks ARC headers (as well as DMARC/DKIM/SPF) and adds "Authentication-Results" headers. rspamd probably does it as well. There's a tutorial on adding OpenDMARC to postfix on Debian here: https://www.linuxbabe.com/mail-server/opendmarc-postfix-debian It's for debian but there might be equivalent tutorials for other Linux systems on that website. It might assume other steps in the complete tutorial: https://www.linuxbabe.com/mail-server/build-email-server-from-scratch-debian-postfix-smtp But maybe not. People say good things about rspamd as well. Check that out. cheers, raf
Re: Postfix is Rewriting the email from address with the serveraddress when server from is foreign
On Sat, Nov 12, 2022 at 11:53:06AM -0500, Paul Kudla wrote: > Ok I am popping email from an external server (aol etc) > > i get the proper email from address in the header's and resend all works ok > if i am popping local email > > ie t...@scom.ca --> p...@scom.ca postfix lets it go as is > > when i get an external email with x...@aol.com (for example) > > postfix replaces the from address in the header with scom...@mail18.scom.ca > > I understand why but it messes up the customer when replying ??? > > Simply put how do i preserve the headers when popping from a foreign server > > if there is a way to do this locally great as i would rather leave the > security feature in tact > > i am running this through a python email program and sending via the > sendmail library ^^^ > i am running multiple servers so i can program an inside one to bypass this > if nessesary > > otherwise how do i just turn off the 'from' address getting mangled? > > thanks It sounds like it might be the "sendmail library" (presumably a python library) that is setting the From: address. You could investigate that. For example, when submitting via the "/usr/sbin/sendmail" binary, there is a -f option that lets you override the sender (if your login account is allowed to do so (at least I think that used to be the case, not sure anymore)). Perhaps there's something that needs to be done differently with the sendmail library as well, to achieve the same effect. Are you parsing the email to extract the sender address and passing it as an argument to whatever sendmail library function does the sending? Or are you letting it work out the sender address for itself? If it's the latter, perhaps it's just using the address of the user account that is running the process. Note that I'm not familiar with python's sendmail library (I've only used smtplib), so this might be a red herring, but its webpage says it has an smtplib-compatible API, but that it invokes the sendmail binary. Apologies if this is irrelevant/unhelpful. cheers, raf
Re: LDAP mail for external users
On Fri, Oct 28, 2022 at 08:51:28AM -0400, Wietse Venema wrote: > Tan Mientras: > > eureka! > > thank you Wietse, it was an issue with the alias table. Now seems its > > working. i'm going to test further... > > This will work fine with email between colleagues, but as Viktor > noted may run into SPF/DMARC etc. issues when forwarding mail from > a sender address outside your domain to a recipient address outside > your domain. In my experience, it still appears to work for email > that has a valid DKIM signature. Otherwise, there is at this time > no 'simple' fix. > > Wietse "postsrsd" can be used to apply the Sender Rewriting Scheme (SRS) to all email. If that feels like overkill, "postforward" can be used as well, to apply SRS selectively for specific recipient adresses. But that's probably only helpful if the list of recipient addresses is fairly static (or if you can automate change propagation to postfinger's configuration). https://github.com/roehling/postsrsd https://github.com/zoni/postforward Debian has a package for postsrsd, but not for postforward. cheers, raf
Re: ot: SPF/DKIM woes
On Sat, Sep 17, 2022 at 01:46:10PM +0200, Benny Pedersen wrote: > li...@sbt.net.au skrev den 2022-09-17 09:12: > > I have mail server on geko.sbt.net.au serving sbt.net.au as well as > > several other TLD domains, > > https://dmarcian.com/spf-survey/?domain=geko.sbt.net.au > > there is no spf there, dmarc will not pass on missing subdomains, spf will > be none The logfile message showed that the envelope sender domain was sbt.net.au, not geko.sbt.net.au. That is just the name of the server sending the email. So there is no reason to expect an SPF record for it. The expectation is that the SPF record for sbt.net.au contain the IP address of geko.sbt.net.au, which it does. > avoid unneed google includes in spf Maybe that's needed when sending emails from gmail. Either way, it shouldn't have any bearing on the problem. Unless I'm missing something. cheers, raf
Re: ot: SPF/DKIM woes
On Sat, Sep 17, 2022 at 11:54:57AM +0200, Matus UHLAR - fantomas wrote: > On 17.09.22 17:12, li...@sbt.net.au wrote: > > I have mail server on geko.sbt.net.au serving sbt.net.au as well as > > several other TLD domains, > > a while back using help from this list, some write ups and mxtoolbox as > > means of verifying/testing I've set SPF/DKIM/DMARC (or so I thought...) > > > > as it seemed to pass all test I was able to run, I assumed it was set up > > correctly, just now, noticed I get rejected from my own gmail address with > > SPF/DKIM (1) (it was working OK in the past) > > > > checking with mxtoolbox: > > > > I get NO SPF for geko.sbt.net.au, I do get SPF for sbt.net.au > > do I need SPF record for both mail host as well as domain ? > > you only need SPF for geko.sbt.net.au if you want to stop other servers for > impoersonating geko.sbt.net.au (sending it in EHLO/HELO), or if you send > mail from geko.sbt.net.au. > > > what else am I missing or stuffed up ? > > > (1) > > Sep 16 13:04:55 geko postfix/smtp[2651]: BC9EB200534: to=, > > relay=gmail-smtp-in.l.google.com[172.217.194.26]:25, delay=11, > > delays=0.01/0.04/2/8.8, dsn=5.7.26, status=bounced (host > > gmail-smtp-in.l.google.com[172.217.194.26] said: 550-5.7.26 This message > > does not pass authentication checks (SPF and DKIM both 550-5.7.26 do not > > pass). SPF check for [sbt.net.au] does not pass with ip: 550-5.7.26 > > [103.106.168.106].To best protect our users from spam, the message > > 550-5.7.26 has been blocked. Please visit 550-5.7.26 > > https://support.google.com/mail/answer/81126#authentication for more 550 > > 5.7.26 information. p2-20020a170902e74200b00176a0d8780csi2398305plf.285 - > > gsmtp (in reply to end of DATA command)) > > your domain is registered to ns1.netregistry.net. nameservers: > > Name Server: NS1.NETREGISTRY.NET > Name Server: NS2.NETREGISTRY.NET > Name Server: NS3.NETREGISTRY.NET > > however, NS records say otherwise: > > sbt.net.au. 3600IN NS ns1.yourdnshost.net. > sbt.net.au. 3600IN NS ns2.yourdnshost.net. > sbt.net.au. 3600IN NS ns3.yourdnshost.net. > > these servers have the same IP addresses, but such discrepancy can cause you > troubles. > > currently 8.8.8.8 (and 1.1.1.1) fail to return response for your domain: > > % dig mx sbt.net.au @8.8.8.8 > > ; <<>> DiG 9.16.27-Debian <<>> mx sbt.net.au @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21196 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > also, your nameservers fail to return answer for type ANY: > > % dig any geko.sbt.net.au @ns1.yourdnshost.net. > ;; Connection to 203.209.194.250#53(203.209.194.250) for geko.sbt.net.au > failed: timed out. > ;; Connection to 203.209.194.250#53(203.209.194.250) for geko.sbt.net.au > failed: timed out. > > this may and may not cause with google DNS issues. > however, it indicates something broken with your DNS. > google is apparently one of those having problems. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > I drive way too fast to worry about cholesterol. That's wierd. I can see lots of DNS records for sbt.net.au: > host sbt.net.au sbt.net.au has address 103.106.168.106 sbt.net.au mail is handled by 10 geko.sbt.net.au. > host -t txt sbt.net.au sbt.net.au descriptive text "v=spf1 ip4:103.106.168.106 ip4:103.106.168.105 ip4:125.168.124.3 include:_spf.google.com ~all" > host -t any sbt.net.au sbt.net.au mail is handled by 10 geko.sbt.net.au. sbt.net.au has address 103.106.168.106 sbt.net.au descriptive text "v=spf1 ip4:103.106.168.106 ip4:103.106.168.105 ip4:125.168.124.3 include:_spf.google.com ~all" cheers, raf
Re: ot: SPF/DKIM woes
On Sat, Sep 17, 2022 at 05:12:40PM +1000, li...@sbt.net.au wrote: > I have mail server on geko.sbt.net.au serving sbt.net.au as well as > several other TLD domains, > a while back using help from this list, some write ups and mxtoolbox as > means of verifying/testing I've set SPF/DKIM/DMARC (or so I thought...) > > as it seemed to pass all test I was able to run, I assumed it was set up > correctly, just now, noticed I get rejected from my own gmail address with > SPF/DKIM (1) (it was working OK in the past) > > checking with mxtoolbox: > > I get NO SPF for geko.sbt.net.au, I do get SPF for sbt.net.au > > what tools/website should I use to test/verify SPF/DKIM/DMARC ? > do I need SPF record for both mail host as well as domain ? > what else am I missing or stuffed up ? > > thanks for any pointers, hope I'm not too far off topic > > Voytek > > > (1) > Sep 16 13:04:55 geko postfix/smtp[2651]: BC9EB200534: to=, > relay=gmail-smtp-in.l.google.com[172.217.194.26]:25, delay=11, > delays=0.01/0.04/2/8.8, dsn=5.7.26, status=bounced (host > gmail-smtp-in.l.google.com[172.217.194.26] said: 550-5.7.26 This message > does not pass authentication checks (SPF and DKIM both 550-5.7.26 do not > pass). SPF check for [sbt.net.au] does not pass with ip: 550-5.7.26 > [103.106.168.106].To best protect our users from spam, the message > 550-5.7.26 has been blocked. Please visit 550-5.7.26 > https://support.google.com/mail/answer/81126#authentication for more 550 > 5.7.26 information. p2-20020a170902e74200b00176a0d8780csi2398305plf.285 - > gsmtp (in reply to end of DATA command)) I can't see what's wrong. The IP address of the sending mail server is 103.106.168.106 which is listed in the SPF record for sbt.net.au. "v=spf1 ip4:103.106.168.106 ip4:103.106.168.105 ip4:125.168.124.3 include:_spf.google.com ~all" So unless you added ip4:103.106.168.106 to the SPF record after the bounce, I can't see what's wrong. Maybe someone else will. The sending server doesn't require its own SPF record. That's just for the domain used in the envelope address (sbt.net.au). There are lots of mail testing sites, e.g.: https://mail-tester.com https://mailtester.com https://www.mailgenius.com https://www.mailreach.co/mail-tester-alternative I've only used the first one. cheers, raf
Re: Fwd: Re: Postfix 3.5 and outbound TLS/SSL
On Tue, Aug 23, 2022 at 09:21:33AM -0700, nate wrote: > On 2022-08-22 14:46, Viktor Dukhovni wrote: > > [..] > > > You don't need to sign your own domain in order to secure outbound > > traffic > > to domains that others have signed. You just need a local validating > > resolver such as "unbound", with DNSSEC validation turned on. > > Ok, yeah I was thinking more of DANE for my own domains rather than > validating others. > > > My take is that the person in question likes being a cult leader, > > dispensing wisdom to adherents, who then, along with the leader, get to > > feel superior to the uninitiated masses. > > Interesting! I have no idea who that person is just came across that > post in a comment on a website somewhere years ago, I had read others > complain about DNSSEC but hadn't seen what appeared to be as fairly > organized specific thoughts on the subject rather than a one liner > that they hate DNSSEC without saying why. > > > The tooling around DNSSEC has significantly improved recently, making > > hands-off auto-pilot operation much simpler in e.g. BIND 9.16 and later. > > Or you can get your domain professionally operated by Google, one.com, > > OVH, ... who operate millions of signed domains with no issues. > > I checked and I do have BIND 9.16 where I host my domains(on my own > servers). I'll think about it more, my home setup is quite simple I > haven't invested much time in it since before 2010 probably(other > than OS updates and stuff to keep it going). > > I have been using Dyn DNS for work related DNS stuff since about 2009, > even though Oracle keeps saying they plan to retire the legacy Dyn > stuff(and say the newer Oracle cloud DNS uses the same Dyn backend), > it's still alive until May 2023 at least. > > > In any case, outbound DANE does not require anything non-trivial on your > > end. > > Good to know, thanks!! > > nate DNSSEC has become really easy since BIND 9.16. The only big investment in time is reading about DNSSEC to make sure that you understand what's happening. The BIND documentation for DNSSEC is good, and once you understand what it's doing, it can be done with a single extra line of configuration (unless you want to get fancy with the policy), and communicating records for the parent zone to your registrar. I started with it a year ago and have just had my first batch of new CDS/CDNSKEY records appear for an annual rollover (my choice). There's no risk of an outage because BIND won't do anything drastic until I've told it that the new DS record is published and the old DS record is withdrawn. I had to set up some monitoring to know when the new CDS/CDNSKEY records appear, but that's just cron+host+diff. An important thing to check first is how good your registrar is when it comes to adding and removing DS and/or DNSKEY records. Before DNSSEC, I was with a registrar that couldn't do it at all, so I switched to a much better one. Uploading them is done with a web form. No API unfortunately, but I've just asked if they're willing to add one. That anti-DNSSEC page seems very silly and/or out of date. It's true that there are security measures that have been developed with the assumption/acceptance that DNS is insecure, but they have their own problems, and there's probably a lot of stuff that just accepts the insecurity rather than doing anything to mitigate it, so that's not very compelling. And modern small keys exist now. And its popularity is steadily increasing. And the claim that the government controls your keys is just wierd. I don't understand that claim at all. Maybe the author doesn't know what escrow means. cheers, raf
Re: opendkim - permission issue?
On Mon, Jun 27, 2022 at 07:19:59AM +0200, Maurizio Caloro wrote: > On 27.06.2022 00:24, Wietse Venema wrote: > > Maurizio Caloro: > > > > setup also opendkim and will appear now the error " > > > *key data is not secure: / is writeable and owned by uid 110 which > > > is not the executing uid (115)* *or the superuser*" > > > it's seem that i have permission issue? > > Look at the output from: > > > > ls -ld / > > > > Wietse > > thanks but stil the same > > # ls -ld > drwx-- 2 opendkim opendkim 4096 Jun 27 06:59 . You left the / off the end of the command, so it only applied to the current directory, not to the / directory. Try: ls -ld / Is / really owned by the user bind as indicated by the opendkim error message? If so, chown it back to root, and see if anything else has been incorrectly chowned by mistake. I'm probably being ridiculous (sorry) but the error message looks like it's saying that / is writable and owned by the user bind. That's very unlikely, but if it were true, it would be worth an error message. cheers, raf
Re: opendkim - permission issue?
On Mon, Jun 27, 2022 at 12:00:20AM +0200, Maurizio Caloro wrote: > > setup also opendkim and will appear now the error "key data is not secure: / > is writeable and owned by uid 110 which is not the executing uid (115)" > it's seem that i have permission issue? > > # opendkim -V > opendkim: OpenDKIM Filter v2.11.0 > Compiled with OpenSSL 1.1.1n 15 Mar 2022 > > systemctl > nmail opendkim: nmail._domainkey.caloro.ch: key data is not secure: / is > writeable and owned by uid 110 which is not the executing uid (115) or the > superuser > nmail opendkim: CC0E640: not authenticated > nmail opendkim: CC0E640: DKIM verification successful > nmail opendkim: CC0E640: s=nmail d=caloro.ch SSL > nmail opendkim: nmail._domainkey.caloro.ch: key data is not secure: / is > writeable and owned by uid 110 which is not the executing uid (115) or the > superuser > nmail opendkim: 09D30: DKIM-Signature field added (s=nmail, d=caloro.ch) > > iam also reading that this "opendkim-testkey: key not secure" would mean > that DNSSEC > # opendkim-testkey -d caloro.ch -s nmail - > opendkim-testkey: using default configfile /etc/opendkim.conf > opendkim-testkey: key loaded from /etc/opendkim/key/dkim.key > opendkim-testkey: checking key 'nmail._domainkey.caloro.ch' > opendkim-testkey: key not secure > opendkim-testkey: PEM_read_bio_PrivateKey() failed error:0909006C:PEM > routines:get_name:no start line > > cat /etc/passwd /etc/group | grep 115 110 > postfix:x:115: > postfix:x:109:115::/var/spool/postfix:/bin/false > opendkim:x:115:121::/var/run/opendkim:/bin/false > messagebus:x:110: > messagebus:x:105:110::/var/run/dbus:/bin/false > bind:x:110:117::/var/cache/bind:/bin/false The above command/output is confusing. "grep 115 110" isn't right. I think you meant: egrep -w '110|115' /etc/passwd /etc/group # but /etc/group is not relevant Anyway, it looks like uid 110 is the user bind and uid 115 is the user opendkim. The error message seems to be referring to the directory / as having the wrong ownership. / would not be owned by the user bind. Is it referring to a chroot'ed directory? Or am I misinterpreting the what the error message is saying? Is there an opendkim forum where you could ask about opendkim's error messages? It seems unlikely that anything owned by the user bind would be involved. Unless somehow a "chown bind /" command has been executed by mistake. > File and owner Security also are correct > > /etc/bind# ls -la /etc/opendkim/key/ > -rw--- 1 opendkim opendkim 51 Jun 26 22:50 dkim.key > -rw--- 1 opendkim opendkim 1675 Jun 26 22:50 nmail.private > -rw--- 1 opendkim opendkim 506 Jun 26 22:50 nmail.txt > > thanks for any help > regards cheers, raf
Re: parameter append syntax (was: milter_header_checks, pcre, chroot)
On Sun, Jun 26, 2022 at 07:45:47AM -0400, Wietse Venema wrote: > raf: > > Also, is .= the best notation? Would += be better? > > https://marc.info/?l=postfix-users&m=164779562215790&w=2 > > Wietse Of course. cheers, raf
Re: parameter append syntax (was: milter_header_checks, pcre, chroot)
On Sat, Jun 25, 2022 at 09:08:30PM -0400, Wietse Venema
wrote:
> raf:
> > If .= can reliably distinguish between being applied to
> > a list or scalar parameter, maybe it could automatically
> > include a leading space when adding to lists.
>
> Unfortunately, the main.cf parser does not know if a parameter value
> is used as a list such as
>
> export_environment = TZ MAIL_CONFIG LANG
> export_environment .= NAME=value
>
> with intended result:
>
> export_environment = TZ MAIL_CONFIG LANG NAME=value
>
> and when a parameter is not:
>
> syslogname = ${multi_instance_name?{$multi_instance_name}:{postfix}}
> syslogname .= /$service_name
>
> with intended result:
>
> syslogname = ${multi_instance_name?{$multi_instance_name}:{postfix}}/blah
>
> Even if the main.cf parser wree made list aware, the value from one
> parameter can be substuted into another parameter value, i.e. list
> and non-list parameter values can be combined. It's better not to
> try to make the main.cf parser smart about list and non-list contexts.
>
> Wietse
I thought that might be the case. I also thought of a
,= alternative but as Viktor says, string append isn't
useful enough, and you'd want there to be a good case
for adding both operations.
Also, is .= the best notation? Would += be better? I
just ask because . and .= are Perl operators for string
concatenation/appending (so it makes perfect sense to
those who are lucky enough to know Perl), but + and +=
might be more natural for those who only know other
programming languages.
cheers,
raf
Re: parameter append syntax (was: milter_header_checks, pcre, chroot)
On Sat, Jun 25, 2022 at 11:07:20AM -0400, Wietse Venema
wrote:
> Wietse:
> >I'm looking into adding "name .= value" support but this is tricky
> >because it has to work not only in main.cf but also in master.cf
> >(-o name.=value).
>
> That idea originated in the context op adding an 'extra' to the
> default value of export_environment, or addind map that I forgot
> to include in the proxy_read_maps default value.
>
> For example,
>
> export_environment .= { NAME = value }
>
> would result in
>
> export_environment = TZ MAIL_CONFIG { LANG NAME=value }
>
> But that won't work if we also want the following to work.
>
> Matus UHLAR - fantomas:
> > submission inet n - y - - smtpd
> >-o syslog_name.=/submission
> > relay unix - - y - - smtp
> >-o syslog_name.=/$service_name
>
> If we support that, the export_environment result will look like
>
> export_environment = TZ MAIL_CONFIG LANGNAME=value
>
> which is not what we want.
>
> It can be fixed by requiring a comma when appending to a list:
>
> export_environment .= , { NAME = value }
>
> would result in
>
> export_environment = TZ MAIL_CONFIG LANG, { NAME = value }
>
> This is more explicit, and a little less user friendly.
>
> Wietse
If .= can reliably distinguish between being applied to
a list or scalar parameter, maybe it could automatically
include a leading space when adding to lists.
cheers,
raf
Re: Postfix - Mysql - howto MultipleDomain?
On Fri, Jun 17, 2022 at 01:20:05PM -0400, Viktor Dukhovni wrote: > On Fri, Jun 17, 2022 at 04:03:52PM +1000, raf wrote: > > > > Out: 454 4.7.0 TLS not available due to local problem > > > > Try deleting the middle two files (nmail.calm-ness.ch), > > or swapping them around. They are in the wrong order. > > Swapping them won't have the desired effect. There can be at most one > RSA keypair (private key + cert) per SSL context. IIRC attempting to > load a second pair will raise an error, but even if not, "at best" the > mistake won't be detected and these will replace the first pair. > > -- > Viktor. Ah, of course. I forgot that bit. Thanks. So removing the middle files from smtpd_tls_chain_files is the only correct approach. Even if the middle pair were in the right order, and even if they successfully replaced the first pair (which might not be a thing anyway), it would still end up with a single RSA certificate, not both. cheers, raf
Re: TLS issue with purchase order emails from ariba.com system.
On Wed, Jun 15, 2022 at 11:09:10PM +0530, P V Anthony wrote: > Please note, I am still finding how to force renew with the letsencrypt > certs with the new renewal settings. Something like the following should do it (after making the renewal config changes that Viktor mentioned (or including them in the command)): certbot renew --force-renewal --cert-name XXX Also note that there is a very useful forum for help with letsencrypt and certbot: https://community.letsencrypt.org/ cheers, raf
Re: Postfix - Mysql - howto MultipleDomain?
On Thu, Jun 16, 2022 at 11:07:05PM +0200, Maurizio Caloro wrote: > On 13.06.2022 12:05, Benny Pedersen wrote: > > postfixadmin is make it very more helpness, move both domains to > > virtual, and make mydestination only for system users, not possible to > > send direct to from outside of mynetworks > > > > https://www.howtoforge.com/how-to-set-up-a-mail-server-with-postfixadmin-on-debian-11/ > > > > > > it world work for older debian aswell, atleast not much need to be > > changed > > Hello and first let me thanks for your message > > Please i need little more input, now installed successfully this two noted > domains, > i can mail and runnig with this setup postix,dovecot,mysql, but after little > tls check > and test will be noted with cert problem on domain calm-ness, added now this > signed certificate to main.cf > > after sigend and add to smtp_tld_chain_files will recieve > the following error. > --> Out: 454 4.7.0 TLS not available due to local problem > > [snips from main.cf] > mydestination = localhost, localhost.$mydomain, nmail.caloro.ch, > nmail.calm-ness.ch > > smtpd_tls_chain_files = > /etc/letsencrypt/live/nmail.caloro.ch/privkey.pem, > /etc/letsencrypt/live/nmail.caloro.ch/fullchain.pem, > /etc/letsencrypt/live/nmail.calm-ness.ch/fullchain.pem, > /etc/letsencrypt/live/nmail.calm-ness.ch/privkey.pem, > /etc/letsencrypt/live/nmail.caloro.ch-ecdsa/privkey.pem, > /etc/letsencrypt/live/nmail.caloro.ch-ecdsa/fullchain.pem[] > [break] > > Transcript of session follows. > > Out: 220 nmail.caloro.ch ESMTP Postfix (Debian/GNU) > In: EHLO www11-do.CheckTLS.com > Out: 250-nmail.caloro.ch > Out: 250-PIPELINING > Out: 250-SIZE 25428800 > Out: 250-ETRN > Out: 250-STARTTLS > Out: 250-ENHANCEDSTATUSCODES > Out: 250-8BITMIME > Out: 250-DSN > Out: 250 CHUNKING > In: STARTTLS > Out: 454 4.7.0 TLS not available due to local problem > In: QUIT > Out: 221 2.0.0 Bye > > thanks Try deleting the middle two files (nmail.calm-ness.ch), or swapping them around. They are in the wrong order. cheers, raf
Re: Postfix - Mysql - howto MultipleDomain?
On Thu, Jun 16, 2022 at 07:50:40PM -0400, Viktor Dukhovni wrote: > On Thu, Jun 16, 2022 at 11:07:05PM +0200, Maurizio Caloro wrote: > > > --> Out: 454 4.7.0 TLS not available due to local problem > > As expected. > > > smtpd_tls_chain_files = > > /etc/letsencrypt/live/nmail.caloro.ch/privkey.pem, > > /etc/letsencrypt/live/nmail.caloro.ch/fullchain.pem, > > /etc/letsencrypt/live/nmail.calm-ness.ch/fullchain.pem, > > /etc/letsencrypt/live/nmail.calm-ness.ch/privkey.pem, > > /etc/letsencrypt/live/nmail.caloro.ch-ecdsa/privkey.pem, > > /etc/letsencrypt/live/nmail.caloro.ch-ecdsa/fullchain.pem[] > > This is wrong. Both domains likely use RSA public/private keys, and > you can only configure at most one default public key for each algorithm > (RSA, ECDSA, Ed25519, Ed448). Another point is that the middle pair of files are in the wrong order. The fullchain file needs to be after the privkey file, not before. See http://www.postfix.org/TLS_README.html (Configuring the server certificate and key files) But this doesn't matter if that pair of files are removed as recommended below. > Generally speaking just certificate chain is quite enough to serve both > domains. > > smtpd_tls_chain_files = > /etc/letsencrypt/live/nmail.caloro.ch/privkey.pem, > /etc/letsencrypt/live/nmail.caloro.ch/fullchain.pem, > > But if for some reason you feel expert enough to configure both RSA and > ECDSA and keep both working, then you set: > > smtpd_tls_chain_files = > /etc/letsencrypt/live/nmail.caloro.ch/privkey.pem, > /etc/letsencrypt/live/nmail.caloro.ch/fullchain.pem, > /etc/letsencrypt/live/nmail.caloro.ch-ecdsa/privkey.pem, > /etc/letsencrypt/live/nmail.caloro.ch-ecdsa/fullchain.pem > > Assuming the suggestive file names align with reality. > > -- > Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Fri, Jun 03, 2022 at 03:58:04PM +0200, Matus UHLAR - fantomas wrote: > > On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote: > > > this will unpack the tarball in local directory. > > > I use standard debian packages, there's SASL related patch but it doesn't > > > seem to affect this issue > > > > > > https://sources.debian.org/patches/postfix/3.5.6-1/ > > > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ > > On 03.06.22 09:27, Viktor Dukhovni wrote: > > The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds > > "/etc/postfix/sasl" to the SASL config search path. This creates two > > conflicting ways to set the location, with the patch likely overriding > > "cyrus_sasl_config_path", and not providing any mechanisms to choose > > alternative locations. > > I have tried with debian 11 and I can confirm this. > Changing cyrus_sasl_config_path did not help and > /etc/postfix/sasl/smtpd.conf was used. That's what I'm seeing too, now. The lesson for me here is not to perform experiments the day after general anaesthetic. :-) cheers, raf
Re: Block MX from recipients
On Thu, Jun 02, 2022 at 04:29:38PM -0300, Emanuel Gonzalez wrote: > The option is interesting, do you have an example? > > I tried to use it but it didn’t work for me. > > smtpd_recipient_restrictions = > check_recipient_mx_access cidr:/etc/postfix/recipient_mx_access.cidr > > 52.164.206.56 reject > > Regards, Not sure, but if there's no MX record, then there's no MX host to look up. Perhaps you want to use check_recipient_a_access instead for these? cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Wed, Jun 01, 2022 at 12:03:43AM -0400, Viktor Dukhovni wrote: > On Wed, Jun 01, 2022 at 01:35:56PM +1000, raf wrote: > > > > So what did they do? > > > > > > > $ postconf -d cyrus_sasl_config_path > > > > cyrus_sasl_config_path = > > > > $ postconf cyrus_sasl_config_path > > > > cyrus_sasl_config_path = > > > > $ dpkg-query -S /etc/postfix/sasl > > > > postfix: /etc/postfix/sasl > > > > > > What would make anything look there? > > > > That's a very good question. I have no idea. I searched for > > /etc/postfix/sasl in all files, not just the executable ones, and > > found nothing that explains it. And there are no symlinks to it, > > either. > > > > The Debian Postfix/SASL wiki page definitely indicates that that > > directory is where Postfix's SASL config files go: > > > > https://wiki.debian.org/PostfixAndSASL > > > > I experimented to see if /etc/postfix/sasl is really used, and it > > looks like it isn't. I think that my settings just happen to coincide > > with libsasl2's defaults. > > Now it all begins to make sense, the Debian docs are wrong, and the > search path is the default one (in no-way Postfix-specific) compiled > into Cyrus SASL. > > And if some distro wants a Postfix-specific location, they'd need to > mess around with symlinks or set "cyrus_sasl_config_path" by compiling > in a different default value, or arranging for an override in main.cf at > install time. > > So my suggested doc patch is pretty close, except perhaps that there > are no distros actually doing this??? In which case the doc tweak > can be somewhat different. > > -- > Viktor. That sounds about right. I suspect that Debian did some customization along these lines in the past (at least in Debian7) but they aren't doing it any more (Debian11). I've added instructions to set cyrus_sasl_config_path in that debian Postfix/SASL wiki page, and added a few SASL mechanisms that aren't completely insecure, but it's still not great. I might just add a note there to read Postfix's SASL_README. cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Wed, Jun 01, 2022 at 03:56:02PM +1200, Peter wrote: > On 30/05/22 2:48 pm, raf wrote: > > > If set > > > +empty (the default value) the search path is the one compiled into the > > > +Cyrus SASL library. > > > > I don't think that's entirely correct. On Debian, for > > example, the default value of cyrus_sasl_config_path is > > empty, and /etc/postfix/sasl is the directory that is > > used. They haven't changed the default value to be > > non-empty. > > It couldn't possibly be that they've compiled it into the cyrus sasl > library? > > > But it does look like it's not the postfix package that > > they changed. They changed the sasl2-bin package. > > The only executable binary that contains the string > > /etc/postfix/sasl is /usr/bin/saslfinger which is > > provided by the sasl2-bin package. > > Which suggests that it's been compiled into the cyrus sasl library. > > Peter No. Perhaps in the past, but no longer. I grepped for /etc/postfix/sasl in every file on a debian11 system and it didn't appear in libsasl2 or anywhere interesting. It did appear in things like saslfinger and apparmor rules and the postfix package file list and augeas-lenses (a config file parser). But nothing in any libsasl files or postfix files. cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Mon, May 30, 2022 at 12:15:19AM -0400, Viktor Dukhovni wrote: > On Mon, May 30, 2022 at 12:48:46PM +1000, raf wrote: > > > I don't think that's entirely correct. On Debian, for > > example, the default value of cyrus_sasl_config_path is > > empty, and /etc/postfix/sasl is the directory that is > > used. > > Well, how exactly does that happen? I don't see any patches to Postfix > that would make it so at first blush. Changes to Cyrus SASL to always > look in /etc/postfix even for non-Postfix applications are exceedingly > unlikely, so something in Postfix would have to call sasl_set_path(3), > and that code uses the "cyrus_sasl_config_path" parameter. > > > They haven't changed the default value to be non-empty. > > So what did they do? > > > $ postconf -d cyrus_sasl_config_path > > cyrus_sasl_config_path = > > $ postconf cyrus_sasl_config_path > > cyrus_sasl_config_path = > > $ dpkg-query -S /etc/postfix/sasl > > postfix: /etc/postfix/sasl > > What would make anything look there? > > -- > Viktor. That's a very good question. I have no idea. I searched for /etc/postfix/sasl in all files, not just the executable ones, and found nothing that explains it. And there are no symlinks to it, either. The Debian Postfix/SASL wiki page definitely indicates that that directory is where Postfix's SASL config files go: https://wiki.debian.org/PostfixAndSASL But that doesn't explain how it works. The wiki page doesn't give instructions to set cyrus_sasl_config_path. Debian does provide its own default main.cf file, but cyrus_sasl_config_path isn't set in there. I've asked the postfix package maintainer for an explanation. I'll let you know if he answers. I experimented to see if /etc/postfix/sasl is really used, and it looks like it isn't. I think that my settings just happen to coincide with libsasl2's defaults. I'm explicitly setting smtpd_sasl_type and smtpd_sasl_path to their default values in main.cf (cyrus and smtpd). And Postfix's SASL readme and Debian's postfix package's contents lead me to think that /etc/postfix/sasl was important, and it all worked, but I just noticed that the 250-AUTH response includes NTLM which isn't in the mech_list directive of the /etc/postfix/conf/smtpd.conf file. So I renamed /etc/postfix/sasl/smtpd.conf to something else, and restarted postfix, and it still worked. So that directory is irrelevant. If I rename the file back, and symlink /etc/sasl2 to /etc/postfix/sasl, then the NTLM disappears from the 250-AUTH response and matches the config file. So, even though the Postfix SASL readme suggests the possibility, and the Debian postfix package and the Debian Postfix SASL wiki page indicate otherwise, there is nothing on Debian that makes libsasl2 look at /etc/postfix/sasl. Also, the default smtpd.conf file (when none is found) must be the equivalent of: pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN I'll modify that wiki page to add an instruction to set cyrus_sasl_config_path. It is an old page (2015). Presumably, it used to be correct then. And saslfinger definitely still thinks that /etc/postfix/sasl is relevant. When I have /etc/postfix/sasl/smtpd.conf, saslfinger -s reports its contents happily (because it looks in /etc/postfix/sasl even when nothing else does), but when I rename it, saslfinger -s claims that SASL can't work because there is no smtpd config. Perhaps is was relevant in the past but something changed since 2015. Actually, that wiki page is dreadful in several other ways. Thanks for the question. cheers, raf
Re: AW: RSA and ECDSA - warning: No certs for key at index 1
On Tue, May 31, 2022 at 02:18:35PM +0200, Maurizio Caloro wrote: > Hello Viktor > Thanks for your Answer. the creation of this Cert are the following: > > The one key-type are for RSA and ECDSA > Acme.sh certonly --standalone --rsa-key-size 4096 --domain > nmail.caloro.ch --key-type rsa --cert-name nmail.caloro.ch-rsa > Acme.sh certonly --standalone --rsa-key-size 4096 --domain > nmail.caloro.ch --key-type ecdsa --cert-name nmail.caloro.ch-ecdsa I don't know much about Acme.sh, but it doesn't look right combining "--rsa-key-size 4096" and "--key-type ecdsa". cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Sun, May 29, 2022 at 11:25:44AM -0400, Viktor Dukhovni
wrote:
> On Sat, May 28, 2022 at 10:32:56PM -0400, Viktor Dukhovni wrote:
>
> > > This might be irrelevant, but the SASL readme mentions
> > > that on some systems Postfix is modified to look for
> > > the Cyrus SASL config in /etc/postfix/sasl or
> > > /var/lib/sasl2. On Debian, it's in /etc/postfix/sasl.
> > > Perhaps "ln -s /etc/sasl2 /etc/postfix/sasl" might
> > > help.
> >
> > I don't expect this is a "modification in Postfix" as such, beyond
> > perhaps tweaking the built-in default of:
> >
> > http://www.postfix.org/postconf.5.html#cyrus_sasl_config_path
> >
> > which determines the search path for the "smtpd.conf" file. The default
> > is to use the path compiled into Cyrus SASL, which would of course not
> > be /etc/postfix/sasl (the Cyrus library is not Postfix-specific).
>
> If the configuration directory turns out to be the issue, or in any
> case..., perhaps the below patch to SASL_README might help someone else
> in the future.
>
> --
> Viktor.
>
> --- proto/SASL_README.html
> +++ proto/SASL_README.html
> @@ -267,10 +267,18 @@ in /usr/lib/sasl2/.
>Cyrus SASL version 2.1.22 and newer additionally search
> in /etc/sasl2/.
>
> - Some Postfix distributions are modified and look for the
> -Cyrus SASL configuration file in /etc/postfix/sasl/,
> -/var/lib/sasl2/ etc. See the distribution-specific
> -documentation to determine the expected location.
> + With Postfix 2.5 and later you can explicitly configure the
> +search path via the cyrus_sasl_config_path configuration
> +parameter. Specify zero or more colon-separated directories. If set
> +empty (the default value) the search path is the one compiled into the
> +Cyrus SASL library.
> +
> + Some Postfix distributions employ a non-empty default value
> +for cyrus_sasl_config_path to look for the Cyrus SASL
> +configuration file in /etc/postfix/sasl/,
> +/var/lib/sasl2/ etc. See the output of postconf
> +cyrus_sasl_config_path and/or the distribution-specific
> +documentation to determine the expected location.
>
>
>
I don't think that's entirely correct. On Debian, for
example, the default value of cyrus_sasl_config_path is
empty, and /etc/postfix/sasl is the directory that is
used. They haven't changed the default value to be
non-empty.
$ uname -a
Linux ook 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64
GNU/Linux
$ dpkg-query -l | grep postfix
ii postfix 3.5.6-1+b1 amd64High-performance mail transport agent
...
$ postconf -d cyrus_sasl_config_path
cyrus_sasl_config_path =
$ postconf cyrus_sasl_config_path
cyrus_sasl_config_path =
$ dpkg-query -S /etc/postfix/sasl
postfix: /etc/postfix/sasl
But perhaps other systems do use a non-empty default.
But it does look like it's not the postfix package that
they changed. They changed the sasl2-bin package.
The only executable binary that contains the string
/etc/postfix/sasl is /usr/bin/saslfinger which is
provided by the sasl2-bin package.
$ find /usr -type f -perm /111 -exec grep -l /etc/postfix/sasl '{}' ';'
/usr/bin/saslfinger
$ dpkg-query -S /usr/bin/saslfinger
sasl2-bin: /usr/bin/saslfinger
cheers,
raf
Re: Postfix+SASL chrooted - out of ideas
On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote: > For completeness here's everything I can think of that could be > related: > > $ ls -ld /etc/sasl2 > drwxr-xr-x 2 root root 4096 May 19 00:58 /etc/sasl2 > > $ ls -l /etc/sasl2/ > -rw-r--r-- 1 root root 62 May 28 18:18 smtpd.conf > > $ cat /etc/sasl2/smtpd.conf > pwcheck_method: saslauthd > log_level: 7 > mech_list: PLAIN LOGIN This might be irrelevant, but the SASL readme mentions that on some systems Postfix is modified to look for the Cyrus SASL config in /etc/postfix/sasl or /var/lib/sasl2. On Debian, it's in /etc/postfix/sasl. Perhaps "ln -s /etc/sasl2 /etc/postfix/sasl" might help. cheers, raf
Re: Postfix+SASL chrooted - out of ideas
On Fri, May 27, 2022 at 06:22:01PM -0700, Jim Garrison wrote: > I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos > 6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working > EXCEPT SASL authentication, and the amount of conflicting information > on Postfix+SASL on the web is rather amazing :-). I've recently done a similar thing, replacing an 11 year old mail server for someone, and encountered a similar-sounding problem. The passwords are in /etc/sasldb2, but that file isn't accessible by chrooted postfix processes. I moved it to /var/spool/postfix/etc/sasldb2 and created a symlink to it at /etc/sasldb2. That might be the cause, but bear in mind Viktor's comments about the lack of security in having unhashed passwords on disk. > -- > Jim Garrison > j...@acm.org cheers, raf
Re: Milter_Readme - Documentation Edit Request - "order", "reject" and "override" - multiple message modifications?
On Wed, May 25, 2022 at 12:56:18PM -0600, James Feeney wrote: > On 5/24/22 08:24, Viktor Dukhovni wrote: > > > Milters learn about the role of the requesting MTA via a macro. Thus > > in the stock master.cf for the submission-related ports: > > > > -o milter_macro_daemon_name=ORIGINATING > > Ah! Interesting. Thanks. > > Yet note that this term "ORIGINATING" is nowhere to be seen in the Postfix > "Milter Readme" - let alone explained. I think that's because the milter protocol wasn't created for postfix. It was created for sendmail. So postfix doesn't document that protocol. It just adopted it. Documenting it is sendmail's job. But it would be good to have a reference to its documentation added to the milter readme. I once went searching for the milter protocol documentation and had trouble. cheers, raf
Re: add alias without reload
On Sat, May 14, 2022 at 06:20:57PM +0800, wilson wrote: > After adding alias to: > > virtual_alias_maps > > and run: > > postmap virtual_alias_maps > > postfix can know the alias was added even if there is no postfix reload. > > How does postfix know the alias was added? > > Thanks The way I think of it (which might be wrong), is that when a database type needs postalias/postmap to create a binary file from a text source file, postfix processes access the binary file for each lookup, so when the binary file is updated, postfix processes see the updated information immediately. But when a database type doesn't need a binary version, and postalias/postmap are not used, then postfix processes read the text source file and hang on to the information in it even if it changes on disk. But that only lasts until the processes stop and are replaced with new ones (which doesn't take very long), so a reload still isn't strictly needed unless you really want the updates to take effect immediately. But you might want that, if you want to test the update. The database types that use postalias/postmap to create a binary file are: btree cdb dbm hash lmdb sdbm The database types that are read directly as text are: pcre regexp cidr texthash You didn't specify an explicit database type in the postmap command, so it's probably hash (i.e., the value of the $default_database_type parameter). cheers, raf
Re: Restricting MAIL_FROM based on SASL login
On Wed, May 04, 2022 at 04:49:10PM +0200, Víctor Rubiella Monfort
wrote:
> El 4/5/22 a las 12:27, Matus UHLAR - fantomas escribió:
> > On 04.05.22 10:50, Víctor Rubiella Monfort wrote:
> > > I'm working on a map for restrict MAIL_FROM declared on mail based
> > > on sasl user authenticated.
> > >
> > > For example if we want that all accounts for domain @domain1.com can
> > > define MAIL_FROM @domain1.com and @domain2.co accounts:
> > >
> > > @domain1.com accou...@domain1.com accou...@domain2.com
> > > accou...@domain2.com accou...@domain2.com
> > > @domain2.com accou...@domain1.com accou...@domain2.com
> > > accou...@domain2.com accou...@domain2.com
> >
> > > I store this on map file and add this configuration on postfix:
> > >
> > > smtpd_sender_login_maps: hash:/etc/postfix/sender_restrictions_map
> > >
> > > smtpd_sender_restrictions
> > > .*
> > > reject_sender_login_mismatch*
> > >
> > > This seems works fine, but is incremental complexity of this map
> > > when we add several domains and this domain has several accounts,
> > > for example if we add 4 domains with 20, 30 o 50 accounts each one.
> > >
> > > There are any way to do something like this:
> > >
> > > @domain1.com @domain1.com,@domain2.com,@domain3.com
> > > @domain2.com @domain1.com,@domain2.com,@domain3.com
> > > @domain3.com @domain1.com,@domain2.com,@domain3.com
> > >
> > > The final purpose is restrict domains can be used on MAIL_FROM,
> > > based on domain used on SASL account. Without consider each account.
> >
> > If you want to allow all accounts to specify all addresses in
> > @domain1.com and @domain2.com, why to specify them at all?
> >
> > Not specifying @domain1.com and @domain2.com should not restrict sending
> > mail from those domains at all.
> >
> > for unauthenticated clients, you can deny mail from: using
> > check_sender_access.
> >
> >
> So, because not all domains can use all domains :D, this should be more
> clarify sample
>
> @domain1.com @domain1.com,@domain2.com,@domain3.com
> @domain2.com @domain1.com,@domain2.com,@domain3.com
> @domain3.com @domain1.com,@domain2.com,@domain3.com
> @domain4.com @domain4.com,@domain5.com
> @domain5.com @domain4.com,@domain5.com
Perhaps you could write a little script that takes the above
information and associated user names, and generates the map
file that Postfix needs. That would automate the incremental
complexity.
I've attached an example script and input file that might do.
But it might not exactly match your requirements.
It assumes that every domain in each group of domains
shares all its user names with the other domains
in its group. If that's not the case, it won't work.
Also, I think you might have mistyped your example,
because accou...@domain2.com appears twice in each
map entry, and I'm assuming that one of them is
supposed to be accou...@domain1.com. If not,
then I have misunderstood.
Given this input:
# List domain groups
domain1.com domain2.com domain3.com
domain4.com domain5.com
# List the user names in each domain group
@domain1.com account1 account2
@domain4.com account1 account3
The attached script produces:
@domain1.com accou...@domain1.com accou...@domain1.com accou...@domain2.com
accou...@domain2.com accou...@domain3.com accou...@domain3.com
@domain2.com accou...@domain1.com accou...@domain1.com accou...@domain2.com
accou...@domain2.com accou...@domain3.com accou...@domain3.com
@domain3.com accou...@domain1.com accou...@domain1.com accou...@domain2.com
accou...@domain2.com accou...@domain3.com accou...@domain3.com
@domain4.com accou...@domain4.com accou...@domain4.com accou...@domain5.com
accou...@domain5.com
@domain5.com accou...@domain4.com accou...@domain4.com accou...@domain5.com
accou...@domain5.com
Hopefully, someone will suggest a nice elegant approach instead,
but something like this can work and take the tedium and risk out of it.
cheers,
raf
#!/usr/bin/env perl
use warnings;
use strict;
# mk_sender_restrictions_map
# Make /etc/postfix/sender_restrictions_map
# from /etc/postfix/sender_restrictions_map.in
my $map = '/etc/postfix/sender_restrictions_map';
my $in = $map . '.in';
my @domain_groups; # List of listrefs containing domain names
my %user_names; # Map from @domain to listref containing user names
# Read the config file
open my $fh, '<', $in or die "$0: Failed to open $in for reading: $!\n";
while (<$fh>)
{
# Strip comments, trim, skip blank lines
s/#.*$//, s/^\s+//, s/\s+$//, s/\s+/ /g;
nex
Re: off-topic mta-sts/office.com question
On Sun, May 01, 2022 at 10:17:33PM -0400, Viktor Dukhovni wrote: > On Mon, May 02, 2022 at 12:04:13PM +1000, raf wrote: > > > The test email bounced with the following report: > > > > > Diagnostic information for administrators: > > > > > > Generating server: ME3PR01MB8390.ausprd01.prod.outlook.com > > > Receiving server: ME3PR01MB8390.ausprd01.prod.outlook.com > > > > > > r...@libslack.org > > > 5/1/2022 12:09:32 AM - Server at ME3PR01MB8390.ausprd01.prod.outlook.com > > > returned '550 5.4.317 Message expired, cannot connect to remote > > > server(451 4.7.5 Remote certificate MUST have a subject alternative name > > > matching the hostname (MTA-STS))' > > > 4/30/2022 11:59:28 PM - Server at libslack.org (82.134.31.111) > > > returned '450 4.4.317 Cannot connect to remote server [Message=451 > > > 4.7.5 Remote certificate MUST have a subject alternative name matching > > > the hostname (MTA-STS)] [LastAttemptedServerName=libslack.org] > > > [LastAttemptedIP=82.134.31.111:25] > > > [SY4AUS01FT024.eop-AUS01.prod.protection.outlook.com](451 4.7.5 Remote > > > certificate MUST have a subject alternative name matching the hostname > > > (MTA-STS))' > > > > The test email was sent to r...@libslack.org. > > libslack.org's MX record points to smtp10.infotech.no. > > smtp10.infotech.no's IP address is 82.134.31.111. > > https://mta-sts.libslack.org/.well-known/mta-sts.txt > > contains "mx: smtp10.infotech.no". > > That MX host has a self-signed certificate with a name of > "elrond10.infotech.no", which is rather at odds of the promised support > for MTA-STS, which requires a Web-PKI trusted certificate with a DNS > subject alternative name matching the MX hostname. > > The details of the error message may be variously misleading, but that > does not change the fact that this domain should not promise what it > does not deliver. > > -- > Viktor. Good point. This must be what the bounce message is trying to say. The MTA-STS wasn't intended. It was a result of using one of my domains for testing that server (and not being careful about it). I'll make sure MTA-STS is not involved at all for the next test. Thanks. cheers, raf
