[pfx] Re: Postfix Site Hosting Tor Node = Blocked Access For Some
* Viktor Dukhovni via Postfix-users: >> The server hosting the Postfix website, run by yours truly, is neither >> located in Germany, nor is it a Tor exit node. > > As for TOR, some sites may have stale or inaccurate data: > > https://www.ipqualityscore.com/tor-ip-address-check/lookup/65.108.3.114 Yeah, admins need to be careful about the queried source. The Tor project publishes official data for all participating server nodes on the Tor Metrics website [1] several times per day. There are also fundamental differences between "guard", "middle" and "exit" type Tor nodes. Only the latter type routes traffic from within the Tor network to the outside world, hence the name "exit". I have been donating bandwidth and computational resources to the Tor project for many years now, but sadly the general level of awareness about what Tor actully is and how it operates has not increased all that much during that time. -Ralph [1] https://metrics.torproject.org/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter outgoing not working
On 2023-09-24 06:16, Wietse Venema via Postfix-users wrote: Stanislav via Postfix-users: Greetings, After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email is not signed with DKIM anymore. After further investigation, I've found that Postfix ignores milter on outgoing emails (incoming goes through milter ok). This has not changed in Postfix, I suppose your configuration has changed. Hi, I've found the root cause. Sorry, it's pretty trivial. While trying to generate a long-long answer with all the details to share with you guys, I've realized I have smtpd_milter_maps defined in my configuration. It's been a while, but I guess my goal was to disable Milters for local clients to skip checks, aka "whitelist" everything local, but I completely missed that DKIM signing will be disabled too because of that change. Also, it looks like I modified the smtpd_milter_maps file, though I didn't restart/reload Postfix after the modification, so when I did upgrade, new configuration finally kicked in. I appreciate your help! Thank you Best ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix Site Hosting Tor Node = Blocked Access For Some
On Mon, Sep 25, 2023 at 12:29:52AM +0200, Ralph Seichter via Postfix-users wrote: > > I have been cutoff from the Postfix web site due to it apparently > > being a TOR exit node in Germany. > > The server hosting the Postfix website, run by yours truly, is neither > located in Germany, nor is it a Tor exit node. Indeed, MaxMinds puts the IP address in Finland: 65.108.3.114: FI, Finland As for TOR, some sites may have stale or inaccurate data: https://www.ipqualityscore.com/tor-ip-address-check/lookup/65.108.3.114 However, the TOR project itself seems to disagree: -- Sanity check, at least one exit node listed: $ dig +noall +comment +ans +auth +nostats +nocl +nottl +nocmd +noedns 200.74.247.162.dnsel.torproject.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48985 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; ANSWER SECTION: 200.74.247.162.dnsel.torproject.org. A 127.0.0.2 -- Ralph's IP is not listed: $ dig +noall +comment +ans +auth +nostats +nocl +nottl +nocmd +noedns 114.3.108.65.dnsel.torproject.org ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13067 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; AUTHORITY SECTION: dnsel.torproject.org. SOA check-01.torproject.org. metrics-team.lists.torproject.org. 2309242233 3600 15 3600 15 -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix Site Hosting Tor Node = Blocked Access For Some
* Eddie Rowe via Postfix-users: > I have been cutoff from the Postfix web site due to it apparently > being a TOR exit node in Germany. The server hosting the Postfix website, run by yours truly, is neither located in Germany, nor is it a Tor exit node. -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
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
[pfx] Re: IP protocol inconsistency
Polarian via Postfix-users:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
> Hello,
>
> I understood RFC 5321 before hand, apologies for you having to type
> this all out, I feel bad now.
>
> But my point was, the documentation states that setting a preference is
> a risky action which could cause deliverability issues, the point of
> the mailing list was a "safe" way to keep IPv6 as a priority and then
> only using IPv4 as a fallback.
The purpose of Postfix is to deliver mail, not to achieve world
domination for a particular IP protocol.
If a destination has IPv4 and IPv6 addresses, then an explicit
preference for one protocol type means that ALL DELIVERIES will
suffer delays when that protocol type has an outage.
Whereas with Postfix default settings, about half of deliveries
will be slow when one of those protocols has an outage (Postfix is
smart enough to use similar numbers of IPv6 and IPv4 addressess,
to avoid huge delays when, for example, a site has many IPvX and
few IPvY addresses, and IPvX has an outage, for {X=4, Y=6} or {X=6,
Y=4}).
For me, availability matters more than protocol religion.
> The solution of using RFC 5321 to my advantage seems to be useful, but
> I am terrified that my email server will break, because that is how it
> is worded within the documentation, and it is what I am taking from
> Viktor's response, so I am really confused here.
>
> I do not want to risk having emails not being delivered, hence why I am
> asking for clarification on how it could go wrong.
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.
Wietse
___
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 09:49:52PM +0100, Polarian wrote: > > No, the choice should be random, to give messages a decent chance of > > getting through under various conditions. > > Why would you ever want to use a protocol randomly? Because gives mail the best chance to be delivered, if necessary after a few retries. > You have Happy Eyeballs which attempts to use the best protocol by > which responds the fastest, this makes sense for performance, but > randomly? How does random help? That may be fine for web services, but is not a good choice for mail, because many destinations set fairly stringent connection concurrency limits, and establishing unused connections is liable to trigger rate limits that impede mail delivery. > Say you have an issue with IPv6, and by your words random gives the > best chance. So lets say its truly random without bias, that would > imply a 50% chance of each protocol being used, would it not? > > That means only 50% of the time, the delivery works, how does this > solve the solution? When all connection attempts fail, SMTP mail is queued and retried. A different choice on retry will eventually get through. You're new here, while Wietse and contributors have been fine-tuning Postfix to be a best-in-class MTA for 25+ years. If a particular address selection approach was chosen, it was carefully considered, and is a good fit for SMTP mail. Postfix does meet your requirement of using both IPv6 and IPv4, each some of the time, when both are advertised. An MTA administrator may choose to use only IPv4 or to prefer IPv4, in which case Postfix will try IPv4 only or first. The default is sensibly address-family neutral. Belabouring this topic further will not be productive: https://www.youtube.com/watch?v=kHue-HaXXzg -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
Polarian via Postfix-users: > Hello, > > Firstly thank you for the response. > > > RFC 5321 requires that the Postfix SMTP CLIENT connects to hosts > > with primary MX preference, before connecting to hosts with a > > secondary MX preference. > > > > For example, given the following DNS records: > > > > example.com. IN MX 10 primary.example.com > > example.com. IN MX 20 secondary.example.com > > > > primary.example.com. IN fc00::1 > > primary.example.com. IN A 10.0.0.1 > > > > secondary.example.com. IN A 10.0.0.2 > > secondary.example.com. IN fc00::2 > > > > With "smtp_address_preference = ipv4", Postfix will connect to: > > > > - First, MX preference 10 address 10.0.0.1, then fc00::1, > > > > - Then, MX preference 20 addresses 10.0.0.2, then fc00::2. > > This is the expected behaviour, I do not see why this needed to be > clarified, but thank you anyways \o/ You asked this question: > What technology do you use to pick between the protocols? So I helpfully gave you that answer. > preference implies priority, so what you are saying here is if you set > it to prefer IPv6, then it will ONLY attempt IPv6 addresses? Look back at the lengthy example that I gave above for the case that "smtp_address_preference = ipv4". It should not be difficult adapt that example for the case that "smtp_address_preference = ipv6". But in case that it is too difficult, I'll do it for you. Given the following DNS records: example.com. IN MX 10 primary.example.com example.com. IN MX 20 secondary.example.com primary.example.com. IN fc00::1 primary.example.com. IN A 10.0.0.1 secondary.example.com. IN A 10.0.0.2 secondary.example.com. IN fc00::2 With "smtp_address_preference = ipv6", Postfix will connect to: - First, MX preference 10 address fc00::1, then 10.0.0.1. - Then, MX preference 20 addresses fc00::2, then 10.0.0.2. > What if I simply want to prioritise one, and use the other as a > fallback? That seems the more logical way of doing it. RFC 5321 requires that an MTA connects to primary MX addresses before secondary MX addresses. RFC 5321 does not allow an MTA to connect to IPv6 primary and secondary MX addresses, before IPv4 primary and secondary MX addresses. > - IPv6 should be attempted first In the example above, Postfix tries to reach the primary MX over IPv6, before trying to reach the primary MX over IPv4. If the primary MX is not available, Postfix tries IPv6 before IPv4 for the secondary MX. > - IPv4 should be attempted as a fallback if the IPv6 route did not > exist (remote doesn't support IPv6, aka no record) Postfix does not try to connect over IPv6 when a destination has no record. Hint: in the examples above, delete the records and keep the A records. Let me do that for you: Given the following DNS records: example.com. IN MX 10 primary.example.com example.com. IN MX 20 secondary.example.com primary.example.com. IN A 10.0.0.1 secondary.example.com. IN A 10.0.0.2 With all possible smtp_address_preference settings, Postfix will connect to: - First, MX preference 10 address 10.0.0.1. - Then, MX preference 20 address 10.0.0.2. > - Emails should ALWAYS be deliverable, it should NOT get stuck within > the queue trying to connect to a single protocol, IPv4 should only be > used as a fallback. Follow the rules of RFC 5321, use "smtp_address_preference = ipv6". See the example above for details. Keep in mind that RFC 5321 does not allow this order: - First, MX preference 10 address fc00::1, then, MX preference 20 address fc00::2. - Then, MX preference 10 address 10.0.0.1, then, MX preference 20 address 10.0.0.2. You could try to fake it with: main.cf: default_transport = smtp6 smtp_fallback_transport = smtp4 master.cf: smtp6 smtp -o inet_protocols=ipv6 smtp4 smtp -o inet_protocols=ipv4 But that would not work. When a domain has MX hosts with only A records, the smtp6 client will return mail as undeliverable with "Name service error for name=mx.example.com type=: Host found but no data record of requested type". You would also have to configure an smtp_delivery_status_filter that replaces a '5.x.x' status code for "Name service error for name=mx.example.com type=: Host found but no data record of requested type" with a '4.x.x' status code. And you might have more hoops tp jump through. Or you could just play by the rules of RFC 5321, and follw the easy path. Wietse ___ 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 07:55:16PM +0100, Polarian via Postfix-users wrote: > > Use the Postfix smtp_address_preference default: random selection. > > If an MX host has IPv4 and IPv6 addresses, this ensures that mail > > won't get stuck in the queue when one of the protocols is not > > working for that destination. > > But this is meant to be a PRIORITY, not mandatory. > > preference implies priority, so what you are saying here is if you set > it to prefer IPv6, then it will ONLY attempt IPv6 addresses? Firstly, you're mostly tilting at windmills. Mail is getting through to you, and which address family was used is largely irrelevant. Secondly, no. Preference is about about ordering, not exclusion, both addresses will be tried when the first chosen does not work out. > What if I simply want to prioritise one, and use the other as a > fallback? That seems the more logical way of doing it. Actually, no, it is not "more logical". The logical thing is to deliver mail, via one of the available addresses, while ensuring also that problems that (perhaps temporarily) make all the purported IPv4 or IPv6 addresses unreachable don't break mail delivery. > > If a destination's MX host has no record, then Postfix will > > not try to connect to it with IPv6. On the other hand, if a > > destination's MX host has an record, but the Postfix host has > > no IPv6 routes, then you should turn off IPv6 support in Postfix. > > This doesn't answer my question, how does postfix decide between IPv4 > and IPv6 with the default preference? At random. The random number generator is the rather dated rand(3), which is seeded vi srand(3) with (pid ^ epoch time). Which may show some bias under test conditions, but should be adequate in real-world conditions. > I am unsure if I wasn't clear enough, I assume that is the problem > here so I will attempt to reclarify. There is no problem. > The expected behaviour is: > > - IPv6 should be attempted first No. That's unwise. > - IPv4 should be attempted as a fallback if the IPv6 route did not > exist (remote doesn't support IPv6, aka no record) No. That's unwise. > - Emails should ALWAYS be deliverable, it should NOT get stuck within > the queue trying to connect to a single protocol, IPv4 should only be > used as a fallback. No, the choice should be random, to give messages a decent chance of getting through under various conditions. > I am unsure if you have already explained this, I took this as "You > can tell it to only use IPv6, but this will prevent delivery of > IPv4-only email servers", or I have gotten completely confused. No. If you want to always try IPv6 first, Postfix will do that, and IPv4-only sites will still work, but given enough non-working IPv6 addresses, some difficulty may be expected. Bottom line, this topic is not worth discussing further. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Example config aliases from mysqldb and /etc/aliases
Noah via Postfix-users: > Hi there, > > I am provisioning an postfix installation. Is there an example > configuration for finding aliases from a mysqldb and also checking the > /etc/aliases file please? alias_maps = hash:/etc/aliases proxy:mysql:/path/to/file This will search the MySQL table last, which reduces load on the database. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: IP protocol inconsistency
Polarian via Postfix-users: > What technology do you use to pick between the protocols? As documented at the link you mentioned, the Postfix SMTP CLIENT can sort IP addresses, with the same MX preference, by their protocol. RFC 5321 requires that the Postfix SMTP CLIENT connects to hosts with primary MX preference, before connecting to hosts with a secondary MX preference. For example, given the following DNS records: example.com. IN MX 10 primary.example.com example.com. IN MX 20 secondary.example.com primary.example.com. IN fc00::1 primary.example.com. IN A 10.0.0.1 secondary.example.com. IN A 10.0.0.2 secondary.example.com. IN fc00::2 With "smtp_address_preference = ipv4", Postfix will connect to: - First, MX preference 10 address 10.0.0.1, then fc00::1, - Then, MX preference 20 addresses 10.0.0.2, then fc00::2. Note: Postfix may not try all IP addresses. This depends on on the smtp_mx_address_limit and smtp_mx_session_limit settings. > Is there any way I can make IPv6 the priority safely without damaging > my ability to deliver mail (I do want IPv4 to be used if IPv6 fails, as > a lot of mail servers are yet to support IPv6). Use the Postfix smtp_address_preference default: random selection. If an MX host has IPv4 and IPv6 addresses, this ensures that mail won't get stuck in the queue when one of the protocols is not working for that destination. If a destination's MX host has no record, then Postfix will not try to connect to it with IPv6. On the other hand, if a destination's MX host has an record, but the Postfix host has no IPv6 routes, then you should turn off IPv6 support in Postfix. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter outgoing not working
Stanislav via Postfix-users: > Greetings, > > After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my > email is not signed with DKIM anymore. After further investigation, I've > found that Postfix ignores milter on outgoing emails (incoming goes > through milter ok). This has not changed in Postfix, I suppose your configuration has changed. Report output from: postconf -n|grep milter postconf -P|grep milter Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: milter outgoing not working
On 24.09.23 04:39, Stanislav via Postfix-users wrote: After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email is not signed with DKIM anymore. After further investigation, I've found that Postfix ignores milter on outgoing emails (incoming goes through milter ok). do you mean on mails accepted via ports 465/587? If so, what's your master.cf configuration? If you have something like: submission inet n - y - - smtpd [...] -o smtpd_milters=$mua_milters you may need to add proper milter (opendkim?) to mua_milters in main.cf -- 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. WinError #98652: Operation completed successfully. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] milter outgoing not working
* Ralf Hildebrandt via Postfix-users : > * Stanislav via Postfix-users : > > Greetings, > > > > After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email > > is not signed with DKIM anymore. After further investigation, I've found > > that Postfix ignores milter on outgoing emails (incoming goes through milter > > ok). > > How is the milter being invoked? > postconf -n |grep milter In my case this yields: # postconf -n |fgrep milter non_smtpd_milters = $smtpd_milters smtpd_milters = inet:127.0.0.1:7357 inet:127.0.0.1:8891 ^ so, two milters are used: clamav-milter and opendkim # netstat -tulpen | egrep "(7357|8891)" tcp0 0 127.0.0.1:8891 0.0.0.0:* LISTEN 983 295923257 3588942/opendkim tcp0 0 127.0.0.1:7357 0.0.0.0:* LISTEN 981 318524015 39048/clamav-milter (you might be using milters in master.cf, selectively for some processes only, so also check master.cf) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] milter outgoing not working
* Stanislav via Postfix-users : > Greetings, > > After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email > is not signed with DKIM anymore. After further investigation, I've found > that Postfix ignores milter on outgoing emails (incoming goes through milter > ok). How is the milter being invoked? postconf -n |grep milter -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] milter outgoing not working
Greetings, After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email is not signed with DKIM anymore. After further investigation, I've found that Postfix ignores milter on outgoing emails (incoming goes through milter ok). I use FreeBSD 13.2 . Does somebody experience this behavior, or it's just me? Thanks ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
