[pfx] Re: SASL authentication - first try local and then AD in postfix
Sandeep, > Am 08.07.2024 um 07:37 schrieb hkhk_exact10 via Postfix-users > : > > Hi All, > > I want to setup SMTP authentication in such a way that the user should first > be looked locally (/etc/passwd) and then in AD. Is it possible to do so? I > was able to configure AD auth via sasl (cyrus), but couldn't do both. Cyrus SASL is able to use saslauthd in order to authenticate users in /etc/passwd. I don’t know what you did with Cyrus SASL to configure AD authentication, but assuming it would be a method called foobar you would configure Cyrus SASL to use the following list of password verification methods: smtpd.conf: pwcheck_method: saslauthd foobar mech_list: PLAIN LOGIN In my example Cyrus SASL would first try to authenticate an identity using saslauthd (/etc/passwd) and then foobar (AD). The mech_list must be limited to PLAIN and LOGIN, since these are the only mechanisms saslauthd supports. HTH Patrick [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG, 80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein smime.p7s Description: S/MIME cryptographic signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Still no luck with Cyrus SASL
John, * Viktor Dukhovni via Postfix-users : > On Tue, Jul 02, 2024 at 11:24:53PM -0400, John Levine via Postfix-users wrote: > > > >Have you posted "postconf -nf" and "postconf -Mf" output (with as-is > > >whitespace, including line-breaks)? > > > > I will, see below. > > Thanks, generally best to do that early when delving into configuration > conundrums. > > > >What's the evidence that "saslauthd" is not used? > > > > I have saslauthd in debug mode so it reports when anything talks to > > it. As I said, the sasl test client works fine and it reports that, so > > I know that works. > > That is, saslauthd(8) is listening on the socket you specified in your > testsaslauthd(8) command-line: > > $ testsaslauthd -f /var/spool/postfix/var/run/saslauthd/mux ... > > which you correctly specify inside the Postfix chroot jail, but, is > "/var/run/saslauthd" the actual directory compiled into the Debian SASL > library? If not, or, in any case, you might specify > > saslauthd_path: /var/run/saslauthd/mux > > in the "smtpd.conf" file, once it is in the correct (for Debian) > directory. Note that this setting does include the "/mux" suffix. IIRC Debian patches Postfix and expects smtpd.conf to be located in /etc/postfix/sasl/smtpd.conf. Have you tried this? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: 25 years today
Wietse, * Wietse Venema via Postfix-users : > As a few on this list may recall, it is 25 years ago today that the > "IBM secure mailer" had its public beta release. This was accompanied > by a nice article in the New York Times business section. > > There is some literature at https://www.postfix.org/press.html that > attests how this project accelerated open-source adoption by a very > large company. > > At the time there were several efforts by people inside IBM to do > open-source projects, but it was the NY Times article that brought > open source on the radar of the CEO. He then tasked people to come > up with an open-source strategy for IBM. > > As for the name Postfix, my colleagues and I had come up with > multiple names that were rejected each time (I still have some > Internet domains names from that time). We decided that this was > not going to work, released it as "IBM secure mailer", and then, > after IBM was no longer in control, changed the name to Postfix. > > That was a long time ago. Postfix has evolved as the Internet has > changed. I am continuing the overhaul of this software, motivated > by people like you on this mailing list. your effort to create a secure mailer became the foundation upon I was able to build my business and the way you approach and design software has influenced how I think about software development fundamentally. You may not be aware of it but sentences like "Stop speculating! Start measuring!" have become cornerstones of my daily work routine. I enjoy the clarity you bring to the table and sometimes you really make me grin like back then when you wrote: "If you want to climb a mountain, don't start at the top." Thank you! p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] FOLLOW-UP Re: Re: [ext] list.sys4.de fails with starttls
* Viktor Dukhovni via Postfix-users : > On Mon, Sep 25, 2023 at 04:24:55PM +0200, Patrick Ben Koetter via > Postfix-users wrote: > > > > Do you have SMTP client TLS connection reuse enabled? If so, TLS > > > connections are made via tlsproxy(8), with the smtp(8) client > > > unaware of any initialisation issues until STARTTLS. > > > > Well spotted and that was the reason Postfix failed. We've added a SELinux > > policy to let tlsproxy do what it wants and things went back to normal. > > Thanks for the confirmation. I feel some pride in intuiting the cause > in this case, the link with the reported symptoms was fairly subtle. After some more investigation and testing… It turned out that RedHat's SELinux policy does not cover Postfix' tlsproxy and whenever tlsproxy takes out to do what Postfix wants it to do SELinux will interfere and prohibit it from doing that. That in consequence made the SMTP service throttle and so it came to a stillstand. For the moment we decided to do without TLS session caching in Postfix smtp-client *and* sending client side x509 certificates on demand in favor of running a more secure platform. Our long-term goal is to re-enable the Postfix features *and* use SELinux. (RedHat if you're on this list and following this thread ping me offlist and I'll be happy to share all information we can provide.) Regards p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommendation for dkim signing
Noel, * Noel Butler via Postfix-users : > > sys4.de are not removing original DKIM sigs just adding postfix.org's, > > which also fails for some reason, but ohh looky that - SPF passes :D > > Decided to have a look ater lunch, that looks like it would be because sys4 > adds footers, where previously Wietse did not, again if they configured > mailman correctly it wouldnt care about that because it wouldn't see yours > or my original sigs, using DKIM "relaxed" doesnt work that way either :) we (sys4) don't add a footer. Determining a lists policy e.g. having the MLM add a footer or not is the owner's privilege. We (sys4) don't own postfix.org's lists – we host them (and are very proud to do so). p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommendation for dkim signing
* Jens Hoffrichter via Postfix-users : > Hi! > > We are looking into implementing DKIM signing for one of our services, > and there are multiple ways to implement that. > > So far I have found that you can do it with opendkim and amavis - any > recommendation for one or the other, or maybe something completely > different I haven't found yet? amavis:: amavis does nor support ED25519 and will very likley never will. There's a none open DMARC / DKIM / SPF addon but I doubt the company who built that will ever open source it. opendkim:: opendkim supports RSA-SHA256 and a (few years old) BETA also supports ED25519-SHA256. Last time I had a look the BETA was still BETA though I can confirm it works very reliably even on larger platforms (ISP). dkimpy-milter:: dkimpy-milter supports RSA-SHA256 and ED25519-SHA256. If you have experience running opendkim you will feel at home using dkimpy-milter. dkimpy-milter used to have and I don't know if it still has problems handling email message headers containing UTF-8 chars when there shouldn't be any, like in a Subject that reads "Passwort zurücksetzen", which MUST be ISO encoded, but then there are developers who don't know that and … dkimpy-milter crashes because of the way Python 3.x handles UTF-8. I've no idea if Scott has found time to address and fix that. rspamd:: rspamd supports RSA-SHA256 and ED25519-SHA256 though the documentation hardly mentions this fact. If you want to add signatures to outbound messages only you might turn off all other scanning (spam, malware, …) rspamd provides to increase performance and avoid false positives or unwanted learning. My recommendation: Use rspamd if you are using it anyway on your platform. It handles email reliably and supports RSA-SHA256 and ED25519-SHA256. If you need a DKIM signer on servers that relay outbound mail only use opendkim's BETA. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
* Viktor Dukhovni via Postfix-users : > On Sun, Sep 17, 2023 at 06:20:53PM +0200, Patrick Ben Koetter via > Postfix-users wrote: > > > Yesterday we upgraded LE certs and it seems – we haven't had time to > > investigate in that yet – SELinux bite Postfix where it shouldn't. > > Astonishingly SELinux has been running like that for 193 days and the > > problem > > should have occurred long time before we exchanged the LE cert. But all of > > what I'm writing is rumor and none has been proven. I'll write more when we > > have proven what went wrong. > > Do you have SMTP client TLS connection reuse enabled? If so, TLS > connections are made via tlsproxy(8), with the smtp(8) client unaware of > any initialisation issues until STARTTLS. Well spotted and that was the reason Postfix failed. We've added a SELinux policy to let tlsproxy do what it wants and things went back to normal. Also: As of today list.sys4.de offers and uses RSA *and* ECDSA certificates. TLSA RRs had been extended before we activated the new certs. > If you also have TLS client certs configured (typically without just > cause) to be sent to servers that happen to request them (also typically > without just cause), then a failure to load the client certs breaks TLS > support in tlsproxy(8), which makes all attempts at "STARTTLS" fail. Yes, list.sys4.de also uses TLS client certs and I'm not really sure I like you writing "typically without just cause". I'd rather have it the other way around and be irritated if clients do not identify themselves in TLS sessions as well. But then this leads to another discussion about mutual DANE-based identification where the client side need to identify itself to a DANE-verifying server as well. > We could perhaps consider soft-failing failure to load certificates in > the SMTP client (tls_client_init()). But this requires care, because > mail could bounce when the server is a submission relay that optionally > authenticates the client via its X.509 certificate, but doesn't > terminate the handshake when a client certificate is not presented > (perhaps it also supports SASL as an alternative). > > The best solution is configure client certs *sparingly*, only for > transports dedicated to destinations that definitely need the client > certs, and not otherwise. Why? I feel a little like I was feeling in the early 2000s when we had to justify offering STARTTLS on the server side. IMHO TLS should be default on both ends and any service not complying should need to explain why. > It is not possible to make an educated guess as to why tlsproxy(8) may > not have been able to load the certs, if that's what happened, without > some additional context from the server. > > Of course the problem could be entirely unrelated to tlsproxy(8), but > there are fewer obvious opportunities for late failure when TLS is > used directly by the smtp(8) client. You spotted the problem perfectly. It was tlsproxy being hindered by SELinux. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] list.sys4.de fails with starttls
___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] warn_if_reject and MILTER
Greetings, I was wondering if there's something similar to warn_if_reject when it comes to dry-run / test-run MILTER applications in Postfix. The documentation on warn_if_reject does not mention MILTERs, which usually means the feature isn't there because otherwise it would be documented, and the per-Milter settings in MILTER_README don't mention something I could use to warn_if_reject either. Is that something worth to implement or should a dry-run test mode be left to each individual MILTER implementation? Regards, p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and DNSSEC
Hey Byung-Hee! * Byung-Hee HWANG via Postfix-users : > Hellow Postfix hackers, > > I have a questions while reading DANE docs. Is DNSSEC mandotary? For > making DANE mail server. > > For now i'm running two postfix servers in public. Actually i'm beginner > in both DANE and DNSSEC. you need DNSSEC enable your DNS zone for DANE *if* you want to offer DANE on your inbound side because those who want to send to your mailserver will need DNSSEC security to ensure their server will communicate with the right server (read: your server). You don't need DNSSEC for your DNS zone *if* your server should DANE-verify other DANE enabled receiver platforms. In this case all you need to do is run a DNSSEC-verifying DNS resolver on your server (not systemd-resolved) and configure Postfix to use DANE when it sends messages: smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_tls_loglevel = 1 I do recommend to enable at least DANE on the outbound side to let your users participate from the higher level of security. p@rick P.S. See also: https://blog.sys4.de/blog/outbound-dane/, which I've written in German. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] OT Re: Re: uceprotect.wtf (was: Send email to one @domain.com via authenticated relay?)
* natan via Postfix-users : > Hi > Today uceprotect add class /24 to blaclist ... One user (dedicated server) > send probably spam but the user claims that he did not send spam only 6 > e-mails in 1h. And uceprotect was blocked by the whole class ... > > other RBLs it was clean any IP with that class /24 What you describe is what UCEprotect is known for. At eco e.V. in Germany, we at the competence group "E-Mail", published a paper about choosing and using blocklists. In this document UCEprotect serves as the only negative example of a blocklist service for all the reasons you stated yourself. Besides that UCEprotect has ridiculed people with complaints and for their misogynistic behaviour. But… there's nothing you can do about it and, dunno if you do that, you shouldn't take it personally when one of your servers gets listed by UCEprotect. It's their customers who choose a blocklist provider that acts with such quality and they don't seem to mind if their receivability is influenced by UCEprotect's blocklist quality. > Any idea ? I'm not going to pay the clowns I agree. I wouldn't pay them either. If you need to communicate with customers using UCEprotect blocklists and can't send them an email use a phone and let them know eventually you can't use email because … p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: /etc/postfix/access only doamin is blocked
* Gerd Hoerst via Postfix-users : > > Hi ! > > in my /etc/postfix/main.cf > > parent_domain_matches_subdomains = . . smtpd_access_maps > .. > smtpd_sender_restrictions = .. check_sender_access > hash:/etc/postfix/access > > > > in my main.cfs > > domain.com DISCARD Spam rule domain block > > > but emails from ..domain.com or .domain.com is still delivered. > blocking domain.com works Quoting from ACCESS(5): ... domain.tld Matches domain.tld as the domain part of an email address. The pattern domain.tld also matches subdomains, but only when the string smtpd_access_maps is listed in the Postfix parent_do‐ main_matches_subdomains configuration setting. .domain.tld Matches subdomains of domain.tld, but only when the string smtpd_access_maps is not listed in the Postfix parent_do‐ main_matches_subdomains configuration setting. ... ergo: domain.com DISCARD Spam rule domain block .domain.com DISCARD Spam rule domain block p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [P-U] Re: New List Host and Reply-to Header
* Gerald Galster via Postfix-users : > >>> This list uses Mailman configuration settings, not handcrafted code. > >>> If people believe that it is worthwhile to change the Mailman > >>> implementation or the DMARC spec, then I suggest that they work > >>> with the people responsible for that. > >> > >> There is no need for changing implementations, it's already there. > >> > >> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html > >> > >> > >> remove_dkim_headers > > > > THAT is a global Mailman setting. It cannot be configured on a > > per-list basis. The postfix lists are hosted on a multi-tenant > > service, it does not run on its dedicated MTA. > > I just wrote that because p@rick (sys4 AG) asked on the mailop mailinglist > 2023-02-17 "Should mailing list messages be DKIM signed? (ARC / DKIM)". > He was about to setup a new mailing list server with mailman 3. > Given there are virtually no other lists in postorious index, chances are > this is a new server currently only hosting the postfix mailinglist > and some testlists so that settings might not be final yet. > > Just out of curiosity it would have been nice to know why he made > that choice. You mean why I choose to use Mailman 3 and not other MLMs? I used to by python.org postmaster for 20 (?) years and there's a natural sympathy for anything that comes from pydotorg. Then I used to be on the MM3 developer team in the early 2000s and some of the ideas and concepts I came up with have found their way into MM3. Besides my personal historic preferences, I choose MM3 because it has been there for a few years now and I don't see it being used widely, though I believe it should. We (community) need a modern MLM and MM3 is modern. There are some things I don't like about MM3. If you come from Postfix MM3 documentation is, to put it, frustrating. It's developers who documented what is interesting to developers, but there don't seem to be any documents for operators. That kicks in when you need to find out how mailman-core, hyperckitty and postorius play together. The web application, to me, should really see some UX love. I constantly get lost hunting options I saw, but I can't remember where. Besides, rendering descriptions / options of parameters visibly into the interface blows up each settings page and the rendering lacks structure. So you end up scanning through a blob of options trying to catch what might to what you want. Wietse can probably tell how much he suffered at some point to get MM3 what he wanted it to do for the postfix-mumble lists. What I like about MM3 is it's approach to subscriber self management. Once you've become a registered MLM platform participant you can easily change settings that will apply to all lists you've subscribed to in one place. I consider that a great usability benefit for subscribers. But most of all I wanted to create a Mailing list platform that is capable of and uses modern email technologies. We have ARC in place and need to figure out a few undocumented issues we still need to address before it will actually work. But that's a temporary problem. I want it to use ARC because even though it is still EXPERIMENTAL, it will likely be here to stay and ARC has been designed to fix the DMARC issues that had been put on our shoulders when DMARC was adopted by major industry players. And… while I write work is going on in the background to provide a fully DNSSEC enabled DNS stack which will allow us to host a DANE enabled mailing list platform. ⌁ [p:~] $ dig +short +dnssec MX postfix.org 10 list.sys4.de. MX 13 2 3600 20230322050014 20230308042038 60616 postfix.org. DXMTOwxrFmyCf7fv02gAR0qmVeB78gGwPu74oR17y1l6vls/zbUP7P6C G5ZZWtHDCMruSzwISYfdwVBNnDdjXg== ⌁ [p:~] $ dig +short +dnssec A list.sys4.de 188.68.34.52 A 8 3 3600 20230315165309 20230308142813 46365 sys4.de. Oi9o51moM26dA2Y2zMjMXErEz8wj/o+tadfas9QedSv5AqPg0C0uBaZd 31IeAZRxGxFLwECqLqPncJgyyKkNLXlTY2t1qQ60/GT3rjRof9kmIwpO lwYgFBwUfsjhz1rPF16W81ya+5DdPJefXuYMN4G6hOWvJPgiMo5qeUGb JFs= This will allow us to add TLSA RRs to list.sys4.de soonish and then postfix.org finally will life what it brought to live when Viktor implemented DANE support making Postfix the first and reference MTA on this planet to support DANE. Secure Email Transport and Email Authentication are the two cornerstones of todays email policing and my personal wish is to provide a state of the art platform and hopefully a template how to run mailing lists in the 2020s. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [P-U] Re: The joke writes itself.
* Phil Biggs via Postfix-users : > Friday, March 10, 2023, 5:54:02 PM, Viktor Dukhovni via Postfix-users wrote: > > > I was also quite happy with no tags at all. In the old days I used the tags to filter my messages and place them in the right mailbox. With the advent of DMARC I stopped that and turned to using List-Id:-headers as filter trigger. They are invisible, they don't require Subject:-header modification and thus don't break DKIM sigs and the folder the message gets placed in tells me which mailing list it comes from. I don't need tags. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
* Viktor Dukhovni via Postfix-users : > On Wed, Mar 08, 2023 at 07:42:56AM +0100, Patrick Ben Koetter via > Postfix-users wrote: > > > - The key material is 4096 Bit and it was brought to my attention there's a > > bug / missing functionality (?) in opendmarc which results in the program > > being unable to handle keys at sizes larger than 2024 Bit. > > I assume that's 2048-bit, not 2024. Further: ACK. Add coffee and it becomes 2048-bit. > - NEVER use 4096-bit RSA. If your security requirements merit a > 4096-bit RSA key, don't use RSA. All the long-term keys securing > the operating system updates you rely on, the DNSSEC key of the root > zone, ... are all 2048-bits. The threat models for 4096-bit RSA > look rather questionable to me. All I see when I see 4096-bit RSA > is a fashion statement. > > - You could even consider a 1024-bit RSA keys for less bloat, and > just roll a new key and selector every ~90-180 days. DKIM > verifiers use unauthenticated DNS to retrieve the key. It makes > little sense to be worried about ~0.5 million core-year attacks on > 1024-bit RSA just to forge some DKIM messages. ACK. On a sidenote: That's why the new technical guideline for email authentication from Germany's Federal Office for Information Security (BSI) will make it mandatory for any platform that wants to qualify for their upcoming TR-03182 standard to run the whole platform on (local) DNSSEC enabled resolvers. *If* a zone publishes its DNS using DNSSEC the qualifying platform must use the chance to use authenticated DNS when it retrieves key material or senderdomain email policies (SPF, DMARC). p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] FOLLOWUP Re: Re: Postfix lists are migrating to a new list server
* Patrick Ben Koetter via Postfix-users : > * Scott Kitterman via Postfix-users : > > ... > > > For Debian, if someone can find/test patches, I can get them into Debian's > > package. I assume other distributors are similar. Feel free to update the > > Debian bug with information. It's unfortunate we don't have a better > > maintained solution. > > In Germany the German government is preparing an initiative to foster open > source projects that are considered to be vital for e.g. the security of > people when they are on the internet. For those interested, here's the link: https://sovereigntechfund.de/en.html p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
* Scott Kitterman via Postfix-users : ... > For Debian, if someone can find/test patches, I can get them into Debian's > package. I assume other distributors are similar. Feel free to update the > Debian bug with information. It's unfortunate we don't have a better > maintained solution. In Germany the German government is preparing an initiative to foster open source projects that are considered to be vital for e.g. the security of people when they are on the internet. At eco e.v., Germanies lobby organization for businesses on the internet, we are currently investigating if opendkim and opendmarc could receive grant from the government. openspf, opendkim and opendmarc have been very useful when the IETF created the RFCs, because you need "rough consensus and running code", and the programs always served to provide the latter, but then, after they had become the de facto standard applications, no one took on the task of "software gardening" and so bugs that had been discovered did not get fixed and new functionality has not been added. That's one of the reasons it has become harder to run a modern mail platform on your own if you are not a major player. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
* postfix--- via Postfix-users : > > > > OpenDMARC is segfaulting. That's what 'signal 11' means. Postfix fails > > > > to get an answer to its end-of-body milter call because of the segfault > > > > closing the other end of that socket. That failure results in Postfix > > > > sending a 4xx to the client. > > > > First step is to verify your installation of OpenDMARC. Make sure you > > > > have a current version, that its dependencies are consistent with the > > > > build, etc. > > > I ran into the same problem. I found that the opendmarc package in Debian > > bullseye is vulnerable to CVE-2021-34555, and I believe this is the source > > of the crash (in combination with the new email headers from the mailing > > list transition). > > > > I solved the problem by upgrading to the version of opendmarc in Debian > > testing. > > > I am using RHEL8 and after checking for updates I was able to update > opendmarc to 1.4.2 (from 1.4.1) however it still has the error, only with > mail from this list. > In the mean time as suggested, I added "list.sys4.de" to the ignorelist to be > able to accept list mail again. However i would like to solve the problem and > not rest on a band-aid. It seems the problem is being caused by two things: - The DNS entry uses h=rsa-sha256 when it should be h=sha256 That's a copy and paste error on my side. I scratched this from a Mailman 3 example and did not verify the example was valid. We'll fix that when we will start using new key material - The key material is 4096 Bit and it was brought to my attention there's a bug / missing functionality (?) in opendmarc which results in the program being unable to handle keys at sizes larger than 2024 Bit. We'll generate a new 2024 Bit key pair and place the new key in DNS. When we do that we'll also see to fix the h=sha256 problem. This will take place within the next 12 hours. Mailman will be restarted in the end and the service will be unavailable for about 30 seconds. No list mail will be lost. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: sys4 is listed in Abusix
* Michael Grimm via Postfix-users : > toganm--- via Postfix-users wrote: > > > Maybe it would have been a better idea to check if the mail server is listed > > in any rbl sites. > > If you really were in mailing business for some time you would know how RBLs > work: They react, they do not read crystal balls! Nope. There are burned IPs that had been previously been used by spammers and there are even complete ASes, owned by hosters that just don't seem to be able / willing to get control over outbound abuse from their networks. Regarding this it *does* make sense to check an IPs reputation *before* you run a mail service using that IP. Besides that: I'd like to keep it classy. I don't see any reason to offend anyone for a discussion over IP. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: sys4 is listed in Abusix
* toganm--- via Postfix-users : > > Hi, > > Maybe it would have been a better idea to check if the mail server is listed > in any rbl sites. For one it is listed in Abusix and my server is rejected it > as a result > > Abusix Mail Intelligence; https://lookup.abusix.com/search?q=188.68.34.52 list.sys4.de is no more listed. abusix will investigate tomorrow what hit the traps. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: sys4 is listed in Abusix
* toganm--- via Postfix-users : > Maybe it would have been a better idea to check if the mail server is listed > in any rbl sites. For one it is listed in Abusix and my server is rejected it > as a result What makes you believe the IP had been blocklisted before? The IP was blocklisted today. It wasn't on a blocklist before that. That's what the details show on the abusix report. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
* Harald Koch via Postfix-users : > On Tue, Mar 7, 2023, at 12:02, Benny Pedersen via Postfix-users wrote: > > > > why is arc invalid ? > > My email provider is adding a little more detail: > > Authentication-Results: pb-mx20.pobox.com; > arc=invalid > (as.1.list.sys4.de=invalid (public key: does not support hash algorithm > 'sha256'), ams.1.list.sys4.de=invalid (public key: does not support hash > algorithm 'sha256')) > smtp.remote-ip=188.68.34.52; Thank you. We'll investigate into this. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[P-U] Re: Postfix lists are migrating to a new list server
* Wietse Venema via Postfix-users : > Gerald Galster via Postfix-users: > > > > >> Out of sheer curiosity ... Mailman 2 or 3? > > > > > > Mailman 3 with ARC support enabled. Additionally all listmail will be DKIM > > > signed. > > > > Do you plan to enable a public archive at > > https://list.sys4.de/hyperkitty/list/postfix-us...@de.postfix.org/ > > as an alternative to marc.info, mail-archive.com, ... ? > > Patrick and I agreed that a local archive was not needed, and I > have verified that marc.info and mail-archive.com are receiving the > new postings (though marc.info appears to be missing one). > > Someone should figure out how to delete the archive link from the > Postorius web pages. I'll let Jörg at sys4 take a look at this. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Postfix lists are migrating to a new list server
* Matus UHLAR - fantomas : > > > On 3/6/23 11:08, Wietse Venema wrote: > > > > This week, the Postfix mailing lists will be migrated from Majordomo at > > > > Cloud9.net to Mailman at Sys4.de. Thanks to Cloud9.net for hosting the > > > > Postfix lists for 24 years, and thanks to Sys4 for being the new host. > > > > > > > > This is the pre-migration announcement. > > > * Phil Stracchino : > > > Out of sheer curiosity ... Mailman 2 or 3? > > On 07.03.23 13:09, Patrick Ben Koetter wrote: > > Mailman 3 with ARC support enabled. Additionally all listmail will be DKIM > > signed. > > So the headers will be modificated? list.sys4.de will accept mail, regardless if has been DKIM signed or not. postfix-lists modify the subject header and they add a list footer. This will break any pre-existing (valid) DKIM signature. But if there's a DKIM signature it will be verified before the modification takes place and the verification result will be stated in an ARC signature list.sys4.de will append as header to any outgoing mail. Additionally any message from postfix.org will be DKIM-signed just before it leaves list.sys4.de. For the moment this will be RSA-SHA256 only. ED25519-SHA256 will likely follow as stable software to do so will become available. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Postfix lists are migrating to a new list server
* Phil Stracchino : > On 3/6/23 11:08, Wietse Venema wrote: > > This week, the Postfix mailing lists will be migrated from Majordomo at > > Cloud9.net to Mailman at Sys4.de. Thanks to Cloud9.net for hosting the > > Postfix lists for 24 years, and thanks to Sys4 for being the new host. > > > > This is the pre-migration announcement. > > Out of sheer curiosity ... Mailman 2 or 3? Mailman 3 with ARC support enabled. Additionally all listmail will be DKIM signed. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: RFC 5233 "Subaddresses" and LDAP lookups
* Viktor Dukhovni : > On Wed, Jan 11, 2023 at 03:57:28PM +0100, Patrick Ben Koetter wrote: > > > Today I ran into a lookup problem where a sender (!) was using the RFC 5233 > > subaddress schema so send a message e.g. as localpart+subaddress@domainpart > > and lookups with smtpd_sender_login_maps failed because I was unable to come > > up with a LDAP query_filter that would look for localpart@domainpart a ka > > strip the subaddress. > > http://www.postfix.org/postconf.5.html#recipient_delimiter > > The documentation isn't clear on whether extensions are handled in > > http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps > > but they are. You shouldn't need any LDAP-specific support here, > Postfix will automatically generate a query with the extension elided. Thanks! Makes me wonder why the setup I was testing today failed to behave like you wrote. I'll try to reconstruct this on a test machine as soon as I find time and verify that. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
RFC 5233 "Subaddresses" and LDAP lookups
Greetings! Today I ran into a lookup problem where a sender (!) was using the RFC 5233 subaddress schema so send a message e.g. as localpart+subaddress@domainpart and lookups with smtpd_sender_login_maps failed because I was unable to come up with a LDAP query_filter that would look for localpart@domainpart a ka strip the subaddress. Is that intentional e.g. because subaddresses are meant for filtering on the recipients side and not for senders as envelope-sender or is it something Postfix should support and it just hasn't been implemented yet? Thanks, p@rick P.S: Or even worse I failed to come up with a query_filter that would actually do what I want. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Opendmarc in after-Amavis smtpd fails
Am 15.04.21 um 13:13 schrieb Jesper Dybdal: 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. I am aware that such code exists, but I don't know if it will be open sourced. Any followup to this should probably go to the amavis mailing list. p@ -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein smime.p7s Description: S/MIME Cryptographic Signature
FYI: ArchLinux modularizes Postfix packages (Arch Users should read this)
Arch Users, if you are using Postfix on Arch Linux and if your Postfix setup utilizes either cdb, ldap, lmdb, mysql, pcre, pgsql or sqlite as data backend your setup will cease to work once you've applied the recent 3.5.9-1 packages. As of this package release Arch Linux has begun to use Postfix' feature to load database drivers dynamically. You will have to install the aforementioned database drivers as optional packages to continue using these database types. Use the pacman-command to list optional Postfix packages: # pacman -Ss postfix- extra/postfix-cdb 3.5.9-1 Fast, easy to administer, secure mail server extra/postfix-ldap 3.5.9-1 Fast, easy to administer, secure mail server extra/postfix-lmdb 3.5.9-1 Fast, easy to administer, secure mail server extra/postfix-mysql 3.5.9-1 Fast, easy to administer, secure mail server extra/postfix-pcre 3.5.9-1 [Installiert] Fast, easy to administer, secure mail server extra/postfix-pgsql 3.5.9-1 Fast, easy to administer, secure mail server extra/postfix-sqlite 3.5.9-1 Fast, easy to administer, secure mail server Once you've installed one or more of the optional packages you will find a new directory dynamicmaps.cf.d in Postfix' configuration_directory. It will contain one file per database type that sets which database driver Postfix should load dynamically: # cat /etc/postfix/dynamicmaps.cf.d/postfix-pcre.cf pcrepostfix-pcre.so dict_pcre_open Reload Postfix and you are done. HTH! p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: How do you manage the ‘hold’ queue?
* David Bürgin : > I’ve recently begun using the ‘hold’ queue, because of a milter that I > use. A milter may ‘quarantine’ a message, which causes the message to be > placed in the ‘hold’ queue (eg OpenDMARC does this when the DMARC policy > requests quarantine). > > But how does one manage that queue? I know that > postqueue/postsuper/postcat exist, but it seems like a lot of work to > periodically (daily, weekly?) inspect each message in that queue and > deal with them one by one? Do people actually use quarantine/on-hold, > and if so how do you manage your queue? The HOLD queue was never meant to be a fullblown quarantine store with management tools etc. That might explain the lack of tools to manage the queue conveniently in daily business. You might want to use amavis' quarantine capabilities and let it do the job. It also has an interface to send (release) commands to and comes with a script to do it manually on the command line. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
* PGNet Dev : > On 10/26/20 4:19 AM, Patrick Ben Koetter wrote: > > There's only *one* SigningTable, but there are two KeyTables – one for rsa > > and > > the other one for ed25519. Maybe you are using an older version of > > dkimpy-milter. IIRC it had a related error in the man page. > > oops, typo. > > yep, I've one ST & 2 KTs, one each for rsa & ed25519 > > using latest available via pip, v1.2.2. can try master branch. That will suffice. > > Yes. I use it on mailop.org. > > thx! > ok. so it's local ... > > > how are you generating your ed25519 data? > > for rsa, here, _either_ 'dknewkey' or 'openssl genrsa (etc)' works fine. > > for the ed25519, i get different fails -- in error logs -- with 'dknewkey' or > 'openssl genpkey (etc)'. > > atm, with 'dknewkey' generated data, on attempted ed25519 signing I'm seeing: > "sign_dkim: The seed must be exactly 32 bytes long" I haven't had any problems either on Debian, Ubuntu or ARCH Linux using dknewkey. > i know README says "in order to generate Ed25519 keys for dkimpy-milter, > dkimpy specific tools > must be used to be compatible > " I wouldn't know either. Maybe you should reach out to the developer. On a sidenote: If you want to use ansible, you might want to try this: https://github.com/sys4/dkimpy-role p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: any success with postfix + dkimpy-milter outbound DKIM signing -- with ed25519 keys?
* PGNet Dev : > i'm swapping out opendkim milter from a postfix setup. > > inbound verification's been replaced with fastmail's authentication_milter -- > in smtpd mode > so far, behaving well. > > outbound signing on postfix sumbission has been replaced with dkimpy-milter. > seems to work nicely for rsa signing. > > support's supposedly _there_ for ed25519 signing. > but, when I deploy -- simply enabling ed25519 signingtable -- I get lots of > errors -- just starting to troubleshoot now. There's only *one* SigningTable, but there are two KeyTables – one for rsa and the other one for ed25519. Maybe you are using an older version of dkimpy-milter. IIRC it had a related error in the man page. > 1st question ... > > ... is outbound ed25519 signing with dkimpy-milter in Postfix known-to-work > for anyone here? Yes. I use it on mailop.org. > iiuc, there's no Postfix-reason that it shouldn't work; a milter's a milter. > > so, just looking for any evidence that someone's got it working at all b4 > diving in. It's worth it. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Recommended milters for small setup
* Ian Evans : > The long story short is that due to dealing with family medical issues over > the past few years, my Combo web/postfix server is still on Ubuntu 14.04. > > In a couple of months I will have some time to upgrade. Instead of risking > an in place upgrade, I am going to fire up a new droplet on Digitalocean, > install the latest stuff over there, and migrate my data. > > My site has two email users, me and the missus. I currently run an email > stack of postfix, amavis, spamassassin, clamav and dovecot. The Postfix > also has dkim, dmarc, spf and postscreen. > > Is there a more efficient, memory stingy, faster milter way to run > spamassassin, clamav, etc, or would you recommend sticking with amavis? If you need quarantine and per user policies you want to stick with amavis. I recommend to use amavis via the amavis-milter bridge. Other than that you might want to give rspamd a shot. It can sign/verify DKIM, verify DMARC and IIRC it can to SPF as well. There's a way to plug ClamAV into rspamd and of course it can detect and reject spam as well. If you use rspamd it is recommended *not* to use postscreen as this keeps clients away from rspamd and that prevents it from learning and becoming more efficient. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Untrusted TLS connection appearing in logs
* Robert Chalmers (Author) : > > I’m seeing this in my log file on outgoing test mail. Can’t seem to find a > solution. The mail does go through, but leaves this “Untrusted” message in > its wake. > > Jul 16 15:33:37 www postfix/587/smtp[35313]: Untrusted TLS connection > established to gmail-smtp-in.l.google.com[2a00:1450:400c:c08::1a]:25: TLSv1.2 > with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) Use smtp_tls_CAFile and let it point to your local collection of trusted CAs. Then reload Postfix. You will begin to see 'trusted' connections. In order to also see 'verified' connections add DANE config to all outgoing mail (read: Postfix smtp-client). p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: saslauthd problem
* N KN : > Thanks for the answer. I'm however trying to use the PAM way, because using > the auxprop method involves storing user passwords in plain text, which I'd > like to avoid. I can't seem to find a way to tell the smtpd.conf file to The best [tm] way is to offer plaintext methods only over an encrypted transport layer and store passwords crypted. This is not possible with auxprops other than saslauthd. > encrypt passwords, and as per the Postfix documentation it seems not > possible, so I'm stuck. The best way would be to tell the PAM module that > the username table is in the user@domain form, I'm not sure this is > possible though. Take a look at the command line option "-r" for saslauthd: https://blog.sys4.de/cyrus-sasl-saslauthd-man-page-en.html Use 'testsaslauthd' to test authentication: https://linux.die.net/man/8/testsaslauthd Alternative: Use dovecot as password verification service and let it do the SQL queries. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Problems with milter_default_action = accept
We've run into a problem with a MILTER, which Postfix is supposed to ignore in
case of problems. To do so we've configured Postfix to use
milter_default_action = accept, when it communicates with the milter, like
this:
mymilter = {
inet:127.0.0.1:6677,
connect_timeout=10s,
default_action=accept
}
smtpd_milters =
$mymilter
...
However it doesn't work and I'm trying to understand why. What kind of
reply/return code does Postfix (or libmilter) need from the milter to let it
'accept' the message in question?
A little background:
The real culprit here is some crappy mail marketing software, which creates
non RFC-conform headers containing Umlauts like this:
Date: Sat, 4 Jan 2020 09:53:42 +0100 (Mitteleuropäische Zeit)
This causes problems in the MILTER application/library. Unfortunately we are
not in a position to tell that particular customer to use something else at
the moment. So I'd like to let Postfix accept messages when the milter runs
into problems.
TIA,
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
ANN: dkimpy-milter ansible role
I've created an ansible role for dkimpy-milter, which allows to install and configure dkimpy-milter. The role also provides the means to create and use rsa and ed25519 type DKIM keys: <https://github.com/sys4/dkimpy-role>. Please report bugs and requests for enhancements to the projects issue tracker located at <https://github.com/sys4/dkimpy-role/issues>. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Unable to send mail via "smtp.office365.com"
* Gerard E. Seibert : > Thank you for that quick and accurate answer. I was just wondering, is > this a bug in 'libsasl' or is it due to a change in Outlook? My setup > had been working for years without any errors. It's very likely not a bug, but simply how SASL works. Unless configured explicitly to act different (any) SASL will always try to use the mechanism that offers the highest security strengh factor. OAUTH2 offers higher security than PLAIN, simply because PLAIN sends the identity (username, password) BASE64 encoded only. Encrypted connections are out of scope of the PLAIN mech. This said I do assume your system upgrade added OAUTH2 mechs, where there had been none on your old system. And what used to work because PLAIN was the only mech and therefore had the highest security strengh factor suddenly began to fail because now OAUTH2 was preferred over PLAIN. Limiting the list of SASL mechs that may be used, just like Wietse wrote, explicitly configures Cyrus SASL to ignore any other mechs except for those on the list. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Sending bounce notification via a relayhost
* Wietse Venema : > Nico Angenon: > > hello, > > > > I?d like to configure postfix to send bounce notification via another host : > > Why should biunces follow a different path than non-bounces? Because bounces get a different rating on the receiving than 'regular' mail and this might have a negative influence on the outbound IP that is used for sending 'regular' mail. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Permanent store of incoming mail.
* @lbutlr : > On 20 Mar 2019, at 15:06, Homer Wilson Smith > wrote: > >Pointers to RTFM > > > >Running Centos 7.x, latest postfix. > > > >What is the best way to keep a permanent store for > > incgoing e-mail. Doesn't have to be forever. 1 year perhaps. > > I use recipient_bcc_maps Or, if you use dovecot as storage, create a second dovecot instance and dsync messages from first to second instance. On the second instance you can benefit from server-side search and all the tooling that comes with doveadm, e.g. iterating over all messages in all mailboxes and age those older than one year. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Understanding the importance of submission
* Yassine Chaouche : > Dear postfix, > > I don't seem to get the idea of submission, I know I must be wrong, b/c so > many articles out there preach to use a different port for submission, but I Use submission on TCP/587 for MUA to MTA traffic. Use smtp on TCP/25 for MTA to MTA traffic. Run authenticated MUA friendly policies on Submission. Run MTA policies on smtp port. Access providers may block outbound TCP/25 connections, because infected enduser devices try to transport messages on that port to remote MTAs. They won't block TCP/597 because submission requires SMTP AUTH, which requires the sender to possess login/pass – something most spammers don't have. p@rick > hope to find some argument in your replies that will make me change my mind. > If I understand correctly, submission is a means for mail server admins to > enforce some policies on port 587 w/o interfering with mail relay which > occurs on port 25. These policies are mainly : > > 1/ Force TLS on all incoming connexions > 2/ Force users to authenticate > > While 1/ can't be enforced on port 25, 2/ can be enforced for relay, e.g. > with : > > smtpd_sasl_auth_enable = yes > smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, > reject_unauth_destination > > So the only thing that I need submission port for seems to be to force TLS > connexions, right ? > > Anything else I am missing there ? > > Another claim for submission is that it reduces spam, but to my > understanding that's only for *sending* spam (relaying), and that's because > the admin enforces user authentication for relay, which can safely be done > on port 25 anyways (otherwise we'd be an open relay). As for *reciving* spam > (we're the final destination), it can still be delivered unauthed from port > 25, so that won't stop *receiving* spam, will it ? > > I'm all confused. > > Yassine. > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: 'Linux 5' support in Postfix Stable Release 3.4.1 ?
* Wietse Venema : > Which distro ships with Linux 5.x kernels? I want to install that > distribution in a VM for tests. I am not interested in a FrankenLinux > where I have to assemble different parts from different providers. > Last time I asked I did not get a good answer. Linux x1.sys4.de 5.0.0-arch1-1-ARCH #1 SMP PREEMPT Mon Mar 4 14:11:43 UTC 2019 x86_64 GNU/Linux -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: 3.3.0 -> 3.3.2 and sasl error
* sashk : > Hi, > > I've attempted upgrade of my postfix docker container from alpine 3.8 (which > has postfix 3.3.0) to alpine 3.9 (postfix 3.3.2). Perfectly working config > which just worked with 3.3.0 now causing SASL auth error: warning: SASL > authentication failure: No worthy mechs found > > Here is verbose logging from container: > > smtp_1 | 2019-02-16T04:33:01.621125+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-host.domain.com > smtp_1 | 2019-02-16T04:33:01.621166+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-PIPELINING > smtp_1 | 2019-02-16T04:33:01.621170+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-SIZE 104857600 > smtp_1 | 2019-02-16T04:33:01.621174+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-VRFY > smtp_1 | 2019-02-16T04:33:01.621177+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-ETRN > smtp_1 | 2019-02-16T04:33:01.621182+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-AUTH PLAIN LOGIN > smtp_1 | 2019-02-16T04:33:01.621186+00:00 xxx postfix/smtp[106]: < > host.domain.com[IP.ADDRESS]:587: 250-AUTH=PLAIN LOGIN The other side offers PLAIN LOGIN, but your smtp client doesn't like that because those are mechanisms which send identification data in clear (read: unencrypted). That's because you have this (default) in place: smtp_sasl_security_options = noplaintext, noanonymous Either you make sure your smtp client uses TLS, while it attempts to authenticate or you lower the security policy and configure your smtp client to permit PLAIN and/or LOGIN like this: smtp_sasl_security_options = noanonymous This removes the noplaintext restriction and only forbids usage of anonymous mechanisms. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: user authentication and password format
* Robert Moskowitz : > For my new server, I plan on using either SHA256 or 512 and trying to see > what impact NOT using MD5 has on the postfix configuration. I am assuming > that this only impacts the sasl authentication and I am seeing: > > # postconf -n|grep sasl > broken_sasl_auth_clients = yes > smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, > rej > ect_unauth_destination, reject_non_fqdn_sender, reject_non_fqdn_recipient, > rejec > t_unknown_recipient_domain > smtpd_sasl_auth_enable = yes > smtpd_sasl_local_domain = $mydomain > smtpd_sasl_path = private/auth > smtpd_sasl_type = dovecot > > That postfix let's dovecot do the authentication lifting and so only dovecot > needs to know the password format and that is in dovecot-sql.conf, > > Is that the extent of it, or is there somewhere else I need to specify the > password format. It's all left to dovecot. From Postfix' point of view dovecot acts as password verification service. Postfix hands over the indentity data, dovecot authenticates the identity and returns the result and Postfix authorizes the identity to e.g. relay mails. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Rethinking the Postfix release schedule
* Wietse Venema : > I do not care much what other projects do. Postfix has a good record > for quality, stability and compatibility, and it supports four > stable releases, each release receiving updates for four years. > > I do observe that 1) several major features were ready about 6 > months after the 3.3 stable release that would have solved a real > problem; and 2) I have code that is not ready for the 3.4 release, > but I don't want to wait with until 2020. Both problems can be > solved with a less-than-year release cycle. Why wait for a group of features before a release? Why not release per feature? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Retiring oqmgr?
Configuring a new Postfix server I just ran across the commented entry for oqmgr and I thought: It must have been ages qmgr had been renamed to oqmgr and it might be time to remove that entry from master.cf. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Logging suggestion
* John Fawcett : > The first one is to leave an explicit trace in the log when starttls is > enforced (for example on the submission port) but the client does not > issue STARTTLS. Have you tried to set reject_plaintext_session and trace its error message in the log? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: cisco pix TLS is required, but was not offere STARTTLS issue
* Stefan Bauer : > Dear Users, > > we trying to deliver mail to remote party with enforced encrcyption. > > 63FFB80805: TLS is required, but was not offered by host mx0.esb.de > [194.77.230.138] > > But looks like, remote device is announcing TLS and can handle it: > > # telnet mx0.esb.de 25 > Trying 194.77.230.138... > Connected to mx0.esb.de. > Escape character is '^]'. > 220 > ehlo test > 250-mx0.esb.de > 250-8BITMIME > 250-SIZE 52428800 > 250 STARTTLS > starttls > 220 Go ahead with TLS > > But the minus "-" is missing in STARTTLS correct? Look into your log and you will very likely find something that says: Cisco PIX enabled? > Is there a known workaround available? > > Maybe some rewrite-voodoo? Something – quite likely a Cisco ASA/PIX – manipulates the SMTP server banner and the STARTTLS capability announcement. This is what it should look like: 220 mail.sys4.de ESMTP Submission EHLO foo.sys4.de 250-mail.sys4.de 250-PIPELINING 250-SIZE 4096 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 SMTPUTF8 QUIT The $something removes the "ESMTP" in den server banner. Without the string "ESMTP" the mail client (read: Your Postfix smtp client) cannot know the remote server supports any of the Enhanced SMTP features, which includes STARTTLS. It *must* assume the server speak rudimentary SMTP only. Thus it uses rudimentary SMTP only, which excludes STARTTLS. And that's why it fails in the first. The missing minus "-" just adds to the dilemma. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Best way of synchronizing configs for multiple relay servers?
* K F : > Not sure I understand the suggestions fully.The configuration management > systems I've found for postfix, are all concentrated on a single postfix > system?Containers? Like in Docker? Why? I have the servers set up already?Not > sure what the Makefile should do in the configuration context. > It's probably just me being narrowminded, so please elaborate so that I might > get enlightened :-) Create your maps with a Makefile and let the script SCP things, for example. > > Den onsdag den 7. november 2018 12.02.32 CET skrev Patrick Ben Koetter > : > > * K F : > > Hi all > > I'm contemplating on how I best keep all our relay servers synchronized in > > their config.They are set up as round robin servers in the DNS, so they > > distribute the load pretty ok.My first idea was to set up some rsync to > > copy the relevant directories like /etc/postfix and /etc/opendkim.Then I > > need a local script on each server looking for changes, and if there is, it > > should restart the postfix service. > > I could also just mount the folders to a specific server, but then I > > introduce a SPOF, which is not what I would like, and I still need > > something on each server to restart the postfix service if any changes are > > detected. > > Are there any nice ready made systems for this?I don't have any mailboxes > > on the servers, as they are only relays from our internal systems, so there > > is no need for a big system that tries to synchronize those as well. > > Choose your weapons: > > - Makefile > - Configuration Management System > - Containers and CI > > p@rick > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Schleißheimer Straße 26/MG,80333 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief > Aufsichtsratsvorsitzender: Florian Kirstein > > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Best way of synchronizing configs for multiple relay servers?
* K F : > Hi all > I'm contemplating on how I best keep all our relay servers synchronized in > their config.They are set up as round robin servers in the DNS, so they > distribute the load pretty ok.My first idea was to set up some rsync to copy > the relevant directories like /etc/postfix and /etc/opendkim.Then I need a > local script on each server looking for changes, and if there is, it should > restart the postfix service. > I could also just mount the folders to a specific server, but then I > introduce a SPOF, which is not what I would like, and I still need something > on each server to restart the postfix service if any changes are detected. > Are there any nice ready made systems for this?I don't have any mailboxes on > the servers, as they are only relays from our internal systems, so there is > no need for a big system that tries to synchronize those as well. Choose your weapons: - Makefile - Configuration Management System - Containers and CI p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: postfix functional testing
* Илья Шипицин : > вт, 2 окт. 2018 г. в 4:24, Wietse Venema : > > > ???: > > > Hello, > > > > > > we have pretty complicated setup. when we change something, we can break > > > something else. however, we can describe "what must work". > > > > In the case of email, this is usually tested by sending email and > > monitoring one or more destination mailboxes, to determine if the > > message is delivered in the expected time and with the expected > > content. > > > > > is there a way of describing configuration testing like > > > > > https://openresty.gitbooks.io/programming-openresty/content/testing/test-nginx.html > > > ? > > > > SMTP is a store-and-forward protocol, therefore server responses > > alone cover only a small part of a complete email transaction. > > > > I understand that HTTP and SMTP are different (while HTTP borrowed a lot > from SMTP, like return status codes). > what I did already is "sendmail -bt" (become test) mode. it allows to test > some aspects of smtp rules (not many, mostly address manipulation). > > what I would like to test are > > 1) some IP are allowed to relay, some are not allowed (i'd like to specify > several IP addresses and see "relay allowed" or "relay not allowed") > 2) some domains should be delivered via LMTP, i.e. locally (I'd like to > specify both local and remote addresses and see what happens) > 3) DKIM signature is added to certain domains (via milter), I'd like to > send test messages and see > > well, at least "3)" can be tested via real use letters. not clear how to > test "1)" and "2)" For 1) and 2) read into XCLIENT. We use it for functional testing all the time. For 3) send the message to another (local) instance and let it verify, then parse the log. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: any api to read logs ?
* Илья Шипицин : > > Here is an idea: combine log analysis with a web API. End of problem. > > that was what I was going to implement. > however, I do not like to implement thing that are implemented already. > so, I did a google search and I asked mailing list. > > seems, I need to implement rest api myself. > > > one more question. > I like text logs. they are fast, and available 100% (comparing, for example > to some network logging). > > is there a way (I did a seach already) to make logs structured ? something > like apache access log (field with separator), json, xml, csv ? > whatever to be machine readable (to make rest api actually read it) There isn't and it is one of the (very few) shortcomings of Postfix. AFAIK logging – as it is today – was hard wired into the code, which means if you would like to add a new way to output it, i.e. alternate format, structure, you would have to work your way through all the code. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: smtp_tls_policy_maps on a per tls user basis
* Stefan Bauer :
> Am Sonntag, 9. September 2018 schrieb Wietse Venema :
> > Instead, you can use transport_maps to choose between different
> > Postfix SMTP clients (with different configurations) based on the
> > recipient address or domain.
> >
> > You can use the access map or header/body_checks FILTER action
> > ("FILTER name-of-transport:", without a domain after the ":") to
> > choose delivery methods based on other message properties, with
> > some loss of elegance.
>
> I see no way to combine both. I want to enforce tls for sender1 to
> google.com but not for sender2 to google.com.
Use two Postfix instances to deal with it. Single messages out first, then
route them as desired:
The first instance accepts the message and uses a ?_destination_recipient_limit
of 1 to hand the message over to the second instance.
In the second instance create (at least) a second smtp service (e.g.
mandatorytls), which enforces TLS to any destination.
Use a suited map type, search for a sender or recipient and let the query
result "FILTER mandatorytls". It will tell Postfix to use the TLS only smtp
service.
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Postsuper remote
* Julian Kippels : > I would like to know if there is a command line tool for managing many > postfix servers from a central server. I have 4 servers running postfix > and I would like to manage the mail queues from one single machine. Using recent Postfix versions you can output Postfix queue status as JSON strings. You can start from there, pull the output into something that's accessible via network and aggregate this in a web frontend, something that does graphs, tables etc. Then add commands that end in SSH commands to the servers or use e.g. a REST API and submit commands to the API that map to postqueue/postsuper commands. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Greylisting (Was Re: Fall back to relay after [some] 5XX repl[ies] from destination?)
* @lbutlr : > On 07 Aug 2018, at 04:49, Luc Pardon wrote: > > but in any case it serves no useful purpose (unlike greylisting, SAV, etc. > > Are people still finding grey listing to be useful? I found it caused far > more problems than it solved and the endless game of scanning logs for sites > like Amazon that resend from different machines or many banks that will > never resend was time consuming and tedious. Yes, I find it still useful, but I don't use it as a primary tool ever since postscreen has landed. Actually I was very happy to send it back into line, because it kills one of the most attractive features in email: instant communication. Nowadays we use it in rspamd, where it works as "dynamic greylisting" addon. Whenever a certain threshold has been reached rspamd sends the client off to greylisting. Any mail that stays below that threshold will not be subject to greylisting. I like that conditional behaviour better. It adds delay to email delivery only when in doubt. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Reducing logging
* LuKreme <krem...@kreme.com>: > I may have asked this before, but if so I can't find the thread. > > I'd like to either reduce the amount that postfix logs or redirect certain > events to a secondary log file (that I can put on a shorter rotation than the > full mail log). > > Is there anyway to redirect, for example, post screen events to a different > log file or the warning hostname does not resolve messages? You'll probably have to use a (more modern) syslog service, e.g. rsyslogd, to split log by content into multiple files. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: postscreen-policy (was: Feature request for postscreen: "defer")
* Wietse Venema <postfix-users@postfix.org>: > Patrick Ben Koetter: > > * Wietse Venema <postfix-users@postfix.org>: > > > Wietse Venema: > > > > Unlike DNS lookups, the access map lookup is a blocking operation, > > > > and if your tcp map takes 80ms to complete (a typical trans-atlantic > > > > query), then you can handle only 12 connections per second, and > > > > make postsceen the largest performance bottleneck on the system. > > > > > > After starting work on postscreen by the middle of 2009, I soon > > > realized that I might have to add some postscreen-policy interface > > > for things that are too complex or that take too much time compared > > > to a quick access map lookup. Perhaps the time has come. > > > > > > Basically this would be a very small subset of the SMTP server > > > policy protocol with just the network 5-tuple (source/destination > > > address/port, protocol, client concurrency), enough to do some > > > simple reputation work. Seems like you had fleshed out a simliar idea a few years before, too: https://www.mail-archive.com/postfix-devel@postfix.org/msg00258.html > > > Perhaps it also makes sense for postscreen to make a postscreen-policy > > > call based on the information that it has collected with its dummy > > > SMTP engine. > > > > That's great news! The reason Christian is using tcp tables is that there's > > no > > postscreen API to call external policy services at the moment. If there was > > he/we would be eager to use that instead. > > Yes, I wanted the discussion to end on an optimistic note. Something to > work on in the train. I was just perusing the Change Log for the upcoming Postfix 3.3 release looking for a note referring to a postscreen policy delegation protocol. Did I miss the note? Did you loose interest? Missed the train? ;) p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Cyrus vs Dovecot for SASL AUTH and IMAP
* J Doe <gene...@nativemethods.com>: > I am looking to use either Cyrus or Dovecot for both SASL authentication and > IMAP. While Postfix 3.1.0 supports both, I was wondering which to prefer if > security is my most important deciding factor ? Does one have a better > track record than the other ? The Cyrus SASL project has been discontinued. I recommend not to use security relevant software that is unmaintained. Use Dovecot as password verification service for Postfix. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Postfix BIMI support?
Jonathan, BIMI adds an URI as header to a message. It is supposed to point to a location, where mail clients can download an image, which is supposed to show a brand indicator, vulgo "logo". Which kind of support would you expect from an MTA such as Postfix? p@rick Am 13.12.2017 um 09:38 schrieb Jonathan Sélea: > Recently stumpled upon BIMI; > > https://authindicators.github.io/rfc-brand-indicators-for-message-identification/#rfc.section.3 > > > What is your view on it? I think that BIMI is more a cosmetic thing > rather than something that prevent spoofing. > > Is there any plans to implement support for it in postfix? > > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein smime.p7s Description: S/MIME Cryptographic Signature
Re: can't get server to start postfix
you have a zombie master process hanging around. Stop postfix. Get a list of all running processes and check if there's a orphaned master process hanging around. Kill it. Start postfix. p@rick * Fazzina, Angelo <angelo.fazz...@uconn.edu>: > Hi, > All of a sudden postfix won't load ? where should I look next ? thanks. > > I tried > [root@mail2 postfix]# service postfix start > Starting postfix: [ OK ] > > > Logs show > Sep 7 16:50:47 mail2 postfix/postfix-script[3214]: starting the Postfix mail > system > Sep 7 16:50:47 mail2 postfix/master[3215]: fatal: open lock file > /var/lib/postfix/master.lock: cannot open file: Permission denied > > [root@mail2 postfix]# ls -l /var/lib/postfix/ > total 0 > -rw-r--r--. 1 postfix postfix 0 Sep 7 16:07 master.lock > > > > [root@mail2 postfix]# postconf -n > alias_database = hash:/etc/aliases > alias_maps = hash:/etc/aliases > command_directory = /usr/sbin > config_directory = /etc/postfix > daemon_directory = /usr/libexec/postfix > data_directory = /var/lib/postfix > debug_peer_level = 2 > html_directory = no > inet_interfaces = all > inet_protocols = all > mail_owner = postfix > mailbox_size_limit = 51200 > mailq_path = /usr/bin/mailq.postfix > manpage_directory = /usr/share/man > mydestination = $myhostname, localhost.$mydomain, localhost, appmail.uconn.edu > myhostname = mail2.uits.uconn.edu > mynetworks = 10.4.40.194 10.4.40.193 10.4.40.189 137.99.80.0/24 127.0.0.0/8 > [:::127.0.0.0]/104 [::1]/128 > newaliases_path = /usr/bin/newaliases.postfix > queue_directory = /var/spool/postfix > readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES > relay_domains = adm.uconn.edu $mydestination > sample_directory = /usr/share/doc/postfix-2.6.6/samples > sendmail_path = /usr/sbin/sendmail.postfix > setgid_group = postdrop > smtpd_tls_exclude_ciphers = IDEA-CBC-SHA, DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, > RC4, aNULL > unknown_local_recipient_reject_code = 550 > virtual_alias_maps = hash:/etc/postfix/virtual > regexp:/etc/postfix/maps/subaddressing > > -Angelo Fazzina > Operating Systems Programmer / Analyst > University of Connecticut, UITS, SSG, Server Systems > 860-486-9075 > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: sasl auth LOGIN / PLAIN
* mj <li...@merit.unu.edu>: > Hi, > > Ok, so disallowing LOGIN is not a clever move :-) Mandatory STARTTLS *and* disallowing any shared-secret mechanism (CRAM-MD5, DIGEST-MD5, NTLM) is a clever move. This way you protect the identity while it is transported from the client to the server and you are able to store the passwords crypted. p@rick > > Thanks for your answers! > > MJ > > On 09/02/2017 08:32 AM, Patrick Ben Koetter wrote: > > * postfix <post...@ayni.com>: > > > On 09/01/2017 04:25 PM, mj wrote: > > > > Just a small question: we currently use posfix with sasl authentication, > > > > and folowing many docs, we have enabled PLAIN and LOGIN authentication. > > > > > > > > However, googling leads me to believe that LOGIN is mostly used by > > > > Outlook Express, and that most (or all?) modern clients support the > > > > PLAIN mechanism. > > > > > > > > I also noticed that most failed authentication attempts are done using > > > > LOGIN. > > > > > > > > Now, assuming that most of these failed authentications are simply > > > > username/password guessing... how many problems would I expect, if I > > > > simply only offer PLAIN mechanism? > > > > > > > > It's hard to find info on what clients use what auth type. So, are > > > > all/most modern clients capable of doing PLAIN? (thunderbird, outlook > > > > 2010/2013) so could I simply disallow LOGIN? > > > > Thunderbird: > > PLAIN, DIGEST-MD5 > > Outlook 20**: > > LOGIN, NTLM > > > > > As far as I know, outlook does only LOGIN, even: because of outlook the > > > LOGIN mechanism was introduced. > > > > That is correct. > > > > p@rick > > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: sasl auth LOGIN / PLAIN
* postfix <post...@ayni.com>: > On 09/01/2017 04:25 PM, mj wrote: > > Just a small question: we currently use posfix with sasl authentication, > > and folowing many docs, we have enabled PLAIN and LOGIN authentication. > > > > However, googling leads me to believe that LOGIN is mostly used by > > Outlook Express, and that most (or all?) modern clients support the > > PLAIN mechanism. > > > > I also noticed that most failed authentication attempts are done using > > LOGIN. > > > > Now, assuming that most of these failed authentications are simply > > username/password guessing... how many problems would I expect, if I > > simply only offer PLAIN mechanism? > > > > It's hard to find info on what clients use what auth type. So, are > > all/most modern clients capable of doing PLAIN? (thunderbird, outlook > > 2010/2013) so could I simply disallow LOGIN? Thunderbird: PLAIN, DIGEST-MD5 Outlook 20**: LOGIN, NTLM > As far as I know, outlook does only LOGIN, even: because of outlook the > LOGIN mechanism was introduced. That is correct. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: chroot setting in master.cf
* Michael Fox <n...@mefox.org>: > > With Postfix 3, chroot is no longer the default. It remains an > > available option for people who want to go through the effort. > > > > Wietse > > Yes, but that wasn't my question. Again, my question was: > > I'm configuring master.cf to add amavisd-new. The amavisd-new documentation > (/usr/share/doc/amavisd-new/README.postfix.html) differs from the default > master.cf file regarding the chroot setting for the cleanup (and > pre-cleanup) service. I presume that the amavisd-new documentation is in > error and that I should go with the chroot setting that's in the default > master.cf. But I don't know enough about the implications of one vs. the > other to be sure. I wrote README.postfix.html for amavisd-new many years ago and I don't recall why master.cf was in the state it was by then. I wouldn't say it the documentation is in error - it's has simply not seen any update in many years. Personally I don't use content_filter and smtpd_proxy_filter anymore. I prefer the MILTER interface over the other methods. If you are interested in this and if you can read German (or are able to handle google translate ;) you may read my blog https://sys4.de/de/blog/2015/07/31/amavisd-milter-howto/ for instructions. > Specifically, I have three questions: > > 1) Section 4.2.1 of the above web page shows adding a pre-cleanup service > with chroot=n. But the default master.cf (from Ubuntu) has the cleanup > service configured > with chroot=y. Should I use the same chroot=y setting for the pre-cleanup > service? > > 2) Section 4.2.2 of the above web page shows modifying the existing cleanup > service to add some "-o" options. But it shows the cleanup service with > chroot=n. Should I leave chroot=y for the cleanup service? > > 3) The above web page also shows the new "amavisfeed" and "127.0.0.1:10025" > services with chroot=n. But similar services in master.cf have chroot=y. > Should these two new services also use chroot=y? The all general answer is: If you plan to run Postfix chrooted, chroot as much as you can. It's a design question. Chrooting a service like Postfix comes at the price of quite some management overhead. You can automate most of that, but you need to take care of it. Many years ago Wietse wrote chrooting Postfix only makes sense on a hardened server. I agree with that. If the server isn't hardened, forget to chroot the service as there are very likely much more easily exploitable "entry points" to the server. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: postscreen fail2ban filter
* Wietse Venema <postfix-users@postfix.org>: > Scott Techlist: > > As I watch the bots and spammers hammer my server with connection attempts, > > I figured I might as well stop them even closer to the front door when they > > try repeatedly. > > > > I have fail2ban running already and once I enabled postscreen it didn't seem > > to have much to do anymore. > > > > My primary question is: Can I filter on the DISCONNECT log line for bad > > connections (and only bad connections), or do some "good" connections also > > log a DISCONNECT. > > Postcreen logs DISCONNECT for clients that PASS the "after 220 > greeting" tests (bare newline, non-SMTP command, pipelining). > > I don't think there is much to gain from parsing postscreen logging > to produce fail2ban rules. postscreen is designed to handle a lot > of abuse with near-zero resources. To add my 2ct: As long as it doesn't impose a problem on the application I prefer to 'see' the disconnects in the application and not on some other host (read: upstream firewall). This makes it easier for me to see relationships etc. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Seperate maps for virtual domains?
* Wietse Venema <postfix-users@postfix.org>: > Patrick Ben Koetter: > > * Viktor Dukhovni <postfix-users@postfix.org>: > > > On Mon, Jun 12, 2017 at 10:32:18AM +0200, Patrick Ben Koetter wrote: > > > > > > > * Julian Kippels <kipp...@hhu.de>: > > > > > would it be faster to have several smaller files for alias_maps and > > > > > transport_maps for each virtual domain, or have one giant file each > > > > > with > > > > > all users domain from all virtual domains in one file? Around 90% of > > > > > traffic is for one domain and the rest is split among 32 other domain. > > > > > > > > Hard to tell. If they are static, binary maps Postfix will read them > > > > all into > > > > memory and work with the in memory copies. So you don't gain any speed > > > > improvements from a giant file. > > > > > > A single CDB, LMDB or Berkeley DB file is much more efficient than > > > multiple smaller files. > > > > At which message throughput rate will this make a difference? > > Always. Because you're replacing hashing with linear search. If you compare hashing to linear search, yes. But I am not sure this is what the OPs question was about? He wrote "would it be faster to have several smaller files (...) or have one giant file". The way I understood it, he would not compare hashing vs. linear search, but many small(er) hashed maps vs. one large hashed map. I understood the latter and that's why I came up with the question of "message throughput rate". The goal I am heading for is: If someone runs a platform at x msg/sec and x is below the threshold where message throughput rate sinks because of "too many small maps" why bother. Stick with many small maps if you gain any other advantage until then. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Seperate maps for virtual domains?
* Viktor Dukhovni <postfix-users@postfix.org>: > On Mon, Jun 12, 2017 at 10:32:18AM +0200, Patrick Ben Koetter wrote: > > > * Julian Kippels <kipp...@hhu.de>: > > > would it be faster to have several smaller files for alias_maps and > > > transport_maps for each virtual domain, or have one giant file each with > > > all users domain from all virtual domains in one file? Around 90% of > > > traffic is for one domain and the rest is split among 32 other domain. > > > > Hard to tell. If they are static, binary maps Postfix will read them all > > into > > memory and work with the in memory copies. So you don't gain any speed > > improvements from a giant file. > > A single CDB, LMDB or Berkeley DB file is much more efficient than > multiple smaller files. At which message throughput rate will this make a difference? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Seperate maps for virtual domains?
* Julian Kippels <kipp...@hhu.de>: > would it be faster to have several smaller files for alias_maps and > transport_maps for each virtual domain, or have one giant file each with > all users domain from all virtual domains in one file? Around 90% of > traffic is for one domain and the rest is split among 32 other domain. Hard to tell. If they are static, binary maps Postfix will read them all into memory and work with the in memory copies. So you don't gain any speed improvements from a giant file. It might be more comofortable to work with many files (one per domain) or better to organize. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Spam Quarantine Folder
* Henry <der...@gmail.com>: > Firstly I am unsure if this question is related to Postfix, > Spamassasin, Amavasid.. amavis > I am using Kolab for email and almost everything is working well with > spam being partially filtered. > > My problem is when spam is moved to quarentine is it moved to > "/var/lib/amavis/virusmails" > https://wiki.kolab.org/Fighting_spam#Spam_Quarantine_Shared_Folder > > As each user has an individual "Spam" email folder I would like spam > emails to be moved to the individual user's spam folder instead where > the individual user can then review them. > > /var/spool/imap/domain/m/mydomain.com/h/user/henry/Spam# > > I have researched this without success: > https://wiki.apache.org/spamassassin/IntegratedInPostfixWithAmavis > > Can anyone point me in the direction how this can be configured please Configure amavis to tag and D_PASS spam and use a SIEVE rule to deliver tagged spam messages into the desired folder. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Issue with SASL authentication
Daniel, * Daniel Bareiro <daniel-lis...@gmx.net>: > So it's all limited to that saslauth is not able to authenticate without > the realm. What I can not find out is why this happens. I do not see the > difference in the configuration between both servers. > > In any case, it seems that Cyrus IMAP is able to run smoothly. But it's > not the same with Postfix. Anyway I'm still thinking what can differ > between both servers so that the authentication without realm does not > work here. I have no idea why the domain needs to be appended on one machine and doesn't have to on another one, but *if* all your SASL users are within the same domain (realm) Postfix can 'add' it for you. Assuming 'server2' is your domain/realm put this in main.cf: smtpd_sasl_local_domain = server2 p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: startup process that rebuilds aliases.db?
* Robert Moskowitz <r...@htt-consult.com>: > My system does not have a battery for the clock (like most armv7 SOCs), thus > I rely on that at some point in boot time, chronyd sets the time. If a file > is updated prior to chronyd accomplishing its task (or network connectivity > is down), the file ends up with a timestamp of "Dec 31 1969". > > I notice that occasionally, after a reboot, /etc/aliases.db reverts to this > time, and I have to run newaliases to fix it. I suppose I could run touch > as well. > > So is postfix startup rebuilding aliases.db, perhaps? Is there some way to It isn't. Something else must tamper your data. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: growing size of mail.log file - postfix logs
* Poliman - Serwis <ser...@poliman.pl>: > Hi everyone. In mail.log file I have many lines like below: > Mar 2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: SSL_accept error from > house.census.shodan.io[89.248.172.16]: -1 > Mar 2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: warning: TLS library > problem: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong version > number:s3_srvr.c:966: Postfix refuses to use SSLv3. > Mar 2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: lost connection after > CONNECT from house.census.shodan.io[89.248.172.16] > Mar 2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: disconnect from > house.census.shodan.io[89.248.172.16] > Mar 2 06:53:30 vps342401 postfix/smtps/smtpd[14637]: lost connection after > CONNECT from house.census.shodan.io[89.248.172.16] house.census.shodan.io tries to connect your Postfix server and then nothing happens. Unless every other host has this problem too, you will have to talk to the people who run house.census.shodan.io to find out why their client doesn't proceed with a SMTP session. Chances are their hosts problem is, it is unable to use any other/newer TLS protocol version. > and > > Mar 2 07:15:01 vps342401 dovecot: pop3-login: Disconnected (no auth attempts > in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, > session= > Mar 2 07:20:01 vps342401 dovecot: imap-login: Disconnected (disconnected > before auth was ready, waited 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, > secured, session=<+TxOa7lJ/AB/AAAB> > Mar 2 07:20:01 vps342401 dovecot: pop3-login: Disconnected (no auth attempts > in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, > session= > Mar 2 07:25:01 vps342401 dovecot: imap-login: Disconnected (disconnected > before auth was ready, waited 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, > secured, session= Something - a program ? - on your server connects to your dovecot service and disconnects. Find out what it is. > From two days log file has 18MB. What is wrong? The log size is not necessarily an indicator that something is wrong on your machine. On busy machines 18 MB growth is a matter of minutes. How recurring are the errors in the LOG? Is it always the same error? Is it always the same host having problems with your server? p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Question about milters
* Linda Pagillo <lpad...@gmail.com>: > Thank you for this Patrick. My problem is, I want to disable the milter for > outgoing authenticated email on those ports, not enable the milter for > them. Also.. I want the milter to still run on non-authenticated email. For > example... u...@domain.com is a valid user on the server. They want to send > mail out on ports 25... I would want to the milter to bypass this because > they are authenticated. Now... if spam...@domain.com tries to send mail out > of the server on port 25 and they do not authenticate, I want the mitler to > run. Is this possible? If you are able to split authenticated from unauthenticated traffic by ports Postfix can do that for you. In this case follow the example I sent in my previous mail. If you cannot split authenticated from unauthenticated traffic two approaches come to my mind: SNFMilter Use a mechanism in SNFMilter to tell authenticated from unauthenticated senders. A quick glance at the INSTALL file suggest it might be possible to signal SNFMilter should become active by setting x-headers. I am not familiar with the product. Maybe someone else on this list or on a SNFMilter-related list has more information on that. split traffic by IP Get a new IP for your mail service and configure Postfix to use that one too. Announce the new IP as MX. From now on all external traffic will enter your mail system via the new IP. Scan all traffic on the new IP using SNFMilter. Do not scan traffic on the old IP. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Question about milters
* Linda Pagillo <lpad...@gmail.com>: > I have only one smtpd_milter and no non_smtpd_milters. The one milter I'm > using is called SNFMilter. It's an anti-spam milter that I use from Arm > Research. I have a configuration file called SNFMilter.xml and in the > main.cf I have the following line: smtpd_milters = unix:/path/to/socket I suggest you remove the smtpd_milters setting from main.cf, because if you put it there it will affect any Postfix smtpd daemon in your Postfix instance. But don't throw it away. Instead move it to master.cf (see my example below) and associate it only with Postfix smtpd daemons that serve ports where you want SNFMilter to become active. My example enables SNFMilter for 25 and disables any other MILTER for 587 and 465: # == # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (no)(never) (100) # == # Port 25 smtp inet n - n - - smtpd -o smtpd_milters=unix:/path/to/socket # Port 587 submission inet n - n - - smtpd -o smtpd_milters= ... # Port 465 smtps inet n - n - - smtpd -o smtpd_milters= ... If you don't have much experience with Postfix yet, pay special attention to notation in master.cf. Versions before 3.0 require *no space* between a parameter and the associated values, e.g. parameter=value. My example above follows this advice. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Question about milters
* Linda Pagillo <lpad...@gmail.com>: > Good day everyone. I have a quick question about a milter that I'm using. > I'm running Postfix 3.x. The milter is called SNFMilter and it uses a Unix > socket instead of inet. My question is a general question about milters. Is > there a way to bypass a milter for authenticated senders who are sending on > posts 25, 587 and 465? I know I can bypass all of Postfix antispam for > authenticated senders, but that is not what I want to do. I just want to > bypass the milter for these outbound senders. Is that even possible? Thanks > for all and any help. If you run separate instances for all the ports you mentioned, you can provide individual, per instance lists of smtpd_milters. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
Re: Postfix 20 years ago
* Wietse Venema <wie...@porcupine.org>: > Last month it was 20 years ago that I started writing Postfix code. > After coming to IBM research in November 1996, I spent most of > December and January making notes on paper. I knew that writing a > mail system was more work than any of my prior projects. Eversince I discovered Postfix it has become the best software I have had the joy to work with. The code quality is outstanding as is the documentation. One of the main reasons to stick with Postfix from the very first moment was its community - friendly, knowledgable and helpful. Unfortunately I don't like Postfix for its reliabilty and stability. It is so reliable and stable that I am forced to turn away from it. It forces me to deal with software of lesser quality, badly written configuration syntax, absent documentation, horrible security architecture etc. pp. I hate it when Postfix does that to me. ;) Postfix is Postfix because you made it that way. It breathes your spirit, Wietse - your standards, your strictness and your mindset. I've learned a lot from you over all the years. Postfix is my role model for good software. When we build tools, services, platforms I often catch myself thinking "How would Postfix do that?". I owe you a lot! Thank you p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: PostgreSQL+Postfix inquiry
* Jeremy T. Bouse <jeremy.bo...@undergrid.net>: > I'm going ahead and asking here as I've been searching and haven't > found any information... > > I've been using PostgreSQL, and MySQL in the past, to hold virtual user > information for my Postfix server. The only thing that has bothered me > is every *sql_*.cf file I had to setup had to have the username, > password and host to use for the DB connection. Am I completely missing > it or is there a way to set that information in one location for all the > database queries to utilize? ATM this is as good as it gets. Postfix has no means to e.g. include files in a configuration e.g. like this: include = /etc/postfix/dbsettings.cf You *could* put all query settings in main.cf, *but* main.cf must remain world readable. This effectively exposes the db connection settings (and all other secrets) to any user, who has access to the machine. I guess you don't want that. If you use configuration management you can have it create the query files. But setting one up only to get around the redundant work is in no relation to the few minutes you spend to write the user/pass etc. a few times. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
HAPROXY protocol version?
Greetings, I'm trying to find out which version (1,2) of the haproxy protocol Postfix supports. I couldn't find any reference in the documentaton nor in the src files. Is there any and I missed it? Thanks, p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: short circuit content_filters
* Michael Munger <mich...@highpoweredhelp.com>: > > > Fix it in spamassassin. Use whitelist_from or better whitelist_from_dkim. > > See "perldoc Mail::SpamAssassin::Conf" for config instructions. > > Seems legit. How do I configure SpamAssassin to look up the domain in MySQL? There may be a way to do that. But I think it would be better to ask this on the Spamassassin Mailing list. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: short circuit content_filters
* Michael Munger <mich...@highpoweredhelp.com>: > TLDR: > > How do I configure Postfix to NOT use spamassassin to scan the email if > it is coming from a domain that is whitelisted via check_sender_access? Fix it in spamassassin. Use whitelist_from or better whitelist_from_dkim. See "perldoc Mail::SpamAssassin::Conf" for config instructions. Alternatively put amavis in between Postfix and Spamassassin and exempt the domains from spam filtering. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
ANN: vim syntax highlighting for Postfix
vim comes with syntax highlighting for Postfix, but the syntax file is outdated and doesn't cover LDAP and other drivers. For those who like an up to date syntax highlighting that reflects your Postfix installation take a look at https://github.com/sys4/vim-postfix. Christian (Rößner) took the time to create two scripts that will create syntax files. The README tells how to install them. Worked out of the box for me. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Feature-request] (smtpd_)milter_exceptions
Am 25.10.2016 um 13:31 schrieb Wietse Venema: > Wietse Venema: >> I've implemented the second variant. If you maintain configurations >> by hand, then excluding mynetworks will be a bit of extra work. I >> recommend that configurations aren't maintained by hand. > John @ KLaM: >> Do you have any suggestions/recommendations for a maintenance system. > Not specifally. In the past years I have main.cf and master.cf > configurable with "postconf" commands, to make the job easier for > configuration tool writers. I'll leave writing such tools to the > people who are in the business of managing postfix systems. Here's one of many ways to acchieve this: https://github.com/sys4/postfix-formula p@rick smime.p7s Description: S/MIME Cryptographic Signature
Re: [Feature-request] (smtpd_)milter_exceptions
* Wietse Venema <postfix-users@postfix.org>: > Christian Ro??ner: > > Possible situation: Central SMTP-hub that gets connections from > > MX-ins and internal servers, ... > > I have a simpler solution: separate those mail streams with separate > MTA instances. That avoids the complexity of adding exceptions to > main.cf, milters, ... > > Different streams can have different filters/milters, which is more > flexible than a milter on/off switch. > > The two MTA instances can run on the same host (bound to different > IP addresses) or on separate hosts. I expected this answer and obviously it makes sense to suggest this solution at first. We came up with that approach too, but had to give it up once we had a closer look at the environment the service runs in. It is not always possible to use an additional IP address or port. Christian's RFE deals with exact these scenarios. We would use the simplier approach if it were possible. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: postscreen-policy (was: Feature request for postscreen: "defer")
* Wietse Venema <postfix-users@postfix.org>: > Wietse Venema: > > Unlike DNS lookups, the access map lookup is a blocking operation, > > and if your tcp map takes 80ms to complete (a typical trans-atlantic > > query), then you can handle only 12 connections per second, and > > make postsceen the largest performance bottleneck on the system. > > After starting work on postscreen by the middle of 2009, I soon > realized that I might have to add some postscreen-policy interface > for things that are too complex or that take too much time compared > to a quick access map lookup. Perhaps the time has come. > > Basically this would be a very small subset of the SMTP server > policy protocol with just the network 5-tuple (source/destination > address/port, protocol, client concurrency), enough to do some > simple reputation work. > > Perhaps it also makes sense for postscreen to make a postscreen-policy > call based on the information that it has collected with its dummy > SMTP engine. That's great news! The reason Christian is using tcp tables is that there's no postscreen API to call external policy services at the moment. If there was he/we would be eager to use that instead. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Feature-request: rfc5322_from_login_maps
* Wietse Venema <postfix-users@postfix.org>: > Dominik Chilla: > > Hello together, > > > > my postfix setup (submission-relay only!) requires an authenticated > > (SMTP-AUTH plain/login) sender. Further it checks if the envelope-sender > > matches the authenticated user-id by using sender_login_maps in > > conjunction with LDAP. In envelope context this is a very usefull and > > important feature, but it doesn?t prevent one to use a different email > > address in the RFC5322-From header. So why not thinking about something > > like rfc5322_from_login_maps? > > > > Alternatively a restriction > > "reject_rfc5322_from_envelope_sender_mismatch" (or the like) would be > > thinkable. > > Do you have a design for that? Note that most reject_mumble features > are designed to block mail BEFORE the "DATA" command, whereas the > message header is received AFTER the DATA command. > > You might be better off implementing this with a Milter IIRC Christian wrote a MILTER that does exactly what you want about two years ago. I'm not sure if he's willing or able to release it as open source. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Time based config options
* Alex Bryant <alex.bry...@trancos.com>: > Was looking for the best strategy for implementing time based config file > options. > > > For instance, implement the following from 8-9:00 am and 4-5:00 pm only: > > virtual_alias_maps = pcre:/etc/postfix/virtual_alias_maps_regex_1 Create a cronjob. Let it execute somehing along the lines of: postconf -e 'virtual_alias_maps = pcre:/etc/postfix/virtual_alias_maps_regex_1' p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: postfix password authorisation not working
* Zalezny Niezalezny <zalezny.niezale...@gmail.com>: > Hi, > > I just woudl like to know what I`m doing wrong. > I read postfix documentation several times and I configured SASL > authentication exacly as it was described. But even with this I do not see > in the telnet output lines similar to this > > 250-AUTH DIGEST-MD5 PLAIN CRAM-MD5 > > > This is my telnet output: > > ehlo localhost > 250-ip-172-31-28-250.eu-central-1.compute.internal > 250-PIPELINING > 250-SIZE 1024 > 250-VRFY > 250-ETRN > 250-STARTTLS > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250 DSN > > > This is my main.cf configuration: > # ### > #TLS > smtpd_tls_auth_only = yes If you enable smtpd_tls_auth_only you will see AUTH only in a a TLS session. Use swaks and let it AUTH in a TLS session. By default it sends the session output to STDOUT and you should be able to see everything. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Postfix penetration test
* li...@lazygranch.com <li...@lazygranch.com>:
> body { font-family: "Calibri","Slate
> Pro",sans-serif,"sans-serif"; color:#262626 } lang="en-US">Any suggestions on a penetration test program that will
> trigger sshguard or fail2ban from the maillog?
>
Send lots of HTML markup?
Use swaks and a script and let it send mail that is supposed to trigger the
rules.
If you need massiv mail: Use mstone and let it send mail that is supposed to
trigger your rules.
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Blocking email from specific IPs
* Viktor Dukhovni <postfix-users@postfix.org>: > > > On May 14, 2016, at 3:21 PM, Christian Kivalo <ml+postfix-us...@valo.at> > > wrote: > > > >> smtpd_recipient_restrictions = > >> ... > >> check_client_access > >> hash:/etc/postfix/client_checks, > >> ... > >> $ cat /etc/postfix/client_checks > >> ... > >> 138.185.116.0/24 REJECT > > > > This looks correct. > > And yet it is wrong, look closely. Hint: The notation is correct. It's the logic (aka: driver/map type) you use to make sense of it. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Content Filter only for incoming mails
* BP20 <dsehlh...@leds-com.de>:
> Hello,
>
> i am new to this.
> I am trying to set up a content filter for incoming postfix mails.
> I am using this instruction:
> http://www.postfix.org/FILTER_README.html#simple_filter
> <http://www.postfix.org/FILTER_README.html#simple_filter>
>
> --- master.cf snippet ---
> smtp inet n - - - - smtpd
> -o content_filter=filter:dummy
> filterunix - n n - 10 pipe
> flags=Rq user=filter null_sender=
> argv=/var/spool/filter/afterqueue.sh -f ${sender} -- ${recipient}
>
>
> The problem is, that the filter is also applied to outgoing mails.
> I don't really understand that "-o content_filter=filter:dummy" line. Should
> "filter:dummy" be replaced?
Nope.
Your problem very likely is that your Postfix server currently is unaware of
directions. It can't tell what is incoming nor can it tell what is outgoing.
> So how can i set it up, so that it is only used for incoming mails?
Use a dedicated submission instance (master.cf) to submit outbound mail.
p@rick
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Re: Dane for smtpd
* Brad Chandler <brad.chand...@mbchandler.net>: > I've set up DNSSEC and the TLSA records for my domains. And I think > I have setup dane for smtp correctly in Postfix. I see "Verified TLS > connection established to" in my logs when connecting to a server > with TLSA records. > > Should I also be seeing "Verified TLS connection established from" > when someone using dane connects to my server? I've used several > validators such as https://dane.sys4.de/smtp/mbchandler.net, and > they all say that everything is correct. No you shouldn't. Actually you can't. DANE, as it is today, does not provide any means for mutual verification. At the moment you will only see "Verified TLS …" on the client side. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: SPF
If you find it on http://www.postfix.org/postconf.5.html it is part of Postfix. If not, someone else added it and it is not part of Postfix or it doesn't exist at all. Patrick Am 01.03.2016 um 10:19 schrieb JosC: > Just upgraded to Postfix 3 - thanks for this release! > With SPF validation I now get stuck on following in my main.cfg: > > Feb 29 10:14:33 ceto postfix/smtpd[50770]: warning: unknown smtpd > restriction: "reject_spf_invalid_sender" > Feb 29 10:14:33 ceto postfix/smtpd[50773]: warning: unknown smtpd > restriction: "permit_spf_valid_sender" > > Can you tell me how to solve this? > > Thanks, > Jos Chrispijn > > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein smime.p7s Description: S/MIME Cryptographic Signature
Re: Postfix Mailman integration
* @lbutlr <krem...@kreme.com>: > On Sun Feb 28 2016 19:56:48 Ruben Safir <ru...@mrbrklyn.com> said: > > > > Maybe I'm just in a bad mood, but my view of mailmans software > > archetecture, at this point, is very low. He tries very hard to help > > people and to work on it, but I think it is broken at the core. > > I am not currently hosting any mailing lists, but I have used mailman for > many years in the past, and I find this statement is not indicative of the > software I ran. At python.org we currently run ~300 hundred mailing lists without any issues at all. We've been running them for about 10 years without any problems. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Permissions
John,
you might want to play around with a script I started a while ago. I don't
recall if I finished it. I think it did the job well enough to stop working on
it at that time.
p@rick
* John A @ KLaM <j...@klam.ca>:
> Recently there was a discussion about file permissions and ownership.
> My postfix setup is as far as I know fairly conventional Debian stretch.
>
> /etc/postfix root root 755
> Main.cf root root 644
> Master.cf root root 644
>
> /etc/postfix/maps root root 755
> Map, pcre etc root root 644
>
> /etc/postfix/sasl root root 755
> --
>
> /etc/postfix/sql root root 755
> sql ? ? 644
>
> Would I be better with directories as 750
> and files as 640.
>
> Ownership = postfix in all cases.
>
>
--
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
#!/bin/bash
# Pruefe Permission, Ownership und Groupwnership aller MAPS, die Postfix
# aktuell eingebunden hat sowie seiner Konfigurationsdateien und Helferskripte.
# Korrigiere die Werte wenn sie abweichen und melde die Aktion.
# Patrick Ben Koetter <p...@sys4.de>
# Map-Dateien
MAP_PERMS='640'
MAP_OWNER='root'
MAP_GROUP='postfix'
# Konfigurationsdateien
CONF_PERMS='644'
CONF_OWNER='root'
CONF_GROUP='postfix'
# Shared Files
SHARED_PERMS='644'
SHARED_OWNER='root'
SHARED_GROUP='postfix'
# Zertifikate
CERT_PERMS='400'
CERT_OWNER='root'
CERT_GROUP='postfix'
# Skripte
SCRIPT_PERMS='750'
SCRIPT_OWNER='root'
SCRIPT_GROUP='postfix'
#
# Ab hier nur noch Programm
# Multiple instance config dir uebergeben
while getopts ":c:" opt; do
case $opt in
c)
INSTANCE_DIR=$OPTARG
;;
\?)
echo "Invalid option: -$OPTARG" >&2
exit 1
;;
:)
echo "postperms: fatal: usage: option -$OPTARG requires an argument." >&2
exit 1
;;
esac
done
# Oder default config dir verwenden
CONFIG_DIR=${INSTANCE_DIR:-"/etc/postfix"}
# Map-Dateien
# Alles was Postfix in ein file auslagern könnte
declare -a MAPS=$(postconf -c $CONFIG_DIR -xh
address_verify_sender_dependent_default_transport_maps \
address_verify_sender_dependent_relayhost_maps
address_verify_transport_maps \
alias_maps canonical_maps fallback_transport_maps \
lmtp_discard_lhlo_keyword_address_maps lmtp_generic_maps
lmtp_pix_workaround_maps \
lmtp_sasl_password_maps lmtp_tls_policy_maps local_recipient_maps
mailbox_command_maps \
mailbox_transport_maps postscreen_discard_ehlo_keyword_address_maps \
rbl_reply_maps recipient_bcc_maps recipient_canonical_maps \
relay_recipient_maps relocated_maps sender_bcc_maps sender_canonical_maps \
sender_dependent_default_transport_maps sender_dependent_relayhost_maps \
smtp_discard_ehlo_keyword_address_maps smtp_generic_maps
smtp_pix_workaround_maps \
smtp_sasl_password_maps smtp_tls_policy_maps
smtpd_discard_ehlo_keyword_address_maps \
smtpd_sender_login_maps transport_maps virtual_alias_maps virtual_gid_maps \
virtual_mailbox_maps virtual_uid_maps bounce_template_file \
body_checks header_checks lmtp_body_checks lmtp_header_checks
lmtp_mime_header_checks \
lmtp_nested_header_checks milter_header_checks mime_header_checks
nested_header_checks \
smtp_body_checks smtp_header_checks smtp_mime_header_checks
smtp_nested_header_checks)
for i in ${MAPS[@]}
do
# Treiberangaben entfernen
FILE="${i/#*:/}"
# Es muss ein Pfad "/.." sein
if [[ ${FILE} == /* ]];
then
chmod -c ${MAP_PERMS} ${FILE}
chown -c ${MAP_OWNER} ${FILE}
chgrp -c ${MAP_GROUP} ${FILE}
fi
done
# Postfix Konfigurationsdateien
declare -a CONFS=(main.cf master.cf dynamicmaps.cf)
for FILE in ${CONFS[@]}
do
chmod -c ${CONF_PERMS} ${FILE}
chown -c ${CONF_OWNER} ${FILE}
chgrp -c ${CONF_GROUP} ${FILE}
done
# Shared Files
declare -a SHARED=(domains)
for FILE in ${SHARED[@]}
do
chmod -c ${SHARED_PERMS} ${FILE}
chown -c ${SHARED_OWNER} ${FILE}
chgrp -c ${SHARED_GROUP} ${FILE}
done
# Zertifikate
declare -a CERTS=$(postconf -c $CONFIG_DIR -xh lmtp_tls_cert_file
lmtp_tls_dcert_file \
lmtp_tls_dkey_file lmtp_tls_eccert_file lmtp_tls_eckey_file \
lmtp_tls_key_file lmtp_tls_trust_anchor_file smtp_tls_cert_file \
smtp_tls_dcert_file smtp_tls_dkey_file smtp_tls_eccert_file \
smtp_tls_eckey_file smtp_tls_key_file smtp_tls_trust_anchor_file \
smtpd_tls_cert_file smtpd_tls_dcert_file smtpd_tls_dh1024_param_file \
smtpd_tls_dh512_param_file smtpd_tls_dkey_file smtpd_tls_eccert_file \
smtpd_tls_eckey_file smtpd_tls
ANN: savacli - Avira SAVAPI command-line client
Greetings, I'd like to announce the release of savacli. It is a command-line client for AVIRAs OEM Antivirus engine SAVAPI. You may download sources and documentation at https://github.com/sys4/savacli. The client 'savacli' was built in a project for a German company that wants to remain anonymous. However they expressed a strong want to release savacli as Open Source Software - a natural desire we hereby gladly follow. :) Regards p@rick For those who don't know AVIRA <http://www.avira.com>: AVIRA builds one of the fastest and most effective AV-scanners on this planet. Being an AVIRA technology partner we implement and enhance their scanner on UNIX platforms. -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Security: How to limit authentication attempts?
* Kiss Gábor <ki...@niif.hu>: > Dear folks, > > My logs are full of lines like this: > > Feb 21 04:12:05 MYOLDMTA postfix/smtpd[12967]: warning: > unknown[195.22.126.159]: SASL LOGIN authentication failed: authentication > failure > > This is a brute force attack in order to get a valid username/password pair. > The cracker usually does 20 attempts within a single SMTP session. > Thought fail2ban alerts the firewall after the third or fourth one but > network filtering applies to new connections only. > (I would not filter _all_ incoming packets until it is > absolutely necessary.) > > So the attacker may try any number of password quite unobtrusively. > > Is there any way to instruct smtpd to close session after 3 unsuccesful > attempts as is written in RFC 4954? I found no appropriate config parameter. Either use postfwd2 or write your own policy server. For permanent blocks use check_sasl_access (newer Postfix only) and let it read a list of blocked logins. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: postfix installation and make error (ATTENTION: Unknown system type)
* timos <importantaccou...@gmail.com>: > I'm new to Postfix. I tried to compile postfix-2.11.3 but ran into an error > and failed with following message: > > make -f Makefile.in MAKELEVEL= Makefiles > (echo "# Do not edit -- this file documents how Postfix was built for your > machine."; /bin/sh makedefs) >makedefs.tmp > ATTENTION: > ATTENTION: Unknown system type: Linux 4.1.13-19.31.amzn1.x86_64 > ATTENTION: > make: *** [Makefiles] Error 1 > make: *** [Makefiles] Error 2 > > I've gone through all possible solution but can't figure out any! > ... any help or fix is appreciated. :( This Postfix version does not recognise Kernel 4.x. IIRC recent snapshots will recognise it. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: body_checks with postscreen. Test works at blocking, but 'real mail' slips through?
* bi...@sent.at <bi...@sent.at>: > Hi Patrick > > Thanks for the reply. > > > To clarify: postscreen never sees a message body. It probes the client IP > > and > > fakes a few SMTP commands, but that's it. > > Ok, took me a couple of rereads, but it's not postscreen doing the check. > It's that postscreen is "part 1" of several checks. > > > The right [tm] method would be to use the postconf utility and let it return > > the parameter setting: > > > > % postconf -n body_checks > > > > If it does not return anything chances are you mistyped the parameter or > > something similiar. (That's make makes postconf better than grep). > > Ok got that. Still looks good. > > postconf -n body_checks > body_checks = pcre:/etc/postfix/body_checks.pcre > > > Save the message to a file. And test like this: > > > > % postmap -q - pcre:/etc/postfix/body_checks.pcre > So does this. > > cat << EOF > /tmp/testfile > TEST BAD CONTENT > EOF > postmap -q - pcre:/etc/postfix/body_checks.pcre TEST BAD CONTENT REJECT 554 5.7.1 Message not allowed You are proving a test with a probe that isn't in question. Test with the message that failed the test. If your Postfix config is correct, then the answer lies within the message you sent. And while you're at it: Please send complete output of 'postconf -n' so we can get a complete picture. ;) p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: body_checks with postscreen. Test works at blocking, but 'real mail' slips through?
* bi...@sent.at <bi...@sent.at>: > Hi > > I'm building my 1st Postfix server and working on getting Postscreen setup. > > I RTFM here > > http://www.postfix.org/POSTSCREEN_README.html > > Where it says > > The third layer performs light-weight content inspection with the Postfix > built-in header_checks and body_checks. This can block unacceptable > attachments such as > executable programs, and worms or viruses with easy-to-recognize signatures. To clarify: postscreen never sees a message body. It probes the client IP and fakes a few SMTP commands, but that's it. However your content test should work. > So in my main.cf I added > > body_checks = /etc/postfix/body_checks.pcre > > Checked that it's in there > > postconf -n | grep body_checks > body_checks = /etc/postfix/body_checks.pcre The right [tm] method would be to use the postconf utility and let it return the parameter setting: % postconf -n body_checks If it does not return anything chances are you mistyped the parameter or something similiar. (That's make makes postconf better than grep). > and edited > > /etc/postfix/body_checks.pcre > /TEST BAD CONTENT/ REJECT 554 5.7.1 Message not allowed > > Then I test it with > > postmap -q "TEST BAD CONTENT" pcre:/etc/postfix/body_checks.pcre > REJECT 554 5.7.1 [P5] Message not allowed > > So it looks ok to me. > > But then I send myself a test message from gmail, making sure the text "TEST > BAD CONTENT" is in the body. > > And it passes right through :-( Save the message to a file. And test like this: % postmap -q - pcre:/etc/postfix/body_checks.pcre https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: How to configure postfix so that mail are received using time from the server
* Alice Wonder <al...@domblogger.net>: > On 01/15/2016 11:10 PM, Robert Schetterer wrote: > >Am 16.01.2016 um 08:05 schrieb Eric Kom: > >>Good day folk, > >>I ran Postfix with Dovecot as a mailbox for years now. > >>I noticed that, when a sender sent mails, the mailbox received it using > >>the date and time from the sender machine not a server one. > >>Which make the receiver mailbox saving the mails at the wrong time. > >>Please can someone help me if something have to be done regarding this > >>issue? > >>Thanks > >> > > > >do you mean issue to fix with this plugin ? > > > >https://addons.mozilla.org/de/thunderbird/addon/imap-received-date/?src=search > > > >Best Regards > >MfG Robert Schetterer > > > > Oh wow, as a thundirbird user very annoyed with that issue that > thought it was something I just had to live with - thank you! By RFC the mail client MUST provide the date header, as it states the date the message was written (and not sent). If it is absent Postfix will add the date (under circumstances). If you can fix the date issue in the senders client. That would be the right [tm] solution. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Question to postscreen and memcache...
* Wietse Venema <postfix-users@postfix.org>: > Django [BOfH]: > > Hi List, > > > > while looking to the Postfix-Doku under: > > > > http://www.postfix.org/POSTSCREEN_README.html#temp_white_sharing > > > > we keep an eye on the Example 4: > > As documented, the whitelist in that example "can be shared only > between postscreen(8) daemons that run under the same master(8) > daemon". > > > Following statemant was written to "Example 4" at the Postfix-Doku: > > A non-persistent memcache: temporary whitelist can be shared between > > postscreen(8) daemons on the > > ---> same host or different hosts. <-- > > There is no such statement for "Example 4" in the documentation at > http://www.postfix.org/POSTSCREEN_README.html Would it be possible to come up with something that allows to run a cluster of Postfix hosts, sharing a temporary postscreen whitelist? It would be desireable to serve a consistent policy throughout all cluster nodes. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
