[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
Having 12x that text in the postconf masnpage would not help. Certainly not, but I think there's a good middle ground. A more practical change would just make brief reference to the distinction. For example: check_recipient_access type:table Search the specified access(5) database for the resolved RCPT TO address (and for some tables domain, parent domains, and localpart@), and execute the corresponding action. That way a newcomer knows to look for clarification on "some" if they intend to rely on a partial key lookup. Another option is to remove the partial key enumeration from these descriptions entirely. It appears that some restriction types are already documented this way (e.g. check_client_mx_access). Jakob ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Server etiquette
On 2/14/24 8:07 AM, Nikolai Lusan via Postfix-users wrote: On Wed, 2024-02-14 at 11:34 +0100, Matus UHLAR - fantomas via Postfix- users wrote: >> On Wed, 2024-02-07 at 12:15 -0500, Viktor Dukhovni via Postfix-users >> wrote: >>> I prefer to have logs that record what I'm blocking. With >>> firewall >>> rules there's not sufficient forensic evidence left behind. > On 14.02.24 19:11, Nikolai Lusan via Postfix-users wrote: >> Here's a tip - try the 'LOG' target before you DROP/DENY/REJECT (I >> prefer REJECT with an ICMP host/port unreachable for _all_ ports on >> my >> side of the link). > Unfortunately it only provides IP you have banned, not from/to mail > addresses. Depending on how convoluted a setup you want you could potentially drop in some tcpdump scans targeted at submission/smtp for the IP's in question - I'm not saying it's an easy fix, but it may just give you the information you want ... the packets are there in the network stack it's just what you do with them before you assign an iptables/nftables action to them. There is a whole heap of power in the network stack, and how/where you can route things to mess with them before a firewalling decision is made (granted this has to be done on the mail host, and you have to have the resources there to deal with it - potentially having a couple of equally weighted MX servers could spread the load and get the job done rather than adding extra RAM/CPU to an existing mail host or MX). > However I also implemented it because of too many attacks on servers.. Having been a sysadmin around the traps since the mid-to-late 1990's I have seen many an attack on servers - it comes with the territory, you run a service and some goon is going to try and exploit it. For example no matter how securely you configure an ssh server you are going to see people running distributed attacks trying to login as root (and a whole heap of other usernames - I find my ssh [attempted] auth logs to be a source of amusement, sometimes, when I'm not getting all "I'm going to track you down and stab you in "interesting" ways . Submission and IMAPS services have become another one of these things (most of the SMTP attacks are boring and easily dealt with using basic one line scripts) but I have found a decent set of fail2ban regexes with a low threshold for failure and a long ban time severely reduces the volume of these attacks, and a permanent "throw the packets on the floor" approach for repeat offenders doesn't hurt either. We all get attacks, I have only had one instance where a SYN attack actually rendered a server unusable (it was a web server and because of commercial arrangements I couldn't kill it at and edge router) - admittedly it was an HTTP[S] server, the code being used for the attack was lifted directly from a java text book, and the attacker was using his home connection to do this - suffices to say a reboot into the remote rescue console allowed me to make the server usable for legitimate clients in a short period of time, and reporting to the ISP (plus a little spite on my part) made the outcome for the little punk not so great. One thing nobody has addressed is reporting to the upstream providers for these attackers. WHOIS is a wonderful tool, and so is traceroute and it's variants, get the information contact the ISP/hosting company and/or it's upstream providers and hint a some reporting to SORBS or other blacklisting sites and you might just get them shutdown outside your network. Nobody wants to have to jump through the hoops to get off a blacklist. Also (unless you want the connections made to your hosts) having your upstream potentially block IP's at it's edge routers might have the desired effect (note I am only talking about connections made from specific IP's the you know to be carrying only attack payloads - if it is shared hosting then contacting the operator of the shared host will probably get you the outcome you want ... I know I have been on the receiving end of this, I was admining a hosting company that allowed "walk-up" hosting and someone chose a Friday evening to sign up with their own domain to the CPANEL machine and proceed to spam the shite out of things for about 2 days until something hit our support ticketing system that alerted us to this, at which point we killed the account and set about trying to restore the reputation of our IP because not to do so would have killed a heap of legitimate business for us). Running any kind of service on the open internet is going to invite some level of attacks, it's why we do internal security (I met Wietse at a security conference almost 20 years ago). But security is an ongoing process, and if you get targeted by the "wrong" people you may need to take extreme measures to keep your service running - even if it means you can't collect all the data on the attack you would like to have. The best you can do is keep evolving the measures you use to reject attacks, hope that the hosts at the
[pfx] Re: Forward mails if user unknown in local recipient table
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2024-02-06 at 22:31 +0530, Akshay Pushparaj via Postfix-users wrote: > I would like to know if i can configure postfix to forward mails if > user not found in local recipient table. > > Usecase: > > Users are split between LDAP in my server and a remote server for > example.com. So if u...@example.com is not present in LDAP it must > forward to remote server. My questions would be: 1. How much control do you have over the remote server? 2. Is the remote server using LDAP to identify users too? 3. If you have little to no control and LDAP is not being used, then how co-operative are the administrators of the remote server? In that case that 1 and 2 are true then slave the remote LDAP into a separate directory on your local server and adjust the postfix configuration to take it into account accordingly. Other than that if you can get a valid list of delivery addresses from the remote server scripting a solution to turn it into a valid map for forwarding is relatively easy. If the administrators of the remote host are not being helpful, and wanting you to split the hosting of addresses for a domain you can either convince them to become helpful, or hand the the entire domain to them. I will admit that at a previous employer I had problems getting some of the other sysadmins to accept that with the postfix/dovecot/ldap setup we had we could have mail delivered to specific office servers (we had one mail server in the head office that everyone, including offices in foreign locations, accessed via IMAP - we frequently got complaints from overseas that email access was "slow". My argument was that local delivery of their email would fix this and could be done via existing VPN tunnels we had - some people mistook that as local storage with remote dovecot using NFS to access mail stores). - -- Nikolai Lusan Email: niko...@lusan.id.au -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMxaUACgkQ4ZaDRV2V L6Sp2g//dpIlHe9Ns6bnDIKHtzUyETlbIaBKa7sWig0lL3kJjQm2I8dtV47ObVve +RDWnELgRGSlXmzUrKKClgifqHotK9XuBdzhQgknxAMjJDirCWJxTYgWmXhiE8TW vnMty3D0yiHCOZsvuoBT5T5poWeysK5OHzvkoEXRl7KSyw+0/uwvocERwRw0bc98 JO4ludmvHwXw/YlcWLF7D2FwSE483pG0QZhWlU/A/g1rGrHPAy8NyYSi+ikQvB12 lOoQVbfS+3rFTn1y4vH0GJ5h6cNqPkm6l9bKfa4ghZ/Xhm5oURTiuLkn5MtRTtiv EFMNTQICOYbM9HvfmUmVRwAWnXKDQh8TojBgVwx+KGox4rXWXTnEWdBF/fLVWlOU VL4PjiryvOBji2aySt9KRh3FJ4FMm1JvQum8XAcj6X3ribbOQEmJMKeqMms3HkaI bOyuCowD3WGjzBJvZkkhl0lJKzDgvcppXtHXPU2qtiOdDVNwsXt2JExlIzVw7tch 0QRSB0EDopkj2H6D5dbMasprMSReyYqaMVIfng1YUljFZ99EdZEJcRede291qG3y uAg4GhKjN96UrsjaxhtEpmFR9y8lC85owX1o8R5B3sLuSIq2IDi1ak5hdC9MGIZg GSepC+SmZ+ET2vyiJJqW7c8ol8nXY+kSPpSiFFl/wsRQKl49Kzc= =fo1T -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2024-02-13 at 18:32 +0100, Geert Hendrickx via Postfix-users wrote: > On Tue, Feb 13, 2024 at 12:23:32 -0500, Wietse Venema via Postfix- > users wrote: > > - masquerade_domains complicates table-driven address validation. > > Log a deprecation warning with compatibility_levels>=3.9. > > > What's the alternative for masquerade_domains ? FWIW I use multi-master LDAP with a bunch of virtual transport and relay records in main.cf. This also has the benefit that my MX hosts can authenticate users and allow them to send email out via that route in the event of the main [submission] host being down. The solution may not be for everyone, but has worked for me in a number of scenarios - even one where the actual mail server was "hidden" (the bosses term, not mine) behind a couple of layers of MX and was (I'm not going to name names) a particular "collaboration suite" that was a java web frontend with a combination of different FOSS tools underneath - the ones that were of use to me were openldap, postfix, dovecot, and mysql/maraidb. This allowed us to extract lists of valid domains, and email addresses to let through the remote MX's (both in and out) - all we had to do was run a small script once an hour to get those lists, and if they had changed push them out to the MX hosts. This solution was _almost_ as good as having either multi-master or slave nodes for LDAP (or a database server if that is you weapon of choice). Distributing your data like this can be good for redundancy purposes as well (being able to dump and backup a database, ldap directory, or even just text lists in multiple locations can save your bacon when things get rough), it can also make it easier for failover and faster for passing through only legitimate mail. Three of the documentation pages with either relevant information, or config directives that can help with this are: https://www.postfix.com/SMTPD_ACCESS_README.html https://www.postfix.com/VIRTUAL_README.html https://www.postfix.com/SMTPD_POLICY_README.html And if that's not enough just start reading the page with _all_ the configuration directive and figure out what you need - -- Nikolai Lusan Email: niko...@lusan.id.au -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMvx8ACgkQ4ZaDRV2V L6RgOQ//bzBsmvF8G/lxIfhUhZ/tBlWv0kHpeYnUzizj93R9P6ODfv3UjTm+gYH1 RlCe0zbeQ+rbnx7H4jTJRnp1Uy9R8zhw+RVj3zPtFEQYXAc+iN45P6GeZh6K+a6q /v3Qw5G18qHJ5fFOmo2ojMNl/s9hjecuaMUwLRrFrf93JlQkBERTctKiSWRAv5eq /WaicL/hlpk+U1cwFrWTcxoAaZ+DTBrBmBZVG5zpRY/s2vvhx+wbY7rRAViirmM2 6kqIOwEmNOuxYNd7yFMQEQS2DRNkfmX8XjrN/XW5Il+Z0aS4TyswNderc/KLR/rg Zs2RiCKot8l/9Pr1vBxPbYBGu4D074mJTOGicOodYeQC6BhA1QFbAh5TzkQxnuJ1 vqC+2lHkD4eyVogvLPfkrI6xU5Birn/Fh/G5xCER3fWq0Ae1SVksakriBCOMSw02 izrd0Ehdh5BSxjiHc2ixVR7uSOjNu6l8OgNBntw8PnXiwvcTUVOyPKelYIsGT6u0 7kOe81I+E9qm1wa8tg4HRoB7+sMLpsxqbhDNAW3x0DzsW7vbkcDtt2slxiwzDcRT CH0EGAInFZeLh2weoLalNDcpp5QCAz4GzOyxfjmtS7WMfuJghtpmBO7ar0CqvZQC nVKxIeaSWJsVxbu/AkFLZajuR1scjyBP5rmXdmWBN47YyoENJO8= =4/pO -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Server etiquette
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2024-02-14 at 07:52 -0500, John Hill via Postfix-users wrote: > I used an access list to redirect all email from them to a spam > folder. Elegant solution, of this I approve. > Turns out I was asked to block the emails users had subscribed to. By the users, or a "higher" power, also depending on _what_ they had willingly subscribe to drives this into what is, for me, and ethical grey area. The who and what of each case need to be right - unless there is prior policy that users have agreed to allowing you to take such action. > I broke my rule of never unsubscribing email and did each one. If there was no other option sometimes we do have to set aside our ethics, and hope it's a one time, or limited, situation. I hope you can convince the powers that be to change policies applied to end users to that you don't end up in a bid like that frequently. > To my surprise they went away. The users? or the attacks? - in my mind either is a win - -- Nikolai Lusan Email: niko...@lusan.id.au -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMwP0ACgkQ4ZaDRV2V L6SMzQ/8Ctt4OtOkfSXyUt9TBXtIi2kbvg5WJeLcavHsmh6xjNwu7UulNrRSDGNv u59A8wOYFvH/m75RhBG5t1qzVZUEOsW3ujy4PY4dhHj1i7+H0cHq4tDmu92PYHKi OhB8tS9Nie+qAkEz6K1yGRnFp0CYVso63AjKJpE8HDBksCbRPofbyzs6WmN5zmRy IJxlnGHFOzh+VwUKaogzGfPk8KbV98e5n5qtlCdX3xJoD26n6LlS+0tIDMOk0JDo HB3O/j42FUktXLVhAzSCy2LfGa9lODoJTUV6TJvyAppBjQ7c/mz/csJuZh3OwaYn Grr+jPrWVC/xBvYzfxviFw/0s4FV0O8Hds47uV+jNqYF2Qv+eMRsf0LSTYsK2/XO egTKuh9MQQ/8SKrovr8OpsWuHJueca5qvNT9W7B6xEBBYMfEAIaK2AexJyf0xg67 +MPRJ1m2glXxBtCfwkmu7UJjB6SNaQv2rglEEpRCXFwmH54jdnzrtiMDSZ/CEC0z K8FKmALVKawYYzeik11l8897zTlWZY4+UBbrTTcgiokjofyYrj8qvXinNIK/YNrn mq55wY7OjqX0ZNuG3A/6vpsrWbrjYYc9YIRzNfOQbCudOLq8RfRLT4AJBgwkWsp3 0AzPigu0ckeK/TSFa9l1skSK53jlqV0HL1G4MnGei4WW0/1+vBQ= =Ojzl -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Unexpected behavior of regexp table in check_sender_access directive
Jakob Cornell via Postfix-users: > Hi Wietse, > > > I can add a debug log that a specific table is skipped for a specific name. > > Ah yes, that's a better fix. That would take care of my confusion with the > logging. > > Do you have any thoughts on postconf(5) describing partial key > lookups in the descriptions for check_*_access without mention of > the indexed table type limitation? There are a dozen or more check_*_access features. Their descriptions all link to the access(5) manpage that describes the table lookups. Having 12x that text in the postconf masnpage would not help. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Server etiquette
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2024-02-14 at 11:34 +0100, Matus UHLAR - fantomas via Postfix- users wrote: > > On Wed, 2024-02-07 at 12:15 -0500, Viktor Dukhovni via Postfix-users > > wrote: > > > I prefer to have logs that record what I'm blocking. With > > > firewall > > > rules there's not sufficient forensic evidence left behind. > > On 14.02.24 19:11, Nikolai Lusan via Postfix-users wrote: > > Here's a tip - try the 'LOG' target before you DROP/DENY/REJECT (I > > prefer REJECT with an ICMP host/port unreachable for _all_ ports on > > my > > side of the link). > > Unfortunately it only provides IP you have banned, not from/to mail > addresses. Depending on how convoluted a setup you want you could potentially drop in some tcpdump scans targeted at submission/smtp for the IP's in question - I'm not saying it's an easy fix, but it may just give you the information you want ... the packets are there in the network stack it's just what you do with them before you assign an iptables/nftables action to them. There is a whole heap of power in the network stack, and how/where you can route things to mess with them before a firewalling decision is made (granted this has to be done on the mail host, and you have to have the resources there to deal with it - potentially having a couple of equally weighted MX servers could spread the load and get the job done rather than adding extra RAM/CPU to an existing mail host or MX). > However I also implemented it because of too many attacks on servers.. Having been a sysadmin around the traps since the mid-to-late 1990's I have seen many an attack on servers - it comes with the territory, you run a service and some goon is going to try and exploit it. For example no matter how securely you configure an ssh server you are going to see people running distributed attacks trying to login as root (and a whole heap of other usernames - I find my ssh [attempted] auth logs to be a source of amusement, sometimes, when I'm not getting all "I'm going to track you down and stab you in "interesting" ways . Submission and IMAPS services have become another one of these things (most of the SMTP attacks are boring and easily dealt with using basic one line scripts) but I have found a decent set of fail2ban regexes with a low threshold for failure and a long ban time severely reduces the volume of these attacks, and a permanent "throw the packets on the floor" approach for repeat offenders doesn't hurt either. We all get attacks, I have only had one instance where a SYN attack actually rendered a server unusable (it was a web server and because of commercial arrangements I couldn't kill it at and edge router) - admittedly it was an HTTP[S] server, the code being used for the attack was lifted directly from a java text book, and the attacker was using his home connection to do this - suffices to say a reboot into the remote rescue console allowed me to make the server usable for legitimate clients in a short period of time, and reporting to the ISP (plus a little spite on my part) made the outcome for the little punk not so great. One thing nobody has addressed is reporting to the upstream providers for these attackers. WHOIS is a wonderful tool, and so is traceroute and it's variants, get the information contact the ISP/hosting company and/or it's upstream providers and hint a some reporting to SORBS or other blacklisting sites and you might just get them shutdown outside your network. Nobody wants to have to jump through the hoops to get off a blacklist. Also (unless you want the connections made to your hosts) having your upstream potentially block IP's at it's edge routers might have the desired effect (note I am only talking about connections made from specific IP's the you know to be carrying only attack payloads - if it is shared hosting then contacting the operator of the shared host will probably get you the outcome you want ... I know I have been on the receiving end of this, I was admining a hosting company that allowed "walk-up" hosting and someone chose a Friday evening to sign up with their own domain to the CPANEL machine and proceed to spam the shite out of things for about 2 days until something hit our support ticketing system that alerted us to this, at which point we killed the account and set about trying to restore the reputation of our IP because not to do so would have killed a heap of legitimate business for us). Running any kind of service on the open internet is going to invite some level of attacks, it's why we do internal security (I met Wietse at a security conference almost 20 years ago). But security is an ongoing process, and if you get targeted by the "wrong" people you may need to take extreme measures to keep your service running - even if it means you can't collect all the data on the attack you would like to have. The best you can do is keep evolving the measures you use to reject attacks, hope that the hosts
[pfx] Re: Server etiquette
On 2/14/24 4:18 AM, Nikolai Lusan via Postfix-users wrote: On Wed, 2024-02-07 at 10:51 -0500, Phil Stracchino via Postfix-users wrote: > On 2/7/24 10:41, John Hill via Postfix-users wrote: >> Good info. >> >> This site sends nothing but junk. IN fact the domain is known for >> it. >> I tried just rejecting the email address. But they just change it. >> So I blocked the IP, they have several. > Have you considered blocking the *domain* with a 50x error (permanent > fail)? Amen. My blocklist contains a mix of domains and individual addresses (predominately gmail/outlook/hotmail/yahoo). Blocking the whole domain can be more effective than blocking the individual addresses (which can theoretically be a long list). Unless you have certain email addresses from that domain you _need_ to receive mail from either whitelist just the addresses you know are legit and block the domain (assuming there is more than one address sending spam/virus/garbage). Or you could go down the path most MS hosted domains do, and send everything to SPAM folders unless the address/domain is in someones contact list (probably means writing a filter that can communicate with a CardDAV server). I used an access list to redirect all email from them to a spam folder. Turns out I was asked to block the emails users had subscribed to. I broke my rule of never unsubscribing email and did each one. To my surprise they went away. The redirect access list is a great tool I will use often. --john ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Server etiquette
On Wed, 2024-02-07 at 12:15 -0500, Viktor Dukhovni via Postfix-users wrote: I prefer to have logs that record what I'm blocking. With firewall rules there's not sufficient forensic evidence left behind. On 14.02.24 19:11, Nikolai Lusan via Postfix-users wrote: Here's a tip - try the 'LOG' target before you DROP/DENY/REJECT (I prefer REJECT with an ICMP host/port unreachable for _all_ ports on my side of the link). Unfortunately it only provides IP you have banned, not from/to mail addresses. However I also implemented it because of too many attacks on servers... -- 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. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Server etiquette
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2024-02-07 at 10:51 -0500, Phil Stracchino via Postfix-users wrote: > On 2/7/24 10:41, John Hill via Postfix-users wrote: > > Good info. > > > > This site sends nothing but junk. IN fact the domain is known for > > it. > > I tried just rejecting the email address. But they just change it. > > So I blocked the IP, they have several. > > Have you considered blocking the *domain* with a 50x error (permanent > fail)? Amen. My blocklist contains a mix of domains and individual addresses (predominately gmail/outlook/hotmail/yahoo). Blocking the whole domain can be more effective than blocking the individual addresses (which can theoretically be a long list). Unless you have certain email addresses from that domain you _need_ to receive mail from either whitelist just the addresses you know are legit and block the domain (assuming there is more than one address sending spam/virus/garbage). Or you could go down the path most MS hosted domains do, and send everything to SPAM folders unless the address/domain is in someones contact list (probably means writing a filter that can communicate with a CardDAV server). - -- Nikolai Lusan Email: niko...@lusan.id.au -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMhXEACgkQ4ZaDRV2V L6Tueg//TMRq7T1Fary3UgPWEwMdoCvK8rlzUmZUzYv34i6iLIwboNJxgrTwbChJ FA5wDTteHtfyLW1P2P4csnCLy7X0NjhAL9XCQ1DyDgwfRYZxwESDu7kz/W7aLcIh xacUfhJ84s44/VD4QyJ+F642QEiJw6nBNCtwE7pBUwHJYBfv/AxnhYvh9v5c5tjW fwjQVXBzzXMnKWQGt31p9jCLF7yUVudBcihD0knmwubHOptXojg1fsw/RltjSY8q AkwuwjbOmjeOxGRo6q7a89MjLkmIzRQAZED+BVrHt3Quy73cGYieRkw6KEgszS0R 4zOmEmnaueLY6cB0RdhpQUynL9QEhW3RTYXrdJHYAktkpfF11K/U+GWGh33u0qqo n2KHkWDHfIZidU2BpZeJJfR2NT/7dIL9AUh0LYqHrt5MehkvIBHf+ohwWEKLd86v HMmDs2b0YodeDxppArSk850AEC9klqPAnhXmJwpEjjI2tP+7M7jHwQOe4kdFHKLy z4dTE5UehnVN0NogxYxMpwddJK6YSbv3Vc9f8GVsAntz+D/SDN2J9/KEmMZduRPb iQRRLgv9oHVjsdIerCG3dklCU0ucmrJGN+Y6gULZzZRDZerIrOQyJztm/xHPNulh fo0Ywv6Asdea1Tm2hlpmaJLig61yemPyyCNn/I/+32VnKsMyAws= =d9RU -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Server etiquette
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2024-02-07 at 12:15 -0500, Viktor Dukhovni via Postfix-users wrote: > On Wed, Feb 07, 2024 at 11:21:10AM -0500, John Hill via Postfix-users > wrote: > > > I use fail2ban as well. I'm just going to see if the sender sever > > will give > > up! In most cases this thread is dealing with that is a pipe dream, these people are determined to get their spam through - multiple IP's, multiple domains, and if the get blacklisted in one hosting location they simple move to the next hosting company that will let them transfer a domain with just a credit card payment. > I prefer to have logs that record what I'm blocking. With firewall > rules there's not sufficient forensic evidence left behind. Here's a tip - try the 'LOG' target before you DROP/DENY/REJECT (I prefer REJECT with an ICMP host/port unreachable for _all_ ports on my side of the link). - -- Nikolai Lusan Email: niko...@lusan.id.au -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmXMg98ACgkQ4ZaDRV2V L6TCmA/8DPfKVskn6Cq8k2Da0U/e2JIOgzJgiBdwmNbIyi1J+fJjw3BL2vqp03RH hzcGDt9Kwto4O4hPCwgGFi/7wNWl+rTqVEtCC6DMWr4l4spZ4ldoNEuwb9BL/mEU JCpP1JuSxORYy8jkF2bdhNPf2ZoWasyVRZxMp0ov97cGAHN6Ka2G0VTnAGNIMOCO AHhBy0u7XNZQN9b8JW1A2VSu8G0MeEJd3h8ubzgmm9pR813SSdIoe3zMpxuoJp/C 8sIqalI0GAEfe4Wqb/KT7cPHGJQR5mCjDjmJsds69H58VV4xK6MkSlto5uDZtDws Tu1XCVKnPLGtlmZOK+4yCZudwLc/3j9zp5hCz4jUYZj7n447OdIn+47Yt5tReF21 7Uu02V6Py+WX2dPMFlR3QO67TmYXpEXcN1ZNxBkJXdbVEHGQtRbs4wlWnSCRDexd qjk04i83wjjl8/wcV9VC92LRkzlqSkhUOwQ6X3bmjfOmjPWwMV3GJR13/SfUm9Zp +8k8eJUp9chiAJxFNotXG0G4/erWUYOT6+WLe7TW0fj6b8sOque1WRzLg+t3nwkw e99Fb6Z5NZ9gcCX1UsruAAXOl+sSQ+pLSyLxlKaxHsD/0w1c56fV089WDyxbC1QT sgKVvMMm6lU/PQjiMkeKIBWHj87lGVvp13jhMiBSf7E1hK8MU+M= =gpOM -END PGP SIGNATURE- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
> On 14. Feb 2024, at 09:23, Geert Hendrickx via Postfix-users > wrote: > >> Of course it is best dealt with at the source by configuring the >> client systems to use the correct domain. > > > Perhaps, but not all client systems are under our control (trusted but not > necessarily cooperative), and it is convenient to manage the (evolving) > mail policy in a central place, rather than on a large number of variour > client systems. (and even there, a single masquerade_domains setting would > be handier than an explicit canonical_maps). Having just introduced ‘masquerade_domains’, I can not agree more, “trusted but not necessarily cooperative” is a beautiful way to put it ;) ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: What features to deprecate
On Tue, Feb 13, 2024 at 12:51:51 -0500, Viktor Dukhovni via Postfix-users wrote: > On Tue, Feb 13, 2024 at 06:32:14PM +0100, Geert Hendrickx via Postfix-users > wrote: > > What's the alternative for masquerade_domains ? > > It is canonical_maps, ideally with explicit mappings for each expected > non-canonical address. For an outbound-only Postfix relay or submission > instance, the canonical mapping could use wildcards or regular > expression mappings. Though in the same context (no inbound mail) the > use of "masquerade_domains" has little down-side. Yes, we use masquerade_domains on an outbound mail relay for a large group of internal servers (typically sending cron mail or other automated reports, so no inbound mail). This was/is the classical case for masquerade_domains? We rewrite only envelope_sender from user@host.domain to user@domain for SPF compliance (not needing an SPF record for each individual hostname). The From header is left alone, as it is DMARC aligned. Achieving the same with canonical_maps would require regular expressions, as there is no catch-all ".domain" support in canonical(5) ? > Of course it is best dealt with at the source by configuring the > client systems to use the correct domain. Perhaps, but not all client systems are under our control (trusted but not necessarily cooperative), and it is convenient to manage the (evolving) mail policy in a central place, rather than on a large number of variour client systems. (and even there, a single masquerade_domains setting would be handier than an explicit canonical_maps). Geert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
