[pfx] Re: 25 years today
On 2023-12-14 14:20, 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. Also thanks from me. I've used postfix since 2000, and it has always been software, documentation and support of the highest quality. Among all the many excellent aspects of Postfix, I would like to especially mention the care taken to ensure backwards compatibility. I've never had to fear breaking things by upgrading Postfix, and I appreciate that very much. -- Jesper Dybdal https://www.dybdal.dk ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: resolv.conf in chroot
On 2023-11-05 17:51, Wietse Venema via Postfix-users wrote: Jesper Dybdal via Postfix-users: To avoid using a public name server for DNSBL lookups, I would like the DNSBL checks to be done using only the name server running on localhost. But I would like the rest of the system to have for instance Google as a secondary name server. I do not use postscreen. If I place a resolv.conf containing only localhost in the postfix chroot jail, while /etc/resolv.conf contains multiple name servers, will that work?? I.e., is resolv.conf read by postfix (smtpd, I assume) only after it is chrooted? (I assume so, but would like confirmation.) If that is the case, all I need is to somehow make Debian not copy /etc/resolv.conf into the chroot jail. Have you considered running a local DNS resolver? Then all you need is "nameserver: 127.0.0.1". That also gives you a bit more privacy than sending all queries to the same provider. Wietse I do run a local resolver. I am just (and quite possibly unnecessarily) worried that during the (few) moments where the local resolver for some reason is stopped, some DNSBL may react badly to a request that comes from the secondary, public, resolver - by responding in a way that causes the mail to be rejected. -- Jesper Dybdal https://www.dybdal.dk ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: resolv.conf in chroot
On 2023-11-05 15:41, Matus UHLAR - fantomas via Postfix-users wrote: Jesper Dybdal via Postfix-users skrev den 2023-11-05 13:48: To avoid using a public name server for DNSBL lookups, I would like the DNSBL checks to be done using only the name server running on localhost. But I would like the rest of the system to have for instance Google as a secondary name server. On 05.11.23 15:12, Benny Pedersen via Postfix-users wrote: its more simple to let postfix use /etc/resolver.conf as is, and then let spam filter use loopback ips only spamassassin local.cf: this does not apply for checks done in postfix. Thanks for your responses. As Matus writes, it will for instance not influence reject_rbl_client restrictions. Meanwhile, I got another idea: let resolv.conf contain localhost + (say) 8.8.8.8, and make a firewall rule that blocks connections to 8.8.8.8 when issued by userid postfix or amavis. Then I won't have to mess with Debian's copying of resolv.conf. Is there any real disadvantage in that (assuming that localhost's name server is almost always available)? -- Jesper Dybdal https://www.dybdal.dk ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] resolv.conf in chroot
To avoid using a public name server for DNSBL lookups, I would like the DNSBL checks to be done using only the name server running on localhost. But I would like the rest of the system to have for instance Google as a secondary name server. I do not use postscreen. If I place a resolv.conf containing only localhost in the postfix chroot jail, while /etc/resolv.conf contains multiple name servers, will that work? I.e., is resolv.conf read by postfix (smtpd, I assume) only after it is chrooted? (I assume so, but would like confirmation.) If that is the case, all I need is to somehow make Debian not copy /etc/resolv.conf into the chroot jail. Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Number of active amavis processes
On 2023-09-13 09:00, Matus UHLAR - fantomas via Postfix-users wrote (in another thread): you may need to limit number of concurrent amavis instances if you don't have enough of CPU or RAM, e.g. in main.cf: smtp-amavis_destination_concurrency_limit = 2 and in amavis config: $max_servers = 2; which have prompted me to take a look at my own amavis process limit. I use amavis as a post-queue filter for submission (via 587, 465, or sendmail(1)) and amavis-milter as pre-queue filter on port 25. What is the correct way to limit the total number of active concurrent amavis process? Will I get the desired effect if I ensure that _destination_concurrency_limit for the post-queue amavis smtp plus the process limit for the port 25 smtpd does not exceed the number of amavis processes? Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Controlling envelope sender of sendmail(1) submission
On 2023-01-01 19:54, Wietse Venema wrote: Viktor Dukhovni: On Sun, Jan 01, 2023 at 05:03:27PM +0100, Jesper Dybdal wrote: ... (I seem to remember that there was a thread here about a similar subject some time ago, but I can't find it now.) Did you mean https://www.postfix.org/postconf.5.html#local_login_sender_maps That was indeed what I meant. I'm not going to upgrade my postfix yet, but when I do, I expect to use it. This is available in Postfix 3.6 and later so it was added very late in the Postfix life cycle. BTW the documentation example can be simplified by inlining the PCRE table in main.cf (Postfix 3.7 and later). Thanks a lot to both of you! -- Jesper Dybdal https://www.dybdal.dk
Controlling envelope sender of sendmail(1) submission
I use reject_authenticated_sender_login_mismatch to control which envelope sender addresses SASL clients can use. That works just fine. Is there a similar way to control which envelope sender addresses can be used by which system user by calling sendmail(1)? (I seem to remember that there was a thread here about a similar subject some time ago, but I can't find it now.) I use authorized_submit_users which is much better than nothing, but the more detailed control that reject_authenticated_sender_login_mismatch provides for SASL would be nice to also have for sendmail(1) submission. Or perhaps I've overlooked some good reason why it would be a bad idea to control sendmail(1) submission in such detail? -- Jesper Dybdal https://www.dybdal.dk
Re: Forward & Reverse DNS Lookups not working correctly
On 2022-11-05 11:57, Paul Kudla wrote: ... # nslookup 10.220.0.6 6.0.220.10.in-addr.arpa name = syslog-local.scom.ca. ... Name: syslog-local.scom.ca Address: 10.228.0.6 Ought that 228 not to be 220? -- Jesper Dybdal https://www.dybdal.dk
Re: different milters for different SMTP clients
On 2022-07-28 13:17, Ivars Strazdiņš wrote: The example for smtpd_milter_maps setting seems to be all or none approach - it seems not possible to configure postfix to apply only some milters based on client’s IP address. If I've understood what you want, then smtpd_milter_maps can do just that. Here is my smtpd_milter_map file: # # jd 2022-06-07 # # Milter selection for external mail # # Most client IP addresses need both milters: # amavisd-milter: inet:127.0.0.1:10029 # opendmarc: inet:127.0.0.1:10030 # # but for some mailing list IP addresses we skip # opendmarc to avoid false positives. # # Disabling all milters can be done with a # RHS of "DISABLE" here. That would disable # Amavis, including spamassassin and DKIM, # and DMARC check, so it would not be a good # idea. # # The Postfix mailing list seems to send from some # of these addresses: 168.100.1.0/28 inet:127.0.0.1:10029 # bendel.debian.org: Debian mailing lists: 82.195.75.100 inet:127.0.0.1:10029 # vger.kernel.org: Netfilter mailing list: 23.128.96.18 inet:127.0.0.1:10029 # postfix.charite.de: Amavis mailing list: 141.42.206.35 inet:127.0.0.1:10029 # lists.clamav.net: ClamAv mailing list: 192.34.61.247 inet:127.0.0.1:10029 # Catchall: use both milters for all other client addresses # (IPv6 included just in case it becomes relevant some day): 0.0.0.0/0 inet:127.0.0.1:10029,inet:127.0.0.1:10030 ::/0 inet:127.0.0.1:10029,inet:127.0.0.1:10030 -- Jesper Dybdal https://www.dybdal.dk
Re: smtpd_milter_maps and XFORWARD
On 2022-04-08 16:22, Wietse Venema wrote: Jesper Dybdal: I run Amavis as a before-queue filter, and opendmarc in the after-Amavis smtpd instance. Why not use Amavis as a before-queue MILTER? Then there is no need to propagate remote SMTP client info through non-Postfix programs. Thanks for the suggestion. I have now done that: amavisd-milter and opendmarc. It seems to work fine. A hint for others migrating from content_filter or smtpd_proxy_filter to milters: don't forget to remove "-o receive_override_options=no_address_mappings" from the options to the port 25 smtpd instance. I neglected that, and it wook me quite a while to figure out why mail was not delivered. -- Jesper Dybdal https://www.dybdal.dk
Re: Pre- or post-queue filter for authenticated submission
On 2022-04-13 16:06, Dominic Raferd wrote: On 13/04/2022 13:29, Jesper Dybdal wrote: I use amavisd-new for the smtpd instances that receive authenticated submission. Are there any significant pros and cons in doing this as a pre-queue filter (proxy) compared to doing it as a post-queue content filter? I suspect that it doesn't really matter for a low-volume server like mine, but I might have overlooked something. (For unauthenticated mail from the outside, it will be a pre-queue amavisd-milter setup.) Thanks, Jesper Pro is that users know immediately that their email has been accepted (or not), rather than being informed afterwards. Con is that users might experience slow submission of emails, because amavis (calling clamav, SA etc) may take quite a number of seconds to decide whether to accept the incoming email. (This should not normally be a problem for unauthenticated mail where delays are standard.) That was what I expected. I'll probably choose post-queue filtering for submission, based on Matus' experience. Thanks to all who responded. -- Jesper Dybdal https://www.dybdal.dk
Re: Pre- or post-queue filter for authenticated submission
On 2022-04-13 15:24, Wietse Venema wrote:
Jesper Dybdal:
I use amavisd-new for the smtpd instances that receive authenticated
submission.
Are there any significant pros and cons in doing this as a pre-queue
filter (proxy) compared to doing it as a post-queue content filter?
Doing what as a filter?
Scanning outgoing mail for viruses and spam with amavis.
Pro is that you have the option to configure different filters for
different mail streams. The MUA (submission and smtps) service
configurations can be distinct from the MX ("port 25") service
configuration.
Yes. Port 25 will be handled before-queue with amavis as a milter and
the opendmarc milter.
Port 587/465 will also be subjected to amavis scan.
I just wonder whether there is any advantage to doing that as a
before-queue filter compared to an after-queue filter. There are
obvious advantages to handling port 25-mails before-queue, but I don't
really see any advantage in doing that for the submission ports, since
sending bounces to my own users should not be a problem. Is that
correctly understood?
--
Jesper Dybdal
https://www.dybdal.dk
Pre- or post-queue filter for authenticated submission
I use amavisd-new for the smtpd instances that receive authenticated submission. Are there any significant pros and cons in doing this as a pre-queue filter (proxy) compared to doing it as a post-queue content filter? I suspect that it doesn't really matter for a low-volume server like mine, but I might have overlooked something. (For unauthenticated mail from the outside, it will be a pre-queue amavisd-milter setup.) Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: smtpd_milter_maps and XFORWARD
On 2022-04-08 20:10, Wietse Venema wrote: You can specify multiple Milters. Each Milter only sees the inputs that Postfix and earlier Milters have allowed. Message content changes made by one Milter are visible to Milters that follow. Thanks. Can milters also see content changes (added headers) made by a policy service? -- Jesper Dybdal https://www.dybdal.dk
Re: smtpd_milter_maps and XFORWARD
On 2022-04-08 16:22, Wietse Venema wrote: Jesper Dybdal: I run Amavis as a before-queue filter, and opendmarc in the after-Amavis smtpd instance. Why not use Amavis as a before-queue MILTER? Then there is no need to propagate remote SMTP client info through non-Postfix programs. That might well be a good idea. I'll need to study the documentation carefully before I experiment with such a change. Postfix supports XFORWARD for logging which requires a low level of trust, because information from XFORWARD has no effect on SMTP server policies. XFORWARD could be used to integrate with a remote provider that sends you cleaned email. XCLIENT is for impersonation, which requires a high level of trust because information from XFORWARD will affect SMTP server policies. So we should not mix up XFORWARD with XCLIENT. As I obviously did - I had forgotten that there are two variants with that important difference. Does it make sense to send XCLIENT into a content filter? It would not be difficult to add, but all filters of interest have a MILTER API nowadays, so people can use that instead. And in addition, for my setup, Amavis would also have to forward XCLIENT to the after-amavis smtpd - I don't know if it would do that. I think I'll manage with what I have until I have the time to understand and setup an amavis-milter solution. Are smtpd_recipient_restrictions, particularly policy services, evaluated before milters, so that I could use policyd_spf to check SPF, and have amavis and opendmarc milters in that same smtpd instance - so the milters could use the Authentication-Results header from policyd_spf and opendmarc could use the one from amavis' DKIM check? (I have a feeling that this is a stupid question with an obvious answer, but if so, the answer eludes me right now.) Alternatively, I'll just have to use a milter SPF checker. Thanks to Wietse and Benny for the responses. -- Jesper Dybdal https://www.dybdal.dk
smtpd_milter_maps and XFORWARD
I run Amavis as a before-queue filter, and opendmarc in the after-Amavis smtpd instance. I would like to use smtpd_milter_maps to exclude some networks from the DMARC check. But it does not seem to work. My guess is that this is because the smtpd instance that should do this comes after Amavis, and thus gets all its connections from localhost. And it seems not to respect XFORWARD. Similarly, it seems that the XFORWARD data are not sent to the milter, so that opendmarc's own configuration option to ignore some IP address does not work either. If my guesses here are correct: would it not be a good idea to let smtpd use the data from XFORWARD when looking addresses up in smtpd_milter_maps and when communicating with milters? (I'm beginning to suspect that perhaps my setup it is not a really good idea - but I do like having Amavis as a pre-queue filter.) Versions, all from Debian 10.12 (Buster): postfix 3.4.14, amavisd-new-2.11.0 (20160426), opendmarc 1.3.2. Thanks, Jesper -- Jesper Dybdal https://www.dybdal.dk
Re: milter_header_checks, pcre, chroot
On 2022-03-19 17:49, Matus UHLAR - fantomas wrote: this should be fixable by using proxymap, better than disabling chroot http://www.postfix.org/proxymap.8.html Thanks. As far as I can see, I need to add proxy:regexp:/etc/postfix/regexp_milter_header_checks to proxy_read_maps. But proxy_read_maps has a long default value - is there a not-too-ugly way to add my milter header checks to the value without losing the default value contents? (OT: Having looked at log files while implementing DMARC check, I am surprised to see that it seems to be not very unusual for companies to have p=reject in their DMARC policy but still send mail that does not pass DMARC - in some cases even with neither SPF nor DKIM. I'm beginning to fear that it will be a while before DMARC can be really useful...) -- Jesper Dybdal https://www.dybdal.dk
Re: milter_header_checks, pcre, chroot
On 2022-03-18 12:35, I wrote: I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue filter. ... Mar 18 11:42:53 nuser postfix/cleanup[8931]: warning: unsupported dictionary type: pcre (/usr/lib/postfix/postfix-pcre.so: No such file or directory) Mar 18 11:42:53 nuser postfix/cleanup[8931]: warning: pcre:/etc/postfix/pcre_milter_header_checks is unavailable. unsupported dictionary type: pcre I have now experimented more with "milter_header_checks", with the following results: * If cleanup is running chroot, then it seems that files needed for "milter_header_checks" cannot be accessed outside the chroot jail. Files needed for other header check variants seem to work fine also outside the jail. No real problem: I've now simply turned off chroot for cleanup. * Headers inserted by milters seem to be subjected to "milter_header_checks" even if receive_override_options=no_header_body_checks is set in the smtpd stanza in master.cf. And that is just what I wanted. Conclusion: As so often, it turns out that postfix, in this case "milter_header_checks", can do what is needed. (Though it would be even better if it also supported PREPEND.) And thanks to Matus and PGNet Dev for interesting suggestions of alternative solutions that I may need if my requirements change. -- Jesper Dybdal https://www.dybdal.dk
Re: milter_header_checks, pcre, chroot
On 2022-03-18 13:07, Matus UHLAR - fantomas wrote: On 18.03.22 12:35, Jesper Dybdal wrote: I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue filter. I would now like to add DMARC validation, done by the opendmarc milter in the after-Amavis smtpd instance. This basically works: opendmarc inserts an "Authentication-Results" header. I would now like to do something (e.g., reject) depending on that header. opendmarc can reject itself, if you configure it to. Thanks for your response. If the version of opendmarc that is included in Debian Buster is configured to reject, then it also puts "quarantine" mails in postfix' hold queue, which is not practical. So I would prefer to just get the header, and then control what happens after that with postfix header checks. However, opendmarc milter requires those Authentication-Results headers for SPF and DKIM to be already present. so you need spf/dkim milter(s) before opendmarc. I use Amavis to generate and verify DKIM signatures, and policyd-spf-python to perform SPF checks. That works, but means that the opendmarc milter must be run by the after-Amavis smtpd. -- Jesper Dybdal https://www.dybdal.dk
milter_header_checks, pcre, chroot
I run postfix 3.4.14 (Debian Buster) with Amavisd-new as a pre-queue filter. I would now like to add DMARC validation, done by the opendmarc milter in the after-Amavis smtpd instance. This basically works: opendmarc inserts an "Authentication-Results" header. I would now like to do something (e.g., reject) depending on that header. My first attempt was to add milter_header_checks to the after-Amavis smtpd stanza in master.cf. That did not work, probably because milter_header_checks is evaluated by cleanup, not smtpd. I then tried to add milter_header_checks = pcre:/etc/postfix/pcre_milter_header_checks to main.cf. This gave the surprising result: Mar 18 11:42:53 nuser postfix/cleanup[8931]: warning: unsupported dictionary type: pcre (/usr/lib/postfix/postfix-pcre.so: No such file or directory) Mar 18 11:42:53 nuser postfix/cleanup[8931]: warning: pcre:/etc/postfix/pcre_milter_header_checks is unavailable. unsupported dictionary type: pcre Surprising, because I have a well-working pcre table used by smtpd: check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, And: root@nuser:~# postconf -m | grep pcre pcre smtpd and cleanup are both running chroot, so I can't quite understand why smtpd can use pcre and cleanup cannot. /usr/lib/postfix/postfix-pcre.so exists, but not in the chroot jail. Do I need to run cleanup without chroot? (Or use regexp instead) An additional question: Is it correctly understood that even though receive_override_options=no_header_body_checks can be specified as smtpd argument, the individual header checks parameters cannot be turned on or off in smtpd, but only globally in cleanup? So that I cannot turn off, e.g., header_checks in a single master.cf smtpd stanza while still having a milter_header_checks parameter active for mail received by that stanza? -- Jesper Dybdal https://www.dybdal.dk
Re: Opendmarc in after-Amavis smtpd fails
On 2021-04-14 18:01, Benny Pedersen wrote: On 2021-04-14 06:27, Simon Wilson wrote: Like you I use amavis to DKIM sign outbound email, not opendkim. I just prefer the way it handles it. I know it's a different setup to yours, but may provide an alternate route. amavisd could support metacpan Mail::DMARC with imho could help simplify it very much Yes - if Amavis could do DMARC check, that would be a very nice solution. -- Jesper Dybdal https://www.dybdal.dk
Re: Opendmarc in after-Amavis smtpd fails
On 2021-04-14 06:27, Simon Wilson wrote: Looks like opendmarc is seeing the injected amavis mail as localhost, which I assume it is... by default opendmarc will ignore that. Yes, that is what I also suspect. I don't quite understand why the client IP address should concert a DMARC check. And if it does, then it seems to me that it would be a good idea for postfix to use XFORWARD information when sending the client address to a milter. But perhaps there is some reason for not doing that. For what it is worth, this is my config for INBOUND email: - pypolicyd-spf called as a check_policy_service in smtpd_recipient_restrictions runs SPF checks, inserting an Authentication-Results header with SPF evaluation - smtpd_milter_maps calls opendkim and opendmarc (in that order) - I have smtpd_milter_maps set so the milters do not run on internal addresses: # Skip milters if mail is from internal addresses or localhost smtpd_milter_maps = cidr:/etc/postfix/smtpd_milter_map - opendmarc.conf is also configured to ignore IgnoreAuthenticatedClients; and IgnoreHosts contains my local network (although I think this last is duplication given the smtpd_milter_maps setting) - All SMTP inbound mail other than from localhost or local network therefore gets SPF, DKIM and DMARC evaluated - Postfix then calls amavis as a content_filter - Amavis evaluates, calls spamassassin (which applies rules on SPF, DKIM, DMARC), etc., and then passes back to postfix. - postfix has no content_filter or milters on the re-injected mail, so it comes back in for delivery Thanks for sharing your setup. I do, however, really like having Amavis as before-queue filter, so I hope I can get that working. Like you I use amavis to DKIM sign outbound email, not opendkim. I just prefer the way it handles it. Yes, I also like the Amavis DKIM-setup, and would prefer to keep it. -- Jesper Dybdal https://www.dybdal.dk
Re: Opendmarc in after-Amavis smtpd fails
I did not get any replies to the message below. So I'm trying again, with a few additional details and questions added at the end. On 2021-04-04 15:13, I wrote: I use postfix 3.4.14 (Debian Buster) with amavisd-new as a pre-queue filter (smtpd_proxy_filter). I use Amavis to generate and verify DKIM signatures, and policyd-spf-python to preform SPF checks. This works fine. But now I would like to add DMARC verification. Since DMARC needs the DKIM result from Amavis, my plan was to use the opendmarc milter in the after-Amavis smtpd instance. But this does not seem to work. Opendmarc logs "ignoring connection from localhost" and seems to do nothing. The after-Amavis smtpd listens at port 10028; opendmarc listens at port 10030. I have placed configuration information and tcpdump examples at https://www.dybdal.dk/opendmarc-problem/ I have verified with tcpdump that Amavis does provide an XFORWARD command to the after-Amavis smtpd. I have verified with tcpdump that the after-Amavis smtpd does connect to opendmarc and that they have a (very short) dialog. I don't know the milter protocol. The short dialog between the after-Amavis smtpd and opendmarc contains "127.0.0.1" a few times, but not the XFORWARD address, but I do not know if that is suspicious. I would very much appreciate it if somebody can tell me what is going on - and what opendmarc means with that error message. Since then, I've had a look at the milter protocol. And yes, one of the 127.0.0.1 addresses transmitted to the milter is the client IP address. But I do not understand why a DMARC check should even consider the client IP address - I would have thought that it should be concerned only with the "From:" and "Authentication-Results" headers. Also, I've found an old thread, in which it seems that the poster has succeeded in doing exactly what I'm trying - I can't see why it should be different from my setup: On 2019-02-25 19:43, Patrick Proniewski wrote: Then, I'm currently trying another approach. In my current setup, I've an amavisd sandwich: outer-smtp->amavisd->inner-smtp. I can't put opendmarc or any milter on the outer-smtp, so I've put opendmarc on the inner-smtp. It's working OK so far, but I'll need extensive testing to check all possible case. An alternative solution might be to use the milter variant of amsvis: policyd-spf, amavis-milter (doing DKIM), openDMARC milter. Would that work? (I hesitate to do major changes, since this is a production system.) Any help would be greatly appreciated. -- Jesper Dybdal https://www.dybdal.dk
Opendmarc in after-Amavis smtpd fails
I use postfix 3.4.14 (Debian Buster) with amavisd-new as a pre-queue filter (smtpd_proxy_filter). I use Amavis to generate and verify DKIM signatures, and policyd-spf-python to preform SPF checks. This works fine. But now I would like to add DMARC verification. Since DMARC needs the DKIM result from Amavis, my plan was to use the opendmarc milter in the after-Amavis smtpd instance. But this does not seem to work. Opendmarc logs "ignoring connection from localhost" and seems to do nothing. The after-Amavis smtpd listens at port 10028; opendmarc listens at port 10030. I have placed configuration information and tcpdump examples at https://www.dybdal.dk/opendmarc-problem/ I have verified with tcpdump that Amavis does provide an XFORWARD command to the after-Amavis smtpd. I have verified with tcpdump that the after-Amavis smtpd does connect to opendmarc and that they have a (very short) dialog. I don't know the milter protocol. The short dialog between the after-Amavis smtpd and opendmarc contains "127.0.0.1" a few times, but not the XFORWARD address, but I do not know if that is suspicious. I would very much appreciate it if somebody can tell me what is going on - and what opendmarc means with that error message. -- Jesper Dybdal https://www.dybdal.dk
Re: sender_dependent_default_transport_maps
On 2019-09-23 22:04, Viktor Dukhovni wrote: As documented in transport(5), when a transport table entry does not specify an explicit nexthop, it uses the extant (default) nexthop for the recipient. In your case that's specified via "relayhost". Of course! Thank you very much! -- Jesper Dybdal http://www.dybdal.dk
sender_dependent_default_transport_maps
sasl_passwd
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_tls_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_restrictions = recipient_access_check, permit_mynetworks,
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname,
reject_non_fqdn_sender, check_sender_access
regexp:/etc/postfix/regexp_sender, reject_unknown_sender_domain,
reject_unknown_recipient_domain, reject_unlisted_recipient,
reject_unauth_destination, permit
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_discard_ehlo_keywords = silent-discard, etrn
smtpd_etrn_restrictions = reject
smtpd_helo_restrictions = not_jd_access_check, permit
smtpd_recipient_restrictions = permit_mynetworks, check_client_access
regexp:/etc/postfix/regexp_skip_spf_and_greylist_client,
check_recipient_access
regexp:/etc/postfix/regexp_skip_spf_and_greylist_recipient,
check_policy_service unix:private/policy-spf, check_recipient_access
regexp:/etc/postfix/regexp_greylist, check_client_access
cidr:/etc/postfix/cidr_skip_greylist, permit_dnswl_client
list.dnswl.org, check_policy_service inet:127.0.0.1:10023, permit
smtpd_relay_restrictions = permit_mynetworks,
reject_unauth_destination, permit
smtpd_restriction_classes = rblmild, rblnormal, rblaggressive,
rblcountries, recipient_access_check, sasl_access_check,
not_jd_access_check, spamblock_senders
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_sender_login_maps = regexp:/etc/postfix/regexp_sender_login_maps
smtpd_sender_restrictions = permit_mynetworks, check_client_access
cdb:/etc/postfix/checkip, check_client_access
regexp:/etc/postfix/regexp_checkip,
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
permit_dnswl_client list.dnswl.org=127.0.[0..255].[2..3],
permit_dnswl_client list.dnswl.org=127.0.[3;5].[0..255],
check_recipient_access regexp:/etc/postfix/regexp_select_rbl, permit
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/nuser.dybdal.dk/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/nuser.dybdal.dk/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_database =
smtputf8_enable = no
spamblock_senders = check_sender_access
regexp:/etc/postfix/regexp_spamblock_senders
unknown_address_reject_code = 550
virtual_alias_domains = regexp:/etc/postfix/virtual_regexp
virtual_alias_maps = regexp:/etc/postfix/virtual_regexp
root@nuser:~#
--
Jesper Dybdal
http://www.dybdal.dk
Re: Unexpected queue file write error
On 2019-09-17 13:02, Wietse Venema wrote: Jesper Dybdal: Can "Error: queue file write error" mean anything other than a problem with the queue file? Yes. LOOK IN THE LOGS. Postfix will not reveal internal error details in its responses to random SMTP clients. You're right: I had somehow overlooked"timeout talking to proxy 127.0.0.1:10024", which undoubtedly is the problem. Port 10024 is the pre-queue amavisd-new. Now I just need to figure out why amavis times out. Thanks, Jesper Dybdal
Unexpected queue file write error
Can "Error: queue file write error" mean anything other than a problem with the queue file? Or does it perhaps actually come from amavis? I am suddenly getting lots of these. The thing I've change is the internet connection (a new faster connection), but nothing at all is changed with the file permissions and there is lots of room on the disk. Postfix 3.1.12 (Debian Stretch). A slightly edited session transcript is shown below. Thanks, Jesper Dybdal Transcript of session follows. Out: 220 nuser.dybdal.dk ESMTP Postfix (Debian/GNU) In: EHLO mail-oi1-f178.google.com Out: 250-nuser.dybdal.dk Out: 250-PIPELINING Out: 250-SIZE 52428800 Out: 250-VRFY Out: 250-STARTTLS Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: STARTTLS Out: 220 2.0.0 Ready to start TLS In: EHLO mail-oi1-f178.google.com Out: 250-nuser.dybdal.dk Out: 250-PIPELINING Out: 250-SIZE 52428800 Out: 250-VRFY Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM:<**@gmail.com> SIZE=5081 Out: 250 2.1.0 Ok In: RCPT TO:<*@dybdal.dk> Out: 250 2.1.5 Ok In: DATA Out: 354 End data with . Out: 451 4.3.0 Error: queue file write error Out: 421 4.7.0 nuser.dybdal.dk Error: too many errors Session aborted, reason: too many errors
Re: The compatibility_level mechanism
On 2018-03-12 12:12, Wietse Venema wrote: Whereas compatibility is easy to check for features that are implemented in one place, smtputf8 affects a lot of programs. One would have to enable it under the covers, but not enforce it. Thanks for the explanation. I'll be more careful the next time I increment compatibility_level. -- Jesper Dybdal http://www.dybdal.dk
The compatibility_level mechanism
The compatibility_level mechanism is an excellent and very well designed idea. But I must have misunderstood something - or there is an error. Around christmas I upgraded from postfix 2.11 to 3.1.6 (Debian 9). I let the system run with compatibility_level=0 for a couple of months. I then checked the log file for occurrences of "using backwards-compatible", which I thought would tell me where I depended on obsolete default settings. Apart from some "chroot=y" warnings (which I fixed), there were no such entries. So I recently set compatibility_level to 2. Very soon after that I saw the following error (with domain names changed): postfix/smtp[11021]: 3zw35550Qyz4FNxb: to=<bs+example.com...@nuser.example.net>, orig_to=<a...@example.com>, relay=127.0.0.1[127.0.0.1]:10027, delay=0.4, delays=0.39/0.01/0/0, dsn=5.6.7, status=bounced (SMTPUTF8 is required, but was not offered by host 127.0.0.1[127.0.0.1]) This was a message sent from a local CGI script using sendmail. Its sender and recipient were in US-ASCII, but the subject line contained (unencoded, standards-violating) ISO 8859-1 characters. [127.0.0.1]:10027 is amavisd-new 2.10.1, which I believe should support SMTPUTF8 (see https://groups.google.com/forum/#!topic/mailing.postfix.users/rKdbrpw0nc8). But that is not a postfix issue, so forget that. What I do not understand, postfix-wise, is that I have seen no warnings about "using backwards-compatible" default value of smtputf8_enable during the period where I was using compatibility_level=0. The same CGI script has undoubtedby sent several mails with ISO-8859-1 subject lines during that period. I have of course now set smtputf8_enable=no until I understand what is going on, but I would like to understand why the compatibility_level mechanism did not warn me about this problem. Jesper Dybdal -- Jesper Dybdal http://www.dybdal.dk
Re: Why is milter not called?
I always helps to ask for help - you then immediately see what you've missed. I've suddenly seen the word "no_milters" in my mail below, which probably explains the problem. I expect it will help to remove that word - sorry for the inconvenience. Jesper On 2017-11-26 21:44, Jesper Dybdal wrote: For incoming mail, I use Amavis as a pre-queue filter. I use policyd-spf-python for SPF check and let Amavis do DKIM check. I then wanted to add DMARC check. I am trying to do it using the opendmarc milter in the postfix instance to which Amavis re-injects the mail. However, the milter is not called at all. The postfix instance in question is defined as: 127.0.0.1:10028 inet n - y - - smtpd -o syslog_name=postfix/10028 -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o mynetworks=127.0.0.0/8 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters -o milter_protocol=6 -o milter_default_action=accept -o smtpd_milters=inet:127.0.0.1:10030 The milter is running and listening at port 10030 (I can connect with telnet). The postfix instance does receive and handle the mail (I can see that in the log). But postfix makes no connection to port 10030. I normally have an iptables rule that allows only user "amavis" to connect to port 10030, but I've tried removing that restriction and that did not help. Have I completely misunderstood something? -- Jesper Dybdal http://www.dybdal.dk
Why is milter not called?
For incoming mail, I use Amavis as a pre-queue filter. I use policyd-spf-python for SPF check and let Amavis do DKIM check. I then wanted to add DMARC check. I am trying to do it using the opendmarc milter in the postfix instance to which Amavis re-injects the mail. However, the milter is not called at all. The postfix instance in question is defined as: 127.0.0.1:10028 inet n - y - - smtpd -o syslog_name=postfix/10028 -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o mynetworks=127.0.0.0/8 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters -o milter_protocol=6 -o milter_default_action=accept -o smtpd_milters=inet:127.0.0.1:10030 The milter is running and listening at port 10030 (I can connect with telnet). The postfix instance does receive and handle the mail (I can see that in the log). But postfix makes no connection to port 10030. I normally have an iptables rule that allows only user "amavis" to connect to port 10030, but I've tried removing that restriction and that did not help. Have I completely misunderstood something? -- Jesper Dybdal http://www.dybdal.dk
Re: Postfix 20 years ago
On 2017-02-12 19:06, Wietse Venema wrote: Last month it was 20 years ago that I started writing Postfix code. Having done a little digging among old files, I've just realized that I've been using Postfix since autumn 2000 (or perhaps earlier). I don't even think I was aware at that time that Postfix was a relatively new piece of software. It just worked. And I could understand its configuration - which I more than I could ever really say about sendmail. I can't remember ever having to upgrade or fix anything quickly because of security bugs (or other bugs, for that matter) in Postfix. And that is a really important point for a small server that does not have a staff standing by 24/7 ready to fix things at short notice. I also appreciate the effort that has been done to keep things backwards compatible: every Postfix upgrade I've done has been a trouble-free success. And with the excellent documentation and the excellent support provided here, Postfix is a true model of high quality software. Thanks! -- Jesper Dybdal http://www.dybdal.dk
Re: Putting all outgoing mail on hold?
I wrote: Is there a simple way to put all outgoing mail (i.e., everything that would normally be processed by the default smtp instance) into the HOLD queue? Thanks for the responses. Considering the disadvantages of using the HOLD state that Noel describes, I think I'll use Wietse's suggestion. Though it doesn't allow releasing individual messages, it is at least a much cleaner way to do it than blocking with a firewall rule.
Putting all outgoing mail on hold?
Is there a simple way to put all outgoing mail (i.e., everything that would normally be processed by the default smtp instance) into the HOLD queue? The reason I would like to do that is that the IP address on which I run my little server is about to change, and I would like outgoing mail to be held until I am sure that the new address has a proper reverse DNS and is not in any problematic DNSBLs. I could also just block outgoing port 25 with a firewall rule, but using HOLD will give me better control: I can then release individual mails if I want to. -- Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Re: reverse dns fails with multiple domains
On Sat, 06 Mar 2010 22:01:14 +0100, mouss mo...@ml.netoyen.net wrote: - OP's reverse DNS is borked: $ host 188.183.91.18 18.91.183.188.in-addr.arpa domain name pointer 0xbcb75b12.cpe.ge-1-1-0-1112.hcnqu2.customer.tele.dk. $ host 0xbcb75b12.cpe.ge-1-1-0-1112.hcnqu2.customer.tele.dk. Host 0xbcb75b12.cpe.ge-1-1-0-1112.hcnqu2.customer.tele.dk. not found: 3(NXDOMAIN) so OP not only has a generic name, but it doesn't resolve back to the IP. If he can get his ISP to fix his reverse (preferably using a custom reverse), then maybe things will get better. The ISP in question is the largest Danish ISP, TDC, of which I am also a customer. They are generally quite good at having consistent forward and reverse DNS records. I expect that if the OP points out the missing A record for 0xbcb75b12.cpe.ge-1-1-0-1112.hcnqu2.customer.tele.dk. in a mail to hostmaster at tele dot dk, then they will fix it. And that will probably solve the problem, regardless of the HELO name. Alternatively, since I suspect from the reverse DNS name that the OP's connection is a Pro grade ADSL product, he can probably get TDC to set the reverse DNS of his IP address to his own name (soapnut.dk.) simply by asking TDC at that same mail address.
Re: VERP uses the recipient name after virtual_regexp rewriting
On Mon, 29 Dec 2008 21:54:52 +0100, I wrote: ... I was surprised to see that when the recipient address provided by Mailman is rewritten by Postfix' virtual_regexp, then the recipient address that Postfix encodes in the envelope return path is the rewritten address, rather than the original subscriber address that Mailman knows. I have just realized that there is another way to look at this, which may be a better argument for the semantics I would like: The problem occurs only because the sending server and the receiving server is the same; the recipient address is in a domain handled by the same postfix instance that Mailman uses to submit mail. If there were two independent postfix instances, this would not happen. In such a case, it seems to me that the result ought to be the same as if processing clearly related to the sending side, such as VERP address generation, happened before processing clearly clearly related to the receiving side, such as recipient address rewriting in virtual_maps. I.e., VERP belongs to sending processing and its result should therefore not depend on virtual_maps rewriting, which are part of the receiving processing and thus belongs logically later; it comes into effect in the same postfix instance only because the subscriber happens to be a local user. (But as I wrote earlier, I can live with the current semantics, and this will - probably - be my last attempt to convince you that the order ought to be different.)
Re: VERP uses the recipient name after virtual_regexp rewriting
On Fri, 2 Jan 2009 15:25:14 -0500 (EST), wie...@porcupine.org (Wietse Venema) wrote: Fortunately, Postfix has original recipient information at hand. Unfortunately, the information is not guaranteed to be in the canonical u...@domain form. However, in the special case of VERP this is OK. I'm glad to hear that sufficient information is available at the relevant point in Postfix' processing. The consumer of VERP bounces really wants to see the same string that it gave to the MTA. We agree completely then. Thanks for your response (and for Postfix in general - it is excellent software).
Re: VERP uses the recipient name after virtual_regexp rewriting
On Tue, 30 Dec 2008 01:10:16 +0100, I wrote: Since my first mail, I have tried an experiment where the rewriting of the sender address is done by a .forward file instead of by virtual_regexp; in that case, VERP actually uses the recipient address before it has been changed by .forward, as I would like it to do. That should of course be rewriting of the *recipient* address, not sender address.
VERP uses the recipient name after virtual_regexp rewriting
I have just installed a mailing list manager (Mailman) for use with my Postfix installation (which has just been upgraded to 2.5.5). I have patched Mailman to use the XVERP option on MAIL FROM. This works, but I was surprised to see that when the recipient address provided by Mailman is rewritten by Postfix' virtual_regexp, then the recipient address that Postfix encodes in the envelope return path is the rewritten address, rather than the original subscriber address that Mailman knows. Since mailing list software using XVERP needs to recognize the address from the envelope return path as being equal to the subscribed address, would it not be better to always use the raw address from RCPT TO, rather than the rewritten one, when creating the VERP'ed return path? I have not tested this with the 2.6 experimental release, but the release notes say nothing about VERP, so I assume the behaviour is the same in 2.6. (This is not a serious problem for me: the addresses that are rewritten in my installation are in practice local addresses and it is extremely unlikely that they will bounce. But it surprised me.) -- Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Re: VERP uses the recipient name after virtual_regexp rewriting
On Mon, 29 Dec 2008 16:21:41 -0500 (EST), wie...@porcupine.org (Wietse Venema) wrote: I do not understand why you would send mail to a recipient address other than the recipient subscribed to the Mailman list. Example: My server (for Mailman and Postfix and some local mailboxes) is named nuser.dybdal.dk. The Mailman virtual host is lists.dybdal.dk, the list I am experimenting with is named jdtest. The subscribed address that Mailman knows is jd-test2 at dybdal.dk. In virtual_regexp, this address is translated to jd+dybdal.dk+jd-test2 at nuser.dybdal.dk. I do this in order to have it delivered to the jd mailbox at nuser.dybdal, with an extension that allows my mail client to recognize the precise virtual domain and address that was used (the same mailbox receives mail to several addresses in several domains). When Mailman sends mail to jd-test2 at dybdal.dk, the address in RCPT TO is jd-test2 at dybdal.dk, but the envelope sender becomes jdtest-bounces+jd+dybdal.dk+jd-test2=nuser.dybdal.dk at lists.dybdal.dk. If this should bounce (which it won't in this example, but it might possible be rewritten to an address at another machine instead), Mailman will try to find a subscriber with the address jd+dybdal.dk+jd-te...@nuser.dybdal.dk, and fail to do so. 1) When you rewrite the envelope RECIPIENT address, then you expect Postfix VERP to use the original recipient address instead of the rewritten one. I think that would make sense, because the VERP'ed recipient address is used (only) for comparison with the subscribed address when the mail bounces. 2) What if you rewrite the envelope SENDER address? Should Postfix VERP use the original envelope sender address or the rewritten one? I had not considered that, since I have no desire to rewrite the sender address. But I think my answer to that question is no. If 1) and 2) work in opposite ways then my little mind will be really confused. I may well have misunderstood something, but it seems to me that: 1) The purpose of the VERP encoded recipient address is (only!) to allow mailing list software to recognize a subscriber, and it therefore makes sense to have the VERP encoded recipient address equal to the subscriber address as the mailing list software knows it; i.e., the RCPT TO address. This VERP use of the recipient address is quite different from the primary purpose of the recipient address, which is to get the mail to wherever the owner of the address wants it, which of course may require rewriting. 2) The purpose of the sender address (whether or not is has a VERP part appended) is to ensure that a bounce is delivered correctly; if any rewriting is specified for the sender address, surely whoever made the rewriting rule has ensured that the rewritten address will be delivered correctly. The mailing list software does not compare the sender address with anything; it just notes that it received a message at its bounce address. Since my first mail, I have tried an experiment where the rewriting of the sender address is done by a .forward file instead of by virtual_regexp; in that case, VERP actually uses the recipient address before it has been changed by .forward, as I would like it to do. Perhaps part of my problem is that I don't really see why it should make a difference to the VERP address whether the recipient address is changed by virtual_regexp or by .forward. I have not tested this with the 2.6 experimental release, but the release notes say nothing about VERP, so I assume the behaviour is the same in 2.6. Yes, this project takes pride in accurate documentatiom :-) You don't really need the smiley - the pride is very appropriate. Accurate documentation, including complete release notes, is something that I, and undoubtedly many others, very much appreciate about Postfix - and miss in many many other software products. -- Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Re: VERP uses the recipient name after virtual_regexp rewriting
On Mon, 29 Dec 2008 22:30:53 +0100, mouss mo...@netoyen.net wrote: Jesper Dybdal a écrit : Since mailing list software using XVERP needs to recognize the address from the envelope return path as being equal to the subscribed address, Really? AFAIK, most list managers use the From: header. The point in VERP is that the list subscriber that bounces can be recognized by the address that the bounce is sent to. This is a much safer way to identify the subscriber than any attempt to parse the bounce message to determine which address actually bounced. -- Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
