[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: 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 a
[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
Re: how to deal with t-online's blocking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, 2022-11-30 at 13:15 +0100, Jaroslaw Rafa wrote: > From the discussion on that list it turns out, that the condition > under > which they consider a server to be "commercial" is to provide so > called > "imprint" on the website associated with the domain, with full contact > details (your name, street address and telephone number!). After you > request > that they unblock your IP, they check manually for existence of that > "imprint", and if it satisfies their requirements, they'll unblock > you. My question is: How do they deal with non-european entities who do not have such legal impediments in their jurisdiction? Also what exact check are they running? Do they verify the addresses and phone numbers at all?I am pretty sure most Australian companies would fail to meet this criteria (for example I just look at the Telstra - https://www.telstra.com.au - website and I can't see where Australias largest telecommunications operator fails this test, and I'd hate to think of the number of Telstra customers that would fail to send email to these mail servers (most of who would get belligerent at bounced email). I know that I don't want to, and am not required to, provide that information for any of my domains, or domains that I host for other entities. This just highlights the problems with internet, and general IT, related legislation/regulation. Another example of a problematic issue is a requirement by the Australian government for anyone working on products that use encryption to insert a backdoor that law enforcement can activate if requested - a requirement that after legislated saw many Australian companies offshore work. - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmOHXaEACgkQ4ZaDRV2V L6Q3Qg/+OzWVAVBCZrS0SmvLm0cYQHvVnFf35ucIs8PzZ+vGtoc59iZjw+dbo8/p ZpEV4sY/jdI4d//owTTJgpNLpEwcnrmk6X6yAno2TBqqB0OURJJ/ueIRpPtkuUlW YB0Dv3qJwS5oRW1t0572W5xSDz6A+AYA1WYhD/TTMftQnBzlPOcDTqVjWKxxy6bg jCgLyLuZFSXZlxW5g2TNVnqVk3P3E9h1FPqNYRP75oIPKbcqIZG4wxmqFBJuMs+n pR6g3tpx+BMzGHbPxS/PVZiC8+hFjnE32Lw5U/MidU4fsUPai6KkcEJaWO+6g6sn Mdm+k+yhczqYkd3lBYZBtSB7+6Q7r0pTKtpudjvfmsTmHedossxSCkjc0XT/kaaE +SKF4yMYMAlC1QB4l3IBfdrD37EaZ5UpAAAIGEP++S9fqBB4rMLLnOQDOQnOSGk3 KLPYTZ8ebQ+M3XiMDEpKEUQuDMvimOrJ1DB0flM13l6senXUV1pHZadovo6t+gfv 0zBcaf3JWIO1/wFae5voB9jnRfWytxZYA03lGShj2ZYOYxOMpgGeNDWLPEbbhJdR fuTXrXs9Bqg6MnayPE9E9YvZZPOaCRXleXOtFYXvSM6f0BDyEAeA0tDacbIZHDW/ 4xeSHHCqyHv76J7V0vnEkgNocsd1sjmIpcgbT2Hapz/GBZlqabI= =hL0i -END PGP SIGNATURE-
Re: unexpected: postfix tls deploy-server-cert + smtpd_tls_chain_files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey, On Wed, 2022-03-30 at 17:35 +1100, raf wrote: > > Postfix picks up new certificates soon enough > (controlled by the max_idle and max_use parameters). > > Did you have smtpd_tls_chain_files set to an old > key/cert, as well as smtpd_tls_cert_file and > smtpd_tls_key_file set to the updated ones? Was that > the cause? The process I use to update my certificates uses rsync to overwrite the old certs/keys with the new ones. My thought process initially was that restarting postfix would have it pick up the new files - eventually by inspecting the relevant hash files I found copies of old certs in them ... hence rebuilding the hash files on update. - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmJFv1kACgkQ4ZaDRV2V L6TrkRAAlSg1rsudX3ctj+/kYp0izWVG/xCXZNSDAdJohOIb2ZM5waadp/DWdorb QtPGOOrE4HMCjvZsFRgLiHu0VEIx3HriHrn+j7SDHAoSSI3z0WmwU1gu/ZL86S9U QSeaRsXbqaxdfDWncjDySakfssrfEXokgHCTso/PCg5HBC4Uvfcl49DXSrkixXPB dn9WVAb8fukBY3m0Xb4qEskYd6Bm8rIDvphDZhSUPQY8Ach54QjFomMmq9xFnRNS bOWt23nmvawFAsKqkj6eHv//oTLwVomjronLf4PydDyZc3yHPK21zmYulk75QfUa kRnOT5ot1y8DjwMeBrcyguuFVpCVR4ZgtfaPB8yJVAidDfr943qSGqIGFksQOoDf wkfcLhEC8bQbjmg7NCei8kjYZiP0AjlsYrM97FqL8S4hP+MGTso2p+oLVT2dMBaH gVbNpnzMRkGOWoNeCNP5huDMIAsH9j656AZLJEuMQ0nDJV7bwuyZ0SQCEhQhGh/Z g6k7UX+R80QyXyiOK9DL1+3C3fMh6zBk8vyzd3qMDbuqnCQIm8olCkKeDgFyTaYC 1mRGemCuT3Ss2j8stvI/RgEutQMCG6trlc3oS7BQp0+GBcdCCEfRce/hWkamZ3xY tLdtsbTJzYbkaSHpA+OpQwh0r9JYg9HqL9qsBkNZjVyqWFQfm8U= =dAy9 -END PGP SIGNATURE-
Re: unexpected: postfix tls deploy-server-cert + smtpd_tls_chain_files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Just going to say I banged my head against this wall for months on end - every time I updated certificates (using letsencrypt it's pretty frequent) postfix showed the new certs as active - but external tests still showed certs from over a year ago. On Mon, 2022-03-28 at 15:23 +1100, raf wrote: > I just tried this (debian-11, postfix-3.5.6) > and was surprised by the effect: > > postfix tls new-server-key > postfix tls deploy-server-cert /etc/postfix/cert-20220328-033631.pem > /etc/postfix/key-20220328-033631.pem > > The main.cf file originally contained: > > smtpd_tls_chain_files = > /etc/postfix/smtpd.key > /etc/postfix/smtpd.cert > > The deploy-server-cert subcommand appended the following: > > smtpd_tls_cert_file = /etc/postfix/cert-20220328-033631.pem > smtpd_tls_key_file = /etc/postfix/key-20220328-033631.pem > > I expected it to notice that smtpd_tls_chain_files was set, > and instead of changing main.cf, just output what I need to > change. So my solution to the problem is to store all the tls certificate and key information in one file (in my case vmail_ssl.map) that file gets mapped with postmap. When new keys or certs get deployed I delete the vmail_ssl.map.db file, regenerate it with postmap, and then restart postfix. (I is worth noting that I host multiple domains and use SNI - so this solution may not be for you.) - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmJC+XkACgkQ4ZaDRV2V L6QxOQ//WEJZl4xAnNux29PLIs/oSm8g7qQxb44Hmjpqc0r2WbMegl7T8WKdJFBw g7S9gEEiFTR7tTgGxBJYIZaq/Cyq8Sc57mzmLg5VtK/OLyFL3cwJzf2hiA11SLkQ 90PdwBO6PHaqf7tLxNzih9c99U86vWMKBFGuP/XyZ3G+cAKeIsNADp25RTbKkmFk h3o+hGWiX9omORXLsPkX4tUHhP87rE5CCokDMkmueRTDgMK/YJzctOiSgFlVOhWv GLwS2SViDaxakiq4G1vNoQlQXxCsVuNm6EKmbCdeJdY1UFoDxAaHdiU9PL14BDSS ZxKFQ4F2Cj24uLSpXIeItzDBgXICigUHLI3Ex0bnqyczgBon/5PKS+/nqIoKEqAu tspDcG2raOu6ZDAycOvSxMR7RdCwRg/RGx1E35vjCByboWJzOyY1aVlif3zoFkUL vppZQkaKAlVb5Ne6wH0iSGPR0H/OOx4k3AKonQtLTKOXhubKTbohIicnuTZiiRWK NTurgc+VlFY8OfWXL1dUTu7FUEzEwMLj8zfXqMjSapWMwO7sFO7YU9HQKprM+erw XehEdUAVz09U6hbl4uwB3bi1mg9MF6KKLcOiPiYcehr0DGBZbldqmANuD3rYAVEk k2+Xorng0FIGyzfjdDwFo2uQkbC6k7FdAFjXXRUFbl7Cd696HOY= =m7ot -END PGP SIGNATURE-
Re: Why the name Postfix?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hey, On Sun, 2022-03-27 at 10:59 +0200, Benny Pedersen wrote: > funny from myside: it fixes all known sendmail bugs :) > it did not take m4 configure from it How plebeian, you used m4 to configure sendmail. ️ In all my years administering sendmail I never got around to using m4 - I just found the directives I needed and put them in proper places, worked quite well for me and gave me a greater understanding of how sendmail functioned. That said it was still better than when I was forced to use Qmail, but not as good as when I transitioned to Postfix. - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmJC9vAACgkQ4ZaDRV2V L6QuZBAAj7WVOh5wA8ZWRX4FcrtJLR487ofUZX0/JTqOKe9AuRN+naCPlPcaPooG jH6BTQ1EuFptzPyEUb3T401yX2q9/6UOyPCFnGF8X2R00eXcAb9FVri4b3okotHq WIiEwWXsDlzSSJsJqEWSj87QMhbZ0lcnwKB+0CwwjcQmAeyMOXYN+SI0824ihbl9 P4SKLhkIi0SlXmEnZ/YVK+fRfNmilh1JGaTGxN3SlVvMzQQQ8EhZC23bdd8nzm7Z wmJkDb+t5AQwqrYSh5CoS09XHlOhtDu7ORZkkcSIB2FTzx0JWZPDpD6hrXAfcggN YYvzIEgPDf47zA1IDyxLSbpC9fT16PI6qZOfsrLrKbVV4/BwGOUJhgaAx2E2d2ZL JAAvcW6s7m4Td+vCdryziyivEuXSushfLZiqoGN8/OinTatbgkIW7k64fxhVZjvF A++Sq8/ITb/Hz+55zf+Ik8SFyrb0/7ww3TV7jki242tdc7beOWSGndWR9xDLJ0DF TmRJ5XwIlQXmY09ZuhJoHkhDQ54c7sx/AlhsFT8ijff+yanfVsguSkToPUC/dgyE e9E3S8D1x8R9utB2gs2u37X3TV0V+XwSSc/rdsXF+xPMDnzstEgUYgr/iQ/z4gCg sY8ZIZQuwB/1SnkuoxOHOHPNhfo/L84ohXy3nUzmsbk6EDfRaOE= =YjU8 -END PGP SIGNATURE-
Re: Why the name Postfix?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2022-03-27 at 09:08 +0530, Amarjeet Anand wrote: > What’s the story behind choosing the name as “Postfix”? As with all children it's what it's parents chose to call it - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAmJC9Z0ACgkQ4ZaDRV2V L6RpVhAAlG1+bl1zPIcR8f/8OuFtIabDVztlzlaSAco8NBP0GV5TWhvsgeap85zD h+cjhE0TejMMBt/KsybAtVyxS60X6aSaJaAo1sOUa1IOpvnT6aHka/6sTggs0o8I CDXVDXBPrGAC01YTBCarB2uytooWezmdLX8VwHaMmMRxwM+IwmHemNHM4Oh4YZWD RdQlRTht106G3X5dPBamIdKj0qRti1+plkOnp3uygDEQ5FzFKux9VM5e0rTxJtt2 mO+UfO58czUVJiEmoQzsUEdPJ+597VMBvBHW44QcOsdrPsQEf9iSpWTv63h6Zxuw iyqOO9FKt5C+lDtR4y4wCS57QSGN/neLgyJBHsm7dxnLGFMtFofPVB6QSnkvjt5p CKwTJCB/95VC4368Odin2oCu8ZSS22ctMdXmDwvFfFC6GLD4BzGZGcnty7pYcvI3 ncJ5bS8bztWTtUiL0wS6LUcgfAYygTFfbACz9+051h2eWkH9r9QzxxKoEOqwH4iV 24pR1jA2CCakLnA6+DcvcGaDKpuMdwu0NKG8Zu0YMj7fX9gazKDTp1aBPOnmSzKZ peX+K03lxK0JQmIC0RBhXlzFgrJl+TsYnbPqEJ5xPKqBuREMA8fRALUjLVp8m2NU RGugUuTGuvlIAO/Z6f1UYEWADUTuMYKRSgoqLgn/eAT4ZwqdJ/g= =keBh -END PGP SIGNATURE-
Re: lower case email address for delivery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-11-28 at 11:30 +0100, Juerg Reimann wrote: FWIW it looks like a dovecot/lda issue. Traditionally SMTP systems forced everything to be lower case ... but then people like Microsoft started making MTA's that where case sensitive for the reciever part of the email address (at the time this was not RFC complianat behaviour). A quick parsing of the current RFC's shows that for the reciever part (i.e. before the "@" symbol) it's up to the delivery agent how it handles case sensetivity, however the domain part of the address shouldn't be case sensitive. I have always run on the basis that all email addresses should be case insensetive, and that the MTA/MDA should ignore the case of any characters in any part of the address. In the case outlined below I would look more closely at your dovecot configuration than your postfix configuration. I have a similar setup, but addmittedly I haven't tried (or seen anyone try) using anything upper case in the email addresses I'm serving. But, yeah, according to the RFC's it's up to the MDA/LDA how it handle character case sensetivity :) > Interesting phenomenon on a newly setup system: > > 2020-11-28T11:15:48+01:00 localhost postfix/lmtp[98782]: [ID 197553 > mail.info] DDB5E8456: to=, > relay=my.host.tld[private/dovecot-lmtp], delay=0.04, > delays=0.02/0/0.01/0.01, dsn=5.1.1, status=bounced (host > my.host.tld[private/dovecot-lmtp] said: 550 5.1.1 > User doesn't exist: u...@domain.tld (in reply to RCPT TO command)) > 2020-11-28T11:16:01+01:00 localhost postfix/lmtp[98782]: [ID 197553 > mail.info] BF1678458: to=, relay= > my.host.tld[private/dovecot-lmtp], delay=0.26, delays=0.25/0/0/0.01, > dsn=5.1.1, status=bounced (host my.host.tld[private/dovecot-lmtp] > said: 550 5.1.1 User doesn't exist: > u...@domain.tld (in reply to RCPT TO command)) > 2020-11-28T11:26:37+01:00 localhost postfix/lmtp[99560]: [ID 197553 > mail.info] BA35E88DC: to=, > relay=my.host.tld[private/dovecot-lmtp], delay=0.16, > delays=0.08/0/0/0.08, dsn=2.0.0, status=sent (250 2.0.0 > YIesL90lwl+2hAEA0J78UA Saved) > > How can I lowercase the complete email address in postfix before > delivery? It happens like this in my case: > > virtual_transport = lmtp:unix:private/dovecot-lmtp When in doubt RTR [Read The RFC] :) - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl/DtKkACgkQ4ZaDRV2V L6TVaQ/+Jv2bekHh4igxgl6BSz0huiI0FTGOXPKZlVObKflha/8kszR8hRI8DKaR 7I2noZknNbwh93wvfYQsz8Qf45FnNzB/231UAQyetBhQg1wB5vzJugsLD2Odk+PT L7kcVOSn2KSQH96Rf6V4qQr6SOrUKhGwos8KBl/mMIvyja4aor84VaLHgES5rG3k PdOkh1XkIm3va6blipsfVQVGriRBzFAMqrNm7s/84m/mJ2Xfr6qHe75OsZDCHGgy sinvXtF9blOsLilFIqI+ZyhXGNMbnZrzG4DvooS9tycc2JygmgcVV3ugcSLfGndI ziFIT6SftnWyndhKJlBqD2R7DUNxlMB7v2AL/Tw2ldURGnZF/bt4G3erUcF8VEAU o9X4RJOOc7dTjYIGOrfDzHn99JLy5m/rbo2nkBZPYcIx4O5HuPcTVXKKYV/6s1Yu xwZyk287esRNi9mZN2v5SPT3pOXhFTCzEaGGJMjh7aQycZNXWxxzIkv9wP1p1ZEe 3TxTdkVVwNC3YRmt2/Tq4ISuWAiVpygjabD6U2YDJghFWNhaJr1M/0pn5MpP5clG Gew4Hj6AZks9XN8t4VPtCvAELeBoUMk7dg4SJQbbH5qlOGqKkk0Y7WWCxHZWo9xS d17fkruJFR7wtslRlygVfjrb2EKZxM7AKCF+dmgW3o849dNvQ+c= =XsX8 -END PGP SIGNATURE-
Re: SMTP TLS delivery fallback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-08-18 at 06:42 -0600, @lbutlr wrote: > > smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, > RC5 > smtp_tls_loglevel = 1 FWIW it is worth periodically reviewing the documentation for openssl and the ciphers it offers to maintain excluded cipher lists, and also set protocol lists. Personally I have: smtp_tls_security_level = may smtpd_tls_security_level = may smtp_tls_mandatory_ciphers = high smtpd_tls_mandatory_ciphers = high smtp_tls_note_starttls_offer = yes smtp_tls_block_early_mail_reply = yes smtpd_tls_protocols = !SSLv2, !SSLv3 !TLSv1 !TLSv1.1 TLSv1.2 TLSv1.3 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 TLSv1.2 TLSv1.3 smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, KDH, SEED, aNULL, RC4, PSD, SRP, 3DES, RC2, aDSS, IDEA, kECDH, eNULL smtpd_tls_exclude_ciphers = MD5, DES, ADH, KDH, SEED, aNULL, RC4,PSD, SRP, 3DES, RC2, aDSS, IDEA, kECDH, eNULL smtp_tls_connection_reuse = yes smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3600s smtpd_tls_always_issue_session_ids = yes smtpd_tls_eecdh_grade = auto tls_preempt_cipherlist = yes tls_daemon_random_bytes = 64 tls_random_source = dev:/dev/urandom tls_random_bytes = 64 tls_random_reseed_period = 3600s tls_random_exchange_name = /var/lib/postfix/prng_exch tls_random_prng_update_period = 3600s tls_append_default_CA = no tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:!CAMELLIA128:!AES128:!SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:!CAMELLIA128-SHA:!AES128-SHA (Some of which may also be deprecated/legacy) It's probably time I reviewed the cipherlist, but I have other things on my plate right now. - -- Nikolai Lusan Email: niko...@lusan.id.au Phone: 0425 661 620 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl89RjwACgkQ4ZaDRV2V L6SeJg/9HuehYiuG2Ebg8N46og3sJkgtzcsghr1pq3BpiABIiI3m9VKNfL+NAazl LvFbIB/9CTbKgCZKI2frnmKtBuDNoSEJ/Mdi6N8fmeRffeMzPu71UN7Kf9y7wWJE 905sEmYKLUaVy+uAj5cXRXExv7+Btv3tXEyNCK6YdHlTEslUzgRgPUYO9q/I5T88 nmGHAQY+yTPNYeP6NUo3mcL4lVNTKIbSnOhnx1aiSUApyy9i8fWgBNXl0JWYjOSO CNI7/DWD226ddT9AXh1c2LSOEc3IP5bww0eB2fCfPb48EZuA1juZFEDhx0FjCCqj zaRgEIPUEQsRCux5hQOrqUZDOuiBc7xyhlhyHoh718mmjeUh9UIJv+wnuVzYZ6s0 crFWOlR0gtMsny2oWk4JifFgu0w3so49mtRvyru0LllMZpJP4dVNucWknj9DTcQ7 iUBwsX5rj1cjYJ62GiR0OjR0d1dVn3ldjStiYo9WjDXXj6KqEcMTO04yMvxPl2G6 tcGmXJ1L1jwqo+RC+S6ixqyfDBs5rn5dv/MTwGQ7fDm8Av/I7nn7gK+LI7lMqPE2 segkXisPnnUM/0IJ2KPeDiUG9D7iMy6wiqjCiB6hjM0u8+8RxsiGrvQUx/FaQknf +kCM/LWXC6ULPn54juAqRTfOz1H8NfgV9jT9frf4KhGeq42Trzg= =pNPW -END PGP SIGNATURE-
Re: SNI problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thank you very much for finding that. I have been having the same issue for months now, and was beginning to think I might have to resort to writing a patch to the SNI code which was seemingly not inspecting deep enough into the certificates (i.e. if you had more than one hostname in the TLS cert - as in the case of a letsencrypt wildcard cert - only first name was being matched). Turns out I was wrong, but I hadn't had the time to sit down and properly debug the issue. I had the "smtpd_tls_eecdh_grade" set to "strong", after removing it from the main.cf file and letting it default I can verify that the starttls sni all works on my servers. On Tue, 2020-06-09 at 19:22 -0400, Viktor Dukhovni wrote: > > On Jun 9, 2020, at 1:07 PM, Viktor Dukhovni > > wrote: > > > > > May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index > > > 1 in SNI data for smtp.myserver.eu does not match next certificate > > > May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library > > > problem: error:1426D121:SSL routines:ssl_set_cert_and_key:not > > > replacing certificate:../ssl/ssl_rsa.c:1107: > > > > The second message is the real problem, OpenSSL believes it already has > > a certificate loaded for that algorithm, which should not be the case. > > The new key then does not match the already installed certificate. But > > there shouldn't be one already loaded. > > Amazingly enough the issue seems to be caused by an obsolete, and > seemingly unrelated setting in the OP's main.cf file: > > smtpd_tls_eecdh_grade = ultra > > This predates support for automatic negotiated EC curve selection > in OpenSSL, and is now just a bad idea. The default "auto" setting > is the only correct one to use. That said, how this breaks loading > of RSA certificate chains is rather a deep mystery I shall pursue > with the OpenSSL team. > > The OP also has other excessive fine-tuning of the TLS stack that > is somewhat counter-productive. > > * 4096 bit RSA cert > * TLS 1.0 disabled > * Overly specific cipherlist > * ... > > For SMTP, try to have modest, but broadly interoperable expectations > of security that raise the ceiling rather than the floor. > > https://tools.ietf.org/rfc7435 > - -- Nikolai Lusan -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl7jnRAACgkQ4ZaDRV2V L6QovQ/9GhBj69ncJVApi6vKtGUvY5lxe/Epff5knj49LTh1c+s1gN3VWMowvYwz hmXkZQeeA5s/5m1Lp3W+3ZAeyIjoGqP4MQNfrNjQB+HtK6sdq/eVD55saRBAn8Lx mIRCmfvEK0HeojL2PEVpW3SI/39Hzs9DqyNkFBu4l1d8x1GFf2abSgewBBGye9Zo J+nORi6Hf1jBHCj/euuFGrr5N1nSNKq/lpP4bGXJxTKH0nwEEazIAhp+C8xdbgry UOZyLJvmuwMIQk/MUb7q4NU/XdjLW95GAugkg+8pFdcdkF08c+TO2ARwNuJPzQRm XNgd+VyV8uhrP4+DoVc0aL+76tmSu3lchap8HYLSxq+H+WhgOdKTCrBsQl1rw9od vUJ62BqI9a/7lskYu6yT1tjhgGjle4S8stDXln1efKQfTLuX/q17xqjLR0RRCHod gaoDERDsYJAOriMlG3KzTO96kTDNtqJT41LPIG188XUb6zQ9r+0vpoyU65HKugNx Lv0HApEsvEo25BIWSsMbTALX2mr62IJQ7K3AqyafZYDGdg+H06aOhBj5dQRlr6QF 0Pys7yp4KMJoy/kqwanQI9Rd1EtDW5+L97qyARmqtQ2TdOmxOL8ayte5spF/c9Ks 4SWCcMMFifSJ34xfZ48nwtZCampOAM/3aHlb3LweN+FB6bQaaIA= =o4N+ -END PGP SIGNATURE-
SNI and Letsencrypt wildcards.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I am having some issues getting SNI working with postfix >3.4 with errors like: Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: connect from localhost[127.0.0.1] Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: warning: key at index 1 in SNI data for mx1.city8ball.org.au does not match next certificate Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: warning: TLS library problem: error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing certificate:../ssl/ssl_rsa.c:1107: Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: warning: error loading private keys and certificates from: SNI data for mx1.city8ball.org.au: aborting TLS handshake Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: SSL_accept error from localhost[127.0.0.1]: -1 Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: warning: TLS library problem: error:1422E0EA:SSL routines:final_server_name:callback failed:../ssl/statem/extensions.c:1007: Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: lost connection after STARTTLS from localhost[127.0.0.1] Feb 7 15:43:08 lutsk postfix/smtpd[4041166]: disconnect from localhost[127.0.0.1] ehlo=1 starttls=0/1 commands=1/2 The certificate file is a wildcard certificate issued by letsencrypt. The following are the pertinent fields from the x509 output of the certificate: Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 Subject: CN = city8ball.org.au X509v3 Subject Alternative Name: DNS:*.city8ball.org.au, DNS:city8ball.org.au These files work with apache, nginx, and dovecot for SNI. Really not sure why I can't get it working with postfix. - From "postconf -n": smtp_tls_mandatory_ciphers = high smtp_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtpd_helo_required = yes smtpd_tls_always_issue_session_ids = yes smtpd_tls_chain_files = /etc/ssl/letsencrypt/lusan.id.au/lusan.id.au.key /etc/ssl/letsencrypt/lusan.id.au/fullchain.cer smtpd_tls_eecdh_grade = strong smtpd_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache tls_append_default_CA = no tls_daemon_random_bytes = 64 tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:!CAMELLIA128:!AES128:!SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:!CAMELLIA128-SHA:!AES128-SHA tls_preempt_cipherlist = yes tls_random_bytes = 64 tls_random_exchange_name = /var/lib/postfix/prng_exch tls_random_prng_update_period = 3600s tls_random_reseed_period = 3600s tls_random_source = dev:/dev/urandom tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map Thanks - -- Nikolai Lusan Email: niko...@lusan.id.au Phone: 0425 661 620 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl48/uAACgkQ4ZaDRV2V L6QNGQ//boxWY3q4FjvMIG6JspSrvc6D3U86sDVUyhWf68l6Ynjz87pRmaaYcgca 9E5x04ZyjLCLmPvOsez8B8OGU39X+MP+m7e/zvB+pbnxFjvpjq8rgKhKqN5t5xC9 mUYmKD2CgAIaklGW9mIOKrn9L9MCesFaNltyYQ0XyJ/UqCgVAPc6xTDU9l9SdnTp MYymIRhpY36/GeWpDoNZuyAN/cIDsP/NU+l03iYStv5GOd5FX7jlvflPeO/6u1Mk AnrvWP7r0/ekOgwVuMQCayXz1Ga65LEIv3ReFEX2jL2kTLmsfCB/yrj03Nr4963s 3I1edln1yAW1THOOE94XBYCXHMA0GkY4CQXD/eiCD1H0P2mTm7L5nryhf451V2yv fzuO6Hc8/O4sYzhDfUe8kVFeNcePN4Tp5g7sx7RxQP3sq9W+s6clyX7pu/HtIcmK CD4XGySOiQcukoS9J2d6okxR+LJBdLRZm4sEDko6jU9APPCtMI8XpbJxOzVudqYr MclERL1pTM0t6J/DtnXW8+PPctyln5Uq3+XWWzHzGoB7v+XfUrW9iSMVm+/+L4ce u+91YWG84oL0OLn+zy2NxQE7q2PIYB3l7O/iooRwR1wLx1iF8OTv7ckHDrJr6XTA re4KNPEXOkd0KXqud7Nn0GOJAbCcl9dHartzUDvpMkN5is0Keh4= =MHqj -END PGP SIGNATURE-
