Re: dnssec DS set, but no RRSIG
On 2021-11-15 11:36:00 (+0800), Benny Pedersen wrote: plantmarknaden.com https://dane.sys4.de/smtp/plantmarknaden.com https://dnsviz.net/d/plantmarknaden.com/dnssec/ why diffrent results ? I don't see 'different' results. That domain is broken. Neither of the listed DNS servers are returning DNSKEYs. Even if they returned RRSIGs with their responses (which they don't), nobody could validate them. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: SPF and DKIM and DMARC records for a relay, on my !
On 2021-06-29 02:09:10 (+0800), White, Daniel E. (GSFC-770.0)[NICS] wrote: We are trying to understand all of these because we will be required to use them eventually. I am getting my info at https://www.dmarcanalyzer.com/spf/ If we add an IP to our SPF record, is any additional action necessary for the DMARC and/or DKIM records ? Not necessarily. If the additional server doesn't share a DKIM key with any of the others, you'll need to add its key to the DNS as well. If it's another server in the same administrative domain and you have a secure way of sharing a DKIM key with an existing server, there's no need. The site says, " When using SPF you need to take note of a limitation in this technique. The number of DNS lookups which are allowed to take place is limited to 10." If we have more than 10 email senders, are we SOL or is there a way to include them without breaking this rule ? If you can list the IP addresses in the SPF record, there won't be additional lookups: "v=spf1 ip4:10.0.0.0/28 ~all" = one lookup "v=spf1 mx ip4:10.0.0.0/28 ~all" = two lookups "v=spf1 mx include:spf.example.net ~all" = at least two lookups Multiple SPF records ? Even with a crazy number of senders, you should be able to figure out a way to limit yourself to only a couple of levels of indirection. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: Precedence of transport and virtual
On 2021-04-09 21:08:08 (+0800), Wietse Venema wrote: Philip Paeps: On mx1.freebsd.org, we have a configuration that (vastly simplified) looks something like this: virtual_maps = hash:/usr/local/etc/postfix/virtual transport_maps = hash:/usr/local/etc/postfix/transport We have freebsd.org configured as a Postfix-style virtual domain virtual: freebsd.org virtual There are certain addresses we'd like to catch on mx1 though, before virtual processing takes place. e.g. in transport we have [elided]@freebsd.org: error:5.2.1 User has left this world However, mail always hits virtual and the transport map appears to be ignored. By definition, a recipient address in a virtual alias domain is rewritten to a recipient address in a different domain. Postfix never delivers mail "to" a virtual alias domain, which explains why there is no query for it in the transport map. To reject mail for a recipient address in a virtual alias domain, delete the recipient from the virtual alias mapping. I knew it had to be something simple ... thanks for the explanation, Wietse. Time to look closely at the machinery that generates our virtual table. What fun! :) Best wishes. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Precedence of transport and virtual
On mx1.freebsd.org, we have a configuration that (vastly simplified) looks something like this: virtual_maps = hash:/usr/local/etc/postfix/virtual transport_maps = hash:/usr/local/etc/postfix/transport We have freebsd.org configured as a Postfix-style virtual domain virtual: freebsd.org virtual There are certain addresses we'd like to catch on mx1 though, before virtual processing takes place. e.g. in transport we have [elided]@freebsd.org: error:5.2.1 User has left this world However, mail always hits virtual and the transport map appears to be ignored. If I understand the documentation correctly, the left hand side of the transport table can be an email address. Is there something trivial we are overlooking? postconf -n doesn't show anything related to virtual/transport ordering that we might have changed from the default. We could probably achieve the same with a check_recipient_access and REJECT but I wonder why the transport option isn't working. (In the specific example above, simply not including [elided] in virtual would also work but the way our virtual is generated is ... intricate). Thanks for any insights. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: OFF TOPIC Are there problems on the list?
On 2020-04-25 10:03:04 (+0200), Francesc Peñalvez wrote: For days, 4 specifically, I have only received 2 emails from the Postfix list. Is there a problem? I've been subscribed to postfix-users for a long time. Sometimes there is less traffic. Sometimes more. Your message made it to the list, in any case, if you were wondering. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: should we use plaintext for message?
On 2020-03-18 09:51:45 (+0800), Wesley Peng wrote: Following this guide: https://useplaintext.email/ Shall we use plaintext message in regular email communication? You should use what the content of the message needs modulo your recipients' wishes. I personally prefer to receive plain text but I don't mind receiving conservatively marked up HTML email (e.g. emphasis, hyperlinks, tables, ... even embedded images if the message requires them). Others may (will) have other preferences. In my experience, plain text suffices for the vast majority of mailing list discussions. Trying to force people to limit themselves to plain text is not a productive use of anyone's time. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: postscreen_pipelining_enable vs. Exim / BDAT
On 2019-10-13 15:56:23 (-0700), Viktor Dukhovni wrote: On Oct 13, 2019, at 6:48 PM, Philip Paeps wrote: I'll see if I can find an appropriate Exim mailing list to post this on. That'd be exim-us...@exim.org it is a GNU Mailman list, so sign up on the web if you like. Or is there an Exim lurker on postfix-users who can pick this up? ;-) I'm on the exim-users list, but you have the logs, and all the relevant facts, so it's your issue to run with. And yes there may be some Exim folks on this list, just like I am on theirs, (and Claus Aßmann is here too from Sendmail). Wietse has already filed a bug, but thanks for the pointer. I might sign up just to keep an eye on what's happening in Exim land. One more mailing list won't hurt. Email compresses very nicely. :) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: PATCH: postscreen_pipelining_enable vs. Exim / BDAT
On 2019-10-13 16:05:07 (-0700), Wietse Venema wrote: Philip Paeps: On 2019-10-13 13:29:27 (-0700), Wietse Venema wrote: Philip Paeps: I've started noticing messages like these in my logs and the logs on mx1.FreeBSD.org in recent months: Oct 13 00:58:21 rincewind postfix/postscreen[76460]: COMMAND PIPELINING from [46.101.147.153]:59818 after BDAT: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=masozm.com;\r\n\t s=mail; h=Content- ... There are two problems: one is big and one is small. The big problem: it is a PROTOCOL ERROR when the remote SMTP client sends a BDAT (or DATA) command, because postscreen rejects all RCPT TO commands, and does not announce PIPELINING support. So no matter what, this client should not pass strict postscreen protocol enforcement. I'll see if I can find an appropriate Exim mailing list to post this on. Or is there an Exim lurker on postfix-users who can pick this up? ;-) I have filed a bug, and forgot to write down the number. The small problem: the 20180903 patch incorrectly fixes a misleading warning message; it tests the right flag, but in the wrong variable. If I fix this, then postscreen in strict protocol mode should still flag Exim's behavior as a protocol error. Better error/warning messages are always appreciated. :) Even if they don't make the real problem go away, they might make it slightly easier to identify. I have a fix (attached) that no longer flags this as a PIPELINING error (because it isn't). It just logs "BDAT without valid RCPT" without blocking mail. That was quick, thank you! :-) I'll rebuild with this patch this week. Is there a way to remove individual entries from the postscreen cache for easy testing? If I delete the whole cache, mail from senders who've already passed the 'after-220' checks will get delayed. Many thanks. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: postscreen_pipelining_enable vs. Exim / BDAT
On 2019-10-13 13:29:27 (-0700), Wietse Venema wrote: Philip Paeps: I've started noticing messages like these in my logs and the logs on mx1.FreeBSD.org in recent months: Oct 13 00:58:21 rincewind postfix/postscreen[76460]: COMMAND PIPELINING from [46.101.147.153]:59818 after BDAT: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=masozm.com;\r\n\t s=mail; h=Content- ... There are two problems: one is big and one is small. The big problem: it is a PROTOCOL ERROR when the remote SMTP client sends a BDAT (or DATA) command, because postscreen rejects all RCPT TO commands, and does not announce PIPELINING support. So no matter what, this client should not pass strict postscreen protocol enforcement. I'll see if I can find an appropriate Exim mailing list to post this on. Or is there an Exim lurker on postfix-users who can pick this up? ;-) The small problem: the 20180903 patch incorrectly fixes a misleading warning message; it tests the right flag, but in the wrong variable. If I fix this, then postscreen in strict protocol mode should still flag Exim's behavior as a protocol error. Better error/warning messages are always appreciated. :) Even if they don't make the real problem go away, they might make it slightly easier to identify. I've turned postscreen_pipelining_enable off on mx1.FreeBSD.org for the time being because it was getting a lot of legitimate email deferred (and timed out). Another reason to turn off all 'after-220' tests is that turning on one will turn on the others, too. That may be OK when a client has already failed the 'before-220' tests, but should probably not happen otherwise. Thanks for the suggestion and the additional context. I've grepped through my mailserver logs and the mx1.FreeBSD.org logs for the past week or so and it doesn't look like the 'after-220' checks are catching much spam. Most spammers get killed by the RBL checks. I've now turned all the 'after-220' checks off again. ``` postscreen_bare_newline_enable = no postscreen_pipelining_enable = no postscreen_non_smtp_command_enable = no ``` Perhaps the wording of the "Important note" in POSTSCREEN_README should be a little more strongly worded? Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
postscreen_pipelining_enable vs. Exim / BDAT
I've started noticing messages like these in my logs and the logs on mx1.FreeBSD.org in recent months: Oct 13 00:58:21 rincewind postfix/postscreen[76460]: COMMAND PIPELINING from [46.101.147.153]:59818 after BDAT: DKIM-Sig nature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=masozm.com;\r\n\t s=mail; h=Content- Oct 13 17:12:51 rincewind postfix/postscreen[60205]: COMMAND PIPELINING from [198.180.150.2]:37464 after BDAT: Received: from h1fa3.n1.ips.mtn.co.ug ([41.210.159.163] helo=[192.168.8.100])\r\n\tby mail.rg.net with Oct 13 17:12:59 rincewind postfix/postscreen[60205]: COMMAND PIPELINING from [198.180.150.2]:33740 after BDAT: Received: from h1fa3.n1.ips.mtn.co.ug ([41.210.159.163] helo=[192.168.8.100])\r\n\tby mail.rg.net with The senders are running recent Exim versions. There was a discussion on this list about a year ago which resulted in a patch against Postfix 3.4-20180903. Did this issue accidentally get unfixed or is this a new interop issue with Exim? I'm running 3.4.7. What can I do to debug this better? I've turned postscreen_pipelining_enable off on mx1.FreeBSD.org for the time being because it was getting a lot of legitimate email deferred (and timed out). Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Re: Blacklistd interaction
On 2019-05-06 10:26:17 (-0700), @lbutlr wrote: On 6 May 2019, at 11:22, lists wrote: It had been my experience that the firewall uses more resources that SSHGuard. Certainly it uses more memory. But you do not have to use a firewall if that's an issue. /etc/hosts.allow is always an option, and that block is practically free. I'm pretty sure that having the kernel (firewall) drop the packets is a lot more "free" than handing the connection to a userspace process to check /etc/hosts.allow. But on contemporary hardware, the difference is probably impossible to measure except under extreme load. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Misconfiguration and documentation clarification help
On 2019-04-19 00:28:31 (-0700), Eric Dynamic wrote: Ok, it's nabble doing it (suppressing anything that could be an email when viewing the postfix archives on their service.) People receiving the email (half dozen or so by now) have probably received the markup I intended. Sorry for my confusion. Yes ... it would be a lot easier if you simply subscribed to the mailing list instead of using a web frontend. After all, email is what you're trying to configure so a mailing list seems like an appropriate interface? Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Current ideas on DKIM signing ?
On 2019-04-07 00:55:58 (+0800), Laura Smith wrote: Hi, Am currently refreshing my perimeter mail infrastructure. The current state of affairs of DKIM signing looks pretty miserable! DKIMProxy seems to be abandonware since 2010 OpenDKIM seems to be going the way of abandonware too (last release in 2015 and the bug tracker filling up). I've had a quick search on github for DKIM but can't find much of interest. We all know what software is like, you have to keep it fed and watered otherwise it starts growing bugs (or worse). I'm not too keen on using software of 2015 vintage. What is everybody using these days ? Or have I missed something in the world of email and everyone's moved from DKIM to the Next Best Thing (TM). Looking forward to your suggestions I'm using rspamd for DKIM signing (and spam filtering). It plugs into Postfix as a milter and I've not had any difficulties with it. I used to run OpenDKIM but when I switched from SpamAssassin to rspamd, I configured it to do DKIM signing too. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: A problem I'm not sure how best to solve
On 2018-10-08 22:42:27 (-0400), Phil Stracchino wrote: I have a perplexing puzzle thrust upon me. Consider the following: Oct 8 15:55:33 minbar postfix/smtpd[7422]: NOQUEUE: reject: RCPT from rs230.mailgun.us[209.61.151.230]: 551 5.1.8 : Sender address rejected: Domain not found; from= to= proto=ESMTP helo= mailgun.us is connecting with a good HELO, and appears to be authorized to send mail on behalf of pluspora.com, but the mail has a sender address that is bad because mg.pluspora.com does not resolve in DNS, and so the mail is rejected. I want to TEMPORARILY (I hope) whitelist redac...@mg.pluspora.com as a sender address as long as the mail is being sent by mailgun.us. How would you do it? You could add a check_sender_access which returns OK for mg.pluspora.com before the reject_unknown_sender_domain in smtpd_recipient_restrictions. (Guessing, because you didn't include your configuration.) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: any api to read logs ?
On 2018-10-01 09:32:58 (+0200), Patrick Ben Koetter wrote: * Илья Шипицин : 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. If you want to go this route, I would recommend looking at libxo[0]. It will still be a lot of work. I'm not sure if anyone has ever tried to use libxo for logging though. Philip [0] libxo: http://juniper.github.io/libxo/libxo-manual.html -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Can a ISP block partially the traffic over the port 25 ??
On 2018-06-28 07:25:43 (-0500), kazabe wrote: I'm have a very strange issue with a mail server, locate in the main company office. Until the last five weeks we are experimenting problems to deliver emails to some domains stored on outlook.com and other servers. We message stay on our queue with the status 442 like this: "dsn=4.4.2, status=deferred (lost connection with mail.server.com[XX.XX.X.XX] while receiving the initial server greeting)." This means you're not getting the 220 greeting from the server you're connecting to. telnet to the port 25 = telnet mail.server.com 25 Trying XX.XX.XX.XX... Connected to mail.server.com. Escape character is '^]'. ehlo localhost 452 syntax error (connecting) You cannot send your EHLO until you receive the 220 greeting from the server. So, this is the question: why if both ports are "open", just the 587 permit to complete the connection? Maybe your ISP or some other middlebox is redirecting traffic to port 25 to a proxy that does not send a 220 greeting for certain reasons. Is possible to the ISP have some internal rules to "block" the traffic related with some connections related with the port 25 of others ISP? (i do the same test with 10 email servers where i know to use our same ISP without problems)? Yes. This is possible. And this is what seems to be happening. Im confused because this issue dont happen with all the port 25 connections; just with some email servers, specially outlook.com, but microsoft answer us to they dont have problems related with our IP. Whoever is running the middlebox may only be selectively interfering with connections. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: New EFF certbot plugin for Postfix
On 2018-06-26 03:37:03 (-0400), Viktor Dukhovni wrote: Overall, I am somewhat skeptical that the STARTTLS everywhere approach to improving SMTP security is a good idea For MTA<->MTA communication, there really isn't another choice. While accepting authenticated mail on port 465 is commonly done, very few servers will accept unauthenticated mail there. The default (commented out) configuration for smtps in master.cf also does not encourage use of this port for accepting unauthenticated mail. It's actually quite convenient -- configuration-wise -- to have smtp + STARTTLS be for unauthenticated mail and smtps or submission + STARTTLS for authenticated mail. Maybe the protocol just needs a fourth port. I'm sure the IETF discussions would be entertaining. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Removing trace records on submission MSA
On 2018-05-02 20:52:46 (+0200), @lbutlr wrote: On 2018-05-01 (04:02 MDT), Philip Paeps wrote: I wonder if it wouldn't be easier to add a configuration option to smtpd to suitably expurgate Received: headers of sensitive information. What information in the Received header do you consider sensitive? When it comes in over submission from authenticated users, I consider the HELO hostname, the IP address and the reverse lookup of the IP address sensitive. Those data allow the user to be tracked around the internet based on where they send email from. The queue id, the date and the sasl username are sufficient trace information to grep in logfiles if something needs to be debugged. Note that I'm only talking about submission. The trace headers added on mail being relayed are perfectly fine. I'm not sure if there's a tidy way to implement this as an option. The hairy header_checks hack also "just works". My mind just rebels against something so conceptually simple requiring such a crazy regular expresion. :) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Root user's sent mail
On 2018-04-30 08:07:07 (-0600), LuKreme wrote: The root user sends out some periodic mails to users. These mails get placed in /root/sent (an mbox file) instead of in /root/Maildir/.Sent/ (a Maildir directory). It’s not a big deal, but it makes clearing the mails periodically slightly more difficult. The mails are sent via a crontab entry much like this: | mutt -e 'set content_type=text/html' -s "DMR $($YDAY)" u...@kreme.com -b adminu...@kreme.com main.cf:home_mailbox = Maildir/ But I suspect the issue here is mutt and not postfix? Correct. You should configure Mutt to use Maildir rather than mbox: set mbox_type= Maildir See the muttrc(5) manual for how to configure where sent mail is stored. You'll probably also want to set the `folder` and `record` options in addition to `mbox_type`. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Removing trace records on submission MSA
On 2018-03-10 22:01:01 (+0100), J Doe wrote:
I have a question in regards to removing some trace records when
providing submission on Postfix 3.1.x and later.
Apologies for resurrecting an old thread.
I had some time to kill yesterday and I came up with this PCRE monster:
/^Received:.*([\n]).*sender: (.+?)\).*(by.+?)\).*(id \w+).*(;.*)/
REPLACE Received: ${3}, authenticated sender ${2})${1} ${4}${5}
It's a bit hairy but it makes the Received: header of a submission user
look a lot like the Received: header added by local delivery:
Received: by rincewind.trouble.is (Postfix, authenticated sender
philip)
id X; Tue, 1 May 2018 09:56:20 + (UTC)
I wonder if it wouldn't be easier to add a configuration option to smtpd
to suitably expurgate Received: headers of sensitive information.
This is working for me though. It's ugly but it seems to work for all
my users and the exotic devices they use.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: Certificate Replacement
On 2018-04-12 16:25:21 (-0700), Doug Hardie wrote: I am needing to replace the certificate and key. Are they read and cached when postfix starts, or are they read during normal mail handling? In other words, can I replace the files or do I need to do a reload or restart of the service afterwards? As pointed out, you don't need to restart (and usually don't even need to reload) Postfix for the new keys and certificates to take effect. However: do keep in mind that if you're using DANE and you're replacing the keys, you need to allow enough time for the keys to roll over in the DNS. Unless you have a real need to change replace the keys (e.g. compromise, policy), it may be easier to simply reissue the certificate without generating new keys. In that case, you can use "3 1 1" TLSA records in the DNS and you don't need to roll them when you're simply reissuing your certificates. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Removing trace records on submission MSA
On 2018-04-05 08:54:45 (+0800), J Doe wrote: Hi Phillip, I have a question in regards to removing some trace records when providing submission on Postfix 3.1.x and later. While reading RFC 6409 (“Message Submission for Mail”), I note that the RFC observes that: "Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces.” By this I take it that I could remove perhaps the initial trace message that returns information about internal addresses and network names. It seems to me that both Hotmail/Outlook and Gmail do this. Is this acceptable ? The only bad side to it would appear to be possibly some increased difficulty in troubleshooting. If it is an acceptable process, how would I configure Postfix to do this only on submission ? I anonymise the initial Received: header with a header_checks on the submission service. In master.cf, I add `-o cleanup_service_name=subcleanup` to the submission service. That service is defined as: subcleanup unix n - n - 0 cleanup -o syslog_name=postfix/subcleanup -o header_checks=pcre:$config_directory/submission_header_checks.pcre The submission_header_checks.pcre file contains: /^\s*(Received: from .+?(?=\s\())[^\n]*(.*for <.*)/ REPLACE $1 (localhost [127.0.0.1])$2 I'm sure there are better ways to do this, but this works for me. It doesn't interfere with debugging much because the logs will mentain the replacement and it's easy to grep for. Thank you for your reply. I currently use DKIM and as per the RFC for DKIM, I don’t include trace headers in the message hash that makes up the DKIM signature. I am under the impression that my DKIM signatures should be correct in this case if I use your solution and it re-writes the first trace header - is that true or are there any other DKIM issues I might run into ? Unless you have specifically configured your DKIM setup to include trace headers in the hash (which you should not do according to the RFC), your DKIM signatures will continue to be correct if you anonymise the first trace header like I do. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Removing trace records on submission MSA
On 2018-03-10 16:01:01 (-0500), J Doe wrote: I have a question in regards to removing some trace records when providing submission on Postfix 3.1.x and later. While reading RFC 6409 (“Message Submission for Mail”), I note that the RFC observes that: "Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces.” By this I take it that I could remove perhaps the initial trace message that returns information about internal addresses and network names. It seems to me that both Hotmail/Outlook and Gmail do this. Is this acceptable ? The only bad side to it would appear to be possibly some increased difficulty in troubleshooting. If it is an acceptable process, how would I configure Postfix to do this only on submission ? I anonymise the initial Received: header with a header_checks on the submission service. In master.cf, I add `-o cleanup_service_name=subcleanup` to the submission service. That service is defined as: subcleanup unix n - n - 0 cleanup -o syslog_name=postfix/subcleanup -o header_checks=pcre:$config_directory/submission_header_checks.pcre The submission_header_checks.pcre file contains: /^\s*(Received: from .+?(?=\s\())[^\n]*(.*for <.*)/ REPLACE $1 (localhost [127.0.0.1])$2 I'm sure there are better ways to do this, but this works for me. It doesn't interfere with debugging much because the logs will mentain the replacement and it's easy to grep for. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Offering STARTTLS in postfix. need help!
On 2018-01-12 15:45:33 (-0500), Sean Son wrote: How does one configure an internet facing Postfix SMTP mail relay server, to offer STARTTLS? I have been googling around and seeing various different articles and blog entries, but I cannot figure out what is the quickest and easiest way to do so. I am running postfix on RHEL 7. Any help is greatly appreciated! I'm surprised Google couldn't find http://www.postfix.org/TLS_README.html DuckDuckGo returns it as the first hit for "Postfix TLS". Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Calendar & Contacts
On 2017-12-27 13:08:44 (+1030), Mal wrote: Interested to hear from those running a Postfix(MTA)/Dovecot(IMAP) combo on what contacts & calendar server projects they are having success with. I run Nextcloud. It's implemented in PHP (of all things) so you definitely want to lock it up in a jail. It stores its data in a PostgreSQL database (or possibly other kinds of databases -- I haven't looked). If you're on FreeBSD, you can install it in a fresh jail with `pkg install nextcloud`. The documentation is fairly comprehensive. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Temporarily stop mail delivery
On 2017-12-25 13:58:53 (-0500), Wietse Venema wrote:
Wietse Venema:
Black Sheep:
> Is there a simple way to temporarily stop postfix delivering mail
> into the /var/vmail mail boxes, instead queueing them up? The
> purpose being to get a clean backup of /var/vmail without stopping
> receipt of mail from the internet. Then restart mail delivery so
> the queue is emptied into the appropriate local mail boxes?
/etc/postfix/main.cf
transport_maps = static:{4.3.0 Mail service unavailable}
Sorry that should be:
transport_maps = static:{retry:4.3.0 Mail service unavailable}
That will stop Postfix from acccepting mail from the network.
Oh wow. Thanks for that tip!
I really need to get used to start using more of these static: maps. I
have a couple single-entry /^.*$/ pcre: tables which should probably all
be static:.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: Postfix vs Exim
[Please don't top-post. Formatting repaired.] On 2017-12-25 11:20:40 (+0100), vonProteus wrote: On Mon, Dec 25, 2017 at 10:04 AM, Marat Khalili wrote: Flamebait question, but I happened to configure both (repository versions) recently, so here's one opinion. Both are useable, and used. Exim is sold as easier to configure, but IMO it doesn't deliver on this - probably simple config is just an impossible thing for universal SMTP MTA. On the other hand, Postfix has larger internet share and more resources on the web dedicated to it. Therefore I usually go for postfix (once you learned it, it's not that hard), and only use exim if there's no postfix in distribution repository. my ultimate goal is to configure MTA in that way that i'm able to use it as a mail relay station sorry for my not fully technical and poor language Any MTA should be ale to relay mail. :) my idea is that i recently encounter more and more email forms which do not allow me to use + addressing so my idea is to setup my own MTA which will redirect emails send to t...@registeruser.example.com to forexample registeru...@gmail.com Postfix can easily be configured to do that for you. I expect Exim can too though. In the case of Postfix, you'd just set up a virtual(5) map to redirect the emails to their final destination. I'd suggest you compare the configuration file formats of the different MTAs your operating system offers and pick the one you find most comfortable. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Postfix vs Exim
On 2017-12-25 09:31:07 (+0100), vonProteus wrote: With one is better and why do you think so? I’m going to chose one and would like to know your opinion Well ... you're asking on the Postfix mailing list. Obviously people are going to answer Postfix. :) To be honest, I never looked at Exim. After a "robust" interaction with Sendmail in early 2000, someone suggested I look at Postfix. I never looked back. (Grepping through revision control logs of old configuration files, the earliest version I can find mentioned was "19991231-pl8" around mid-2000, which I apparently upgraded to "19991231-pl13" in early 2001. Version numbers didn't come along until a year or so after that :) Happy days!) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: How can I "reject_unverified_LOCAL_sender"?
On 2017-10-20 21:28:29 (+0200), Rick van Rein wrote: On 2017-10-20 21:17:26 (+0200), Philip Paeps wrote: On 2017-10-20 19:51:07 (+0200), Rick van Rein wrote: Wouldn't it be a lot easier simply to reject those with SPF? If you're seeing mail from one of your domains coming in from a host you know couldn't have legitimately sent it, you can reject it outright. That would block not just the spam, but also legitimate bypassing through forwarders and email lists (if they don't do VERP). I would prefer not to go there for something that could be solved with local information. It would break legitimate forwarders, but that's easy to whitelist because (hopefully) you know your forwarders. The salient part of my configuration is: smtpd_sender_restrictions = permit_mynetworks reject_unknown_sender_domain check_client_access cidr:$config_directory/access_client.cidr check_client_access hash:$config_directory/access_forwarders check_recipient_access pcre:$config_directory/access_recipient.pcre check_spf The `access_forwarders` table lists all legitimate forwarders. There are a couple of forwarders in `access_recipient` too: forwarders whose IP addresses I can't (easily) control, I configure to forward to a unique (and opaque and non-guessable) alias. But SPF does rely on information that is not local (to Postfix). If you don't want to use SPF, you could use a combination of a check_client_access to whitelist your hosts followed by a check_sender_access. That's a neat work-around. It hinges on not having any checks or rejects after these ones, but for the sender_restrictions, that is currently true. Since there's not all that much you can check in sender restrictions, that shouldn't be a big problem. You may be able to fiddle with (not) deferring reject if that's a limitation for you. If you don't want to rely on SPF, you should be able to modify my configuration by adding a `check_sender_access` after the whitelists. One way to go could be to create a database of sender domains to validate, enter my own domains in it, and use "external" access to my own MTA and probing it. But that leads to cyclic probing! I suppose I am really looking for something simpler -- namely an invocation of the virtual(8) server for addresses on the said lists. Why bother validating the address? Because that is the vital piece of information that sets the attempts by spammers aside from proper behaviour. Because that gives a good source for detecting, with high degree of certainty, that a party is sending spam. If you really have no control over your forwarders, this is true. It may be worth the effort to take control over the forwarders though. SPF blocks a lot of crap. As I wrote: the forwarders you know by IP address can simply be a check_client_access. Forwarders whose IP addresses are variable can hopefully be taught to forward to a unique address. For bootstrapping new restrictions, I find `warn_if_reject` extremely helpful. Good luck. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: How can I "reject_unverified_LOCAL_sender"?
On 2017-10-20 19:51:07 (+0200), Rick van Rein wrote: I see a lot of spam entering that claims to have come from a local domain, usually guessing a non-existent account. I've been looking for a way to "reject_unverified_local_sender", by which I mean that the sender address is verified iff it occurs in virtual_alias_domains (and perhaps a few other lists). Wouldn't it be a lot easier simply to reject those with SPF? If you're seeing mail from one of your domains coming in from a host you know couldn't have legitimately sent it, you can reject it outright. If you don't want to use SPF, you could use a combination of a check_client_access to whitelist your hosts followed by a check_sender_access. One way to go could be to create a database of sender domains to validate, enter my own domains in it, and use "external" access to my own MTA and probing it. But that leads to cyclic probing! I suppose I am really looking for something simpler -- namely an invocation of the virtual(8) server for addresses on the said lists. Why bother validating the address? I don't see how I can do this with Postfix, and it's not even simple in a policy due to the cyclic risk. What are others doing in this respect? I use SPF. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Increasing spam level to backup MX
On 2017-09-11 14:13:29 (+0200), Davide Marchi wrote: activating a backup server I realized that some spammers using this server to send spam to my relay_recipient_maps addresses. Spam is then successfully forwarded to the main server. Is there a parameter to prevent this type of action? A type check "do not receive email if the main server is reachable...? Or should I operate directly by SpamAssassin? Your backup servers should have the same filtering in place as your main server. If not, spam will sneak through. For a simple setup, a separate backup server will often do more harm than good. If you're using postscreen and you have multiple IP addresses configured,, you should investigate the ``postscreen_whitelist_interfaces`` option to give spammers who try backup MXes a hard time. Last time I checked, it was not possible to share the postscreen temporary whitelist between machines. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Lists and spam prevention / use of Reply-To:
On 2017-08-29 14:12:29 (+0200), Ralph Seichter wrote: On 29.08.2017 13:42, @lbutlr wrote: There are very good reasons for footers on many lists, and DKIM should be smart enough to figure this out. I disagree about "very good reasons for footers on many lists". Meta information belongs into the message headers, not the body. DKIM-signed messages are letters, not postcards, and no non-totalitarian postal service would dare open your letter and scribble junk on the contents. Stick to the envelope, Mr. Postman. ;-) Scribbling in the body also breaks PGP signatures. At least that's trivially worked around by adding the list footer in a separate MIME part as many lists do. But DKIM still doesn't like that. DKIM, SPF and DMARC have one thing in common: they're all hostile to mailing lists. P.S.: We're drifting far away from Postfix here. Sorry for continuing to drift. I'll shut up again. :) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: postfix mail parsing
On 2017-07-14 13:46:15 (+0530), hyndavirap...@bel.co.in wrote: i have installed postfix 2.10 from source code. That's getting a little long in the tooth. we are sending mail to postfix server with custom headers. Based on those headers, some actions need to be taken at mail server. For that purpose i'm customizing postfix source code. I'm not sure why you feel you need to modify the Postfix source code to process custom headers. Why is `header_checks` not working for you? In other words: "what problem are you trying to solve?" This seems like Postfix should be able to "just do". Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: pickup/maildrop being used to spam through my machine.
On 2017-06-13 04:28:39 (-0400), Homer Wilson Smith wrote: Suddenly I am find adore's mailq queue filled with spam, each having a pickup line in the logs, but no indication where it comes from, probably the web server as the from username is apache, but so far no corellation between web logs and time stamp on pickup line. Check for other processes running as the apache user. Check the crontab of that user too. Also firewall off any ports. I would definitely advise taking a disk image of the machine for forensic analysis and then doing a clean reinstall. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Berkeley DB reads DB_CONFIG from cwd
On 2017-06-11 14:07:36 (-0400), Wietse Venema wrote:
Oh, and it will of course open a DB_CONFIG file in whatever happens to
be the super-user's cwd when they invoke the postmap or postalias
command, so this is not just a matter of set-gid Postfix commands.
[...]
-if ((errno = db->set_cachesize(db, 0, dict_db_cache_size, 0)) != 0)
- msg_fatal("set DB cache size %d: %m", dict_db_cache_size);
Is this change intentional, or did it sneak in? It seems unrelated to
the environment workaround.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: Proper Forwarding Procedure?
On 2017-06-09 21:10:12 (+0100), Dominic Raferd wrote: On 9 June 2017 at 20:45, Steve Jenkins wrote: I've got a Postfix server hosting a lastname.org domain name for family members. I use virtual aliasing to forward inbound mail for family members to third-pary mail providers (mostly gmail, but a few yahoo and aol, too). I've also created user accounts on the server for a very small handful of immediate family members (4 people) so they can authenticate (via TLS) send email as firstn...@lastname.org (which is properly DKIM signed and will pass an SPF check). I do not provide any mail storage or retrieval on the server (no POP or IMAP) for any family members. This has worked fine for years, but now I'm starting to see warnings in the Postfix log from Gmail, stating that the server is being rate-limited because of unsolicited messages. I presume that Gmail is sensing SPAM being sent to the @lastname.org accounts, which gets forwarded to the family member's Gmail account. I don't do any spam checking or filtering on the Postfix server. So my questions are: 1) What's the best way to forward family members' incoming mail to Gmail (and other mailers)? 2) My Postscreen and main.cf sender restrictions are rejecting a fair amount of inbound spam, but apparently not enough to keep Gmail happy. 3) Should I consider setting up SpamAssassin with some very low thresholds to pick up the obvious stuff? I have a not-dissimilar setup and I have various fixes to minimise Gmail's upset. But I guess the first q is whether you need to be worried about the 'rate-limited' messages. If you have a low volume of incoming emails anyway a bit of rate-limiting is hardly likely to be a problem. The rate-limiting may not be a big problem long-term but eventually all email coming from you will be filed as spam. And then users will blame you for that ... Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Proper Forwarding Procedure?
On 2017-06-09 12:45:31 (-0700), Steve Jenkins wrote: I've got a Postfix server hosting a lastname.org domain name for family members. I use virtual aliasing to forward inbound mail for family members to third-pary mail providers (mostly gmail, but a few yahoo and aol, too). I've also created user accounts on the server for a very small handful of immediate family members (4 people) so they can authenticate (via TLS) send email as firstn...@lastname.org (which is properly DKIM signed and will pass an SPF check). I do not provide any mail storage or retrieval on the server (no POP or IMAP) for any family members. This has worked fine for years, but now I'm starting to see warnings in the Postfix log from Gmail, stating that the server is being rate-limited because of unsolicited messages. I presume that Gmail is sensing SPAM being sent to the @lastname.org accounts, which gets forwarded to the family member's Gmail account. I don't do any spam checking or filtering on the Postfix server. So my questions are: 1) What's the best way to forward family members' incoming mail to Gmail (and other mailers)? There really isn't any "best" way to do this. Reportedly, Google can retrieve email over POP3 or IMAP. Perhaps you can set up accounts for your users? 2) My Postscreen and main.cf sender restrictions are rejecting a fair amount of inbound spam, but apparently not enough to keep Gmail happy. 3) Should I consider setting up SpamAssassin with some very low thresholds to pick up the obvious stuff? Yes. Google gets increasingly cranky if you relay spam to them and ultimately your users will blame you when Google eventually files all their mail coming from your server as junk. But you really want users to pull mail from you. Unfortunately, forwarding is no longer a viable option in the current world of email. The spammers have broken that for everyone. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Feasible to encrypt the virtual_mailbox_base directory with ecryptfs?
On 2017-05-20 20:33:01 (-0700), pbw wrote: Has anyone tried to do this? Was it feasible? As long as the encryption is transparent to Postfix, it shouldn't matter. I run all my mail systems on encrypted volumes. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: TLS warning
On 2017-05-24 14:54:34 (+0200), Bastian Blank wrote: On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote: You shouldn't be accepting sslv3 due to the poodle attack. https://en.m.wikipedia.org/wiki/POODLE Please explain how exactly SMTP is exploitable using POODLE? There are other good reasons to disable SSLv3. But POODLE is a distraction in the context of SMTP. In general though, when it comes to SMTP, any encryption is better than none. And opportunistic encryption is the way to go. Read RFC 7435: https://tools.ietf.org/html/rfc7435 Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: SPF best practices
On 2017-05-09 14:22:39 (+0200), Volker Cordes wrote: I know this topic is not really postfix related but advice would nevertheless be appreciated. This is definitely more appropriate for another mailing list. I'm adding a second mail server to my setup, my domains are spf-protected by this simple entry: v=spf1 mx -all If I add second DNS A entry for my MX server will this still work or do I have to list ips individually? Or should I create multiple MX entries? The reason I don't want to do that in the first place is that there are a lot of domains and I'd have to set the entries manually. Note that MX records list servers that *receive* email while SPF records list servers that *send* email. As far as SPF is concerned, adding an extra A record to the host pointed to by the MX record will just work but that's usually not what you want with respect to your receiving mail servers. If that server will not be receiving mail, it's definitely the wrong thing to do. I prefer to list individual IPs in my SPF records. If you don't want to maintain many SPF records, look into creating an _spf.example.com SPF record and including it in your various domains. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Does white-listing 'postmaster' white-list all the other recipients?
On 2017-04-20 01:43:11 (-0700), J. Johnson wrote:
A while back I was wondering why certain spammers kept hitting our
'postmaster' account, then i realized there were multiple recipients.
It seems like the other recipients ride in on the back of 'postmaster',
then are free to go there individual ways. Does anyone know if that is
true? And if so, how can the additional recipients be suppressed?
It depends on where you whitelist postmaster. If you whitelist by
checking the To: header in `header_checks`, the message is likely to
also be delivered to anyone else in the To: header.
With `check_recipient_access` in `smtpd_{sender,recipient}_restrictions`
you can exempt mail with an envelope recipient postmaster from other
checks. E.g.:
main.cf:
smtpd_sender_restrictions =
[...]
check_recipient_access pcre:$config_directory/access_recipient.pcre
check_spf
access_recipient.pcre:
/^postmaster\@/OK
The above would bypass `check_spf` for messages directed at postmaster
but the `header_checks` still run.
I would only list things in `header_checks` that are really egregious
and which no mail to postmaster@ is going to convince me is legitimate.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: Automatically substitute FQDN of local system in config
On 2017-04-19 18:52:56 (+0300), Marat Khalili wrote: On 19/04/17 18:39, Philip Paeps wrote: Linux systems often only configure their shortname with `sethostname()` (for reasons I've never understood). If you set a FQDN though, it will be returned with `gethostname()`. Try to figure out where your particular flavour of Linux sets its hostname and teach it to set a FQDN instead of a shortname. You're right, this is my case! Will consider moving to FQDN in hostname then (wonder what it may break)... For what it's worth, I've never encountered anything that *relies* on the weird Linux behaviour. [But plenty of things that don't work around it as elegantly as Postfix does by appending .localdomain!] Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Automatically substitute FQDN of local system in config
On 2017-04-19 17:54:32 (+0300), Marat Khalili wrote: I'm having trouble creating Postfix config (main.cf) without explicitly writing domain name in it. I'd like both myhostname and mydomain automatically set to output of `hostname -f` or contents of /etc/mailname. However, whatever combinations of myorigin, mydomain and myhostname I define, I either receive errors or values like `hostname`.localdomain. Is it impossible, or am I missing some working combination? If `gethostname()` returns a FQDN it will be used as `$myhostname`. If it only returns a hostname, Postfix will append `localdomain`. I'm using Postfix 3.1.0-3 under Ubuntu 16.04. Linux systems often only configure their shortname with `sethostname()` (for reasons I've never understood). If you set a FQDN though, it will be returned with `gethostname()`. Try to figure out where your particular flavour of Linux sets its hostname and teach it to set a FQDN instead of a shortname. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: ECDSA and RSA: setting preference
On 2017-04-19 13:33:13 (+0200), @lbutlr wrote: On 2017-04-13 (11:21 MDT), Viktor Dukhovni wrote: smtp_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5 I have these, but also LOW, EXPORT, and RC4. Are these not needed? That depends on the versions of Postfix and OpenSSL on your system and on how much you care about interoperability. While RC4-MD5 should no longer be used for anything, there are still a lot of mailservers out there that don't know any better. When you don't offer them RC4-MD5, they will fall back to plain text. Even RC4-MD5 is better than that. In general, you should probably leave this setting alone unless you have a very specify reason to change it. And even then, you will likely be better served with an entry in `smtp_tls_policy_maps` overriding the default for a specific destination. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: team alias and SPF
On 2017-04-18 00:04:07 (+0200), Benny Pedersen wrote: Philip Paeps skrev den 2017-04-17 19:49: On 2017-04-17 19:33:36 (+0200), Geert Stappers wrote: teamfoo: localcopy j...@example.com b...@domain.tld john@some.where Bob checks SPF on incoming messages. Bob should not be checking SPF from your mailserver if he knows there's a forward / expander there. the forwarding host ip can be added to spf whitelist in mta stage where spf is being breaked, doing so will in case of spamassaasin check spf for the real sender ips that is the originating ip Sure. That's a possibility. Checking SPF breaks email forwarding. incorrect since enveloper domain changes on the forward host Only if you take steps to change the envelope. In a normal/default setup, the envelope will not be changed. The easiest way to do this, is for Bob to check a list of forwarders in his ``smtpd_sender_restrictions`` if he's using Postfix. its not postfix job of make envelope sender fixses Correct. since spf is not dkim, or even sid-milter that breaks spf by checking from: header with breaks spf, i think most users see sender-id as a spf fail there in, but its not spf spf is maillists safe, so why say forwarding breaks spf ? SPF is only "safe" for mailing lists if the mailing list takes ownership of the message and remails it with a new envelope. SPF is not "safe" when you're simply forwarding the message (i.e.: without changing the envelope). If you check SPF, you need to whitelist every machine that forwards mail for you. Your backup MX for one. But also every other host that you know legitimately forwards mail for you. DKIM is completely unrelated. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: team alias and SPF
On 2017-04-17 19:33:36 (+0200), Geert Stappers wrote: teamfoo: localcopy j...@example.com b...@domain.tld john@some.where Bob checks SPF on incoming messages. Bob should not be checking SPF from your mailserver if he knows there's a forward / expander there. Checking SPF breaks email forwarding. The easiest way to do this, is for Bob to check a list of forwarders in his ``smtpd_sender_restrictions`` if he's using Postfix. main.cf: smtpd_sender_restrictions = [...] check_client_access hash:$config_directory/access_forwarders [] access_forwarders: [...] your_server.example.com OK [...] If Bob wants to verify SPF, he should have a table like that whitelisting every host he knows forwards mail to him. This is really Bob's problem and not yours... In the year 2017 is that all correct behaviour. Several years earlier was a team alias best pratice. Now I'm looking for a successor. If you check SPF, you should be prepared to whitelist known forwarders. I think the right approach is * recieve the e-mail * rewrite some headers ** the Alice From should go into Reply To ** new From is team...@projecthost.my.domain Note that SPF checks the envelope From (5321.From) not the header From. * send the message of Alice to the foo team members If bob is the only recipient who causes you grief, you should ask him not to check SPF for your server, since this is really his problem. If you want to make it your problem (or it's been made your problem), there are two options: you could run a mailing list (e.g. mailman) which rewrites the envelopes or you could use e.g. postsrsd to rewrite the envelopes. Note that postsrsd will rewrite all your envelopes, regardless of whether the address was expanded. https://github.com/roehling/postsrsd Mailman and postsrsd are both trivial to set up. My preference would be for mailman because postsrsd will but it will rewrite all envelopes, something which I personally would find upsetting but your views may differ. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: new installation questions
On 2017-04-16 12:52:51 (+0530), Rajesh M <24x7ser...@24x7server.net> wrote: i have been using qmail (qmailtoaster) for the past several years and would like to use postfix for my new server my os is centos6 -- 64 bit my servers are hexcore processors, 16 gb ram os - raid1 -- 600 gb 15k rpm data - raid1 -- 2000 gb 7.2k rpm i have a traffic of around 60k delivered emails per day per server my current qmail install includes qmail (Maildir format), maildrop, vopmail (for managing users), qmailadmin (web interface for creation / modification /deletion of users, forwarding, auto-response and mailing list management) , spamassassin, mysql, dovecot pop3 and imap, SSL/TLS and STARTTLS for smtp/pop3/imap and squirrelmail for webmail. I also use email sending / receiving policy and email archival of every email sent and recd per user. on postfix i would like to have a similar setup as above with a fairy simple way to migrate user mailbox data, which OS is preferred (though i am using centos6 i dont mind changing) and also what partition format would be stable and faster than ext4. could you please let me know where to start please, links to url which apply to current postfix packages and also add-on software, with some information on specific steps where i need to take care. I would definitely recommend FreeBSD if you're not married to Linux. It's a lot more predictable (no systemd farce). Progress is made at a steady pace, without surprises. Just like Postfix. The FreeBSD port of Postfix follows Wietse's releases quite closely and ships without gratuitous changes to the default settings. If you ``pkg install postfix`` on FreeBSD you'll get a pristine Postfix installation with defaults as documented by Postfix. For filesystems: I cannot recommend ZFS strongly enough. For a busy mailspool, you really want to add SSD log devices to your pool though. If you can't use ZFS for whatever reason, UFS works well for Postfix too. For mail storage, the builtin lz4 compression of ZFS performs incredibly well. Postfix supports Maildir so you probabably will not need to migrate your user mailboxes. If you add a '/' at the end of ``mail_spool_directory`` or ``home_mailbox``, Postfix local(8) will deliver Maildir-style. You can probably keep using your MySQL database from qmail largely unchanged. The [MYSQL_README](http://www.postfix.org/MYSQL_README.html) documents the configuration very well. Dovecot works well with Postfix too, so do SpamAssassin and maildrop and everything else you're likely to need. Postfix comes with incredibly thorough documentation. You'll have to ask more specific questions on this list if you run into difficulties. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: exclude a host(s) and allow it without authentication
On 2017-04-15 13:29:37 (+0100), lejeczek wrote:
I'm fiddling with settings but thought, someone already must know - how
to achieve above, if possible at all?
Simply add it to $mynetworks and add ``permit_mynetworks`` to the
relevant ``smtpd_{foo}_restrictions``?
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: ECDSA and RSA: setting preference
On 2017-04-13 17:28:44 (+0200), Zbyszek Żółkiewski
wrote:
Wiadomość napisana przez Philip Paeps w dniu
13.04.2017, o godz. 16:04:
On 2017-04-13 15:55:12 (+0200), Zbyszek Żółkiewski
wrote:
Wiadomość napisana przez Philip Paeps w dniu
13.04.2017, o godz. 15:50:
On 2017-04-13 14:53:50 (+0200), Zbyszek Żółkiewski
wrote:
Wiadomość napisana przez Zbyszek Żółkiewski
w dniu 13.04.2017, o godz. 13:33:
Question: postfix 2.11: I have configured both RSA and ECDSA
support on the server (smtpd_tls_cert_file and
smtpd_tls_eccert_file) and support for ECDSA works great -
however ECDSA is _never_ selected as cipher for sending or
receiving mails.
To check if it is properly configured i have disabled RSA support
and running server only with ECDSA and i confirm it works with
gmail servers for example (cipher ECDHE-ECDSA…).
Is there any way i can force postfix to first try ECDHE-ECDSA…
and then fallback to RSA? Note, i have tried custom
tls_high_cipherlist but no luck…
I think i found solution to this, by modifying default high list
to:
tls_high_cipherlist =
ECDSA:aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
server now prefers ECDSA over RSA. Can someone cross-check if that
is correct solution for a problem and not pose any risk?
This poses an interoperability risk. You should carefully check
your maillogs for the ciphers you're excluding with this.
[...]
Note that many senders will fall back to plain SMTP if they can't
negotiate TLS with you. I feel a little security is better than no
security at all.
thanks for the comment. But please not that i am using defaults
postfix „high” settings - my only change is to force ECDSA at
the beginning of the cipher list.
Sorry. I missed that you were on Postfix 2.11. I looked at
``postconf -d tls_high_cipherlist`` on my Postfix 3.1.4 installation
and it does not list !MEDIUM or +RC4.
adding ECDSA causes to change order only to the defaults. This could
be also some kind of feature requests to postfix maintainers - to
have option to sort (not change) cipher list.
You can achieve that using ``tls_{high,medium,low}_cipherlist``
together with ``tls_preempt_cipherlist = yes``. I don't really think
Postfix is the correct place to sort ciphers by preference. That's
something to do in OpenSSL.
all looks good except _outgoing_ mail that still uses
ECDHE-RSA-AES128-GCM-SHA256. Incoming mail is using
ECDHE-ECDSA-AES256-GCM-SHA384 and clients as well are using
ECDHE-ECDSA-AES256-GCM-SHA384.
Are you sure the servers you are talking to actually support ECDSA? :)
Did you check the TLS handshake with tcpdump to verify the cipherlist
offered by the server? By default TLS servers allow clients to select
their preferred cipher but they can override this default.
so where is problem ? settings are:
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
tls_high_cipherlist =
ECDSA:AESGCM:aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
These settings look fine. You could perhaps add
``tls_preempt_cipherlist`` but this only affects smtpd, it has no effect
on the smtp client.
Please check the TLS handshake to verify the ordering of ciphers in the
client hello and whether the server offers ECDSA in the server hello and
that it doesn't preempt the client's offered ciphers.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: ECDSA and RSA: setting preference
On 2017-04-13 08:16:29 (-0600), @lbutlr wrote:
On 2017-04-13 (07:50 MDT), Philip Paeps wrote:
egrep "TLS connection established from.*with cipher" \
/var/log/maillog* | awk \
'{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | \
sort | uniq -c | sort -n
Interesting. Ran this over a few days of logs:
5288 TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
4633 TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384
2343 TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256
1527 TLSv1 with cipher ECDHE-RSA-AES128-SHA
1250 TLSv1.2 with cipher AECDH-AES256-SHA
Everything else is under 500, and the next 2 are the top 2 TLSv1.2 without GCM.
That's a pretty good situation to be in. :)
I've been trying to reach out to the RC4-MD5 users who are unfortunately
still in the top 10 of one of the mail systems I manage.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: ECDSA and RSA: setting preference
On 2017-04-13 15:55:12 (+0200), Zbyszek Żółkiewski wrote:
Wiadomość napisana przez Philip Paeps w dniu 13.04.2017, o
godz. 15:50:
On 2017-04-13 14:53:50 (+0200), Zbyszek Żółkiewski wrote:
Wiadomość napisana przez Zbyszek Żółkiewski w dniu
13.04.2017, o godz. 13:33:
Question: postfix 2.11: I have configured both RSA and ECDSA support
on the server (smtpd_tls_cert_file and smtpd_tls_eccert_file) and
support for ECDSA works great - however ECDSA is _never_ selected as
cipher for sending or receiving mails.
To check if it is properly configured i have disabled RSA support
and running server only with ECDSA and i confirm it works with gmail
servers for example (cipher ECDHE-ECDSA…).
Is there any way i can force postfix to first try ECDHE-ECDSA… and
then fallback to RSA? Note, i have tried custom tls_high_cipherlist
but no luck…
I think i found solution to this, by modifying default high list to:
tls_high_cipherlist = ECDSA:aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
server now prefers ECDSA over RSA. Can someone cross-check if that is
correct solution for a problem and not pose any risk?
This poses an interoperability risk. You should carefully check your
maillogs for the ciphers you're excluding with this.
Try something like:
egrep "TLS connection established from.*with cipher" \
/var/log/maillog* | awk \
'{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | \
sort | uniq -c | sort -n
This will give you a list of ciphers negotiated by occurence.
I would not recommend fiddling with the default TLS cipherlists unless
you have a very specific need.
Note that many senders will fall back to plain SMTP if they can't
negotiate TLS with you. I feel a little security is better than no
security at all.
thanks for the comment. But please not that i am using defaults postfix
„high” settings - my only change is to force ECDSA at the beginning of
the cipher list.
Sorry. I missed that you were on Postfix 2.11. I looked at ``postconf
-d tls_high_cipherlist`` on my Postfix 3.1.4 installation and it does
not list !MEDIUM or +RC4.
adding ECDSA causes to change order only to the defaults. This could be
also some kind of feature requests to postfix maintainers - to have
option to sort (not change) cipher list.
You can achieve that using ``tls_{high,medium,low}_cipherlist`` together
with ``tls_preempt_cipherlist = yes``. I don't really think Postfix is
the correct place to sort ciphers by preference. That's something to do
in OpenSSL.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: ECDSA and RSA: setting preference
On 2017-04-13 14:53:50 (+0200), Zbyszek Żółkiewski wrote:
Wiadomość napisana przez Zbyszek Żółkiewski w dniu
13.04.2017, o godz. 13:33:
Question: postfix 2.11: I have configured both RSA and ECDSA support
on the server (smtpd_tls_cert_file and smtpd_tls_eccert_file) and
support for ECDSA works great - however ECDSA is _never_ selected as
cipher for sending or receiving mails.
To check if it is properly configured i have disabled RSA support and
running server only with ECDSA and i confirm it works with gmail
servers for example (cipher ECDHE-ECDSA…).
Is there any way i can force postfix to first try ECDHE-ECDSA… and
then fallback to RSA? Note, i have tried custom tls_high_cipherlist
but no luck…
I think i found solution to this, by modifying default high list to:
tls_high_cipherlist = ECDSA:aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH
server now prefers ECDSA over RSA. Can someone cross-check if that is correct
solution for a problem and not pose any risk?
This poses an interoperability risk. You should carefully check your
maillogs for the ciphers you're excluding with this.
Try something like:
egrep "TLS connection established from.*with cipher" \
/var/log/maillog* | awk \
'{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | \
sort | uniq -c | sort -n
This will give you a list of ciphers negotiated by occurence.
I would not recommend fiddling with the default TLS cipherlists unless
you have a very specific need.
Note that many senders will fall back to plain SMTP if they can't
negotiate TLS with you. I feel a little security is better than no
security at all.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: lots of € From: owner-postfix-users-dig...@cloud9.net (Majordomo Pseudo User)
On 2017-04-13 04:27:09 (+0200), Benny Pedersen wrote: body only contained € chars only me that was maked millionare ? :=) I get surprisingly little spam from Postfix mailing lists. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: relay server - mass mailing tuning
On 2017-04-11 14:04:08 (-0400), Viktor Dukhovni wrote: On Apr 11, 2017, at 1:55 PM, Philip Paeps wrote: It is worth repeating that the spinning rust actually matters in this case: Postfix fsync()s when accepting a message into the queue. The time to it takes to enqueue a message is at least the time it takes to write it to disk, not simply the time it takes to hit the buffer cache. For high-volume senders, the main problem is usually getting the mail *out* faster with less friction from the receiving systems. Accepting mail faster is not necessarily a good idea, if that just means a bigger backlog. I'm aware of that. :) I merely wanted to remind the OP (and anyone stumbling across this thread in the archives) that the time it takes to enqueue mail should not be underestimated. Many common workloads don't have to care too much about disk latency because they're protected by the buffer cache. This is not the case when handling large volumes of mail. Ideally you want to be able to get mail out as fast as it's coming in or at least not very much slower but you don't have complete control over that (sites you need to deliver to can go down or refuse to take mail from you for a while, etc). If you know you need to relay half a million messages in a short period of time weighing about 100Gbytes in total, you need to be prepared to enqueue an appreciable fraction of that volume. The OPs efforts should go towards understanding what it takes to send email at the intended volume. Receiving it fast enough is a secondary issue. It sounds like the OP is largely unprepared for the task at hand. This requires real experience and dedicated effort. Just asking for a few ideas on this list is unlikely to be sufficient. I agree. A sane approach is to start small, grow gradually, and solve small problems as they come up, before they become big problems. Going from nothing to sending a very large volume of mail is not easy. At the very least, the OP should spend what little time he has before he needs to handle this load becoming as familiar as possible with the TUNING_README and probably also QSHAPE_README. That will hopefully prepare him enough to balance the rate of mail coming in against the rate he can get it out. It still might not be very pretty though. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: relay server - mass mailing tuning
On 2017-04-11 10:02:21 (-0400), Wietse Venema wrote: Fazzina, Angelo: I would think they would have to tell you the volume and or rate at which they intend to send the mail. He mentioned message count and size, about 100GB of traffic, so that might take a while, especially when the queue is on spinning disks. It is worth repeating that the spinning rust actually matters in this case: Postfix fsync()s when accepting a message into the queue. The time to it takes to enqueue a message is at least the time it takes to write it to disk, not simply the time it takes to hit the buffer cache. People occasionally forget that Postfix actually tries to be reliable in addition to fast. :) Mounting /var/spool on an SSD is definitely a good idea. Ideally a mirrored pair of SSDs for reliability. If you're running on ZFS, you want your ZIL on fast SSDs (again: plural, and remember to mirror them, by default ZFS load-balances log devices). (If you don't care about reliability, mount /var/spool on a tmpfs. Or build Postfix without HAS_FSYNC. If it breaks you get to keep the pieces though.) - If the sender's DNS setup is borked, Postfix will lose time doing DNS lookup for the SMTP client name/address. Running a local resolver (e.g. Unbound) can mitigate most of these issues. Also be sure to check that the TTL of the SMTP client's DNS name / zone are configured sensibly. If it's got a TTL of 5 seconds, you can do all the caching you like and you'll still be doing a lot of waiting for DNS. (This can be mitigated with the cache-min-ttl setting in Unbound). Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: Disabling SMTPUTF8 per destination
On 2017-04-10 09:51:42 (-0400), Wietse Venema wrote: > Philip Paeps: > > My system is configured with default SMTPUTF8 settings [...] > > > > This works perfectly fine (probably because, sadly, SMTPUTF8 is still > > quite rare in the wild) except occasionally I'll get an NDR for a > > locally submitted message: > > > > SMTPUTF8 is required, but was not offered by host > > > > This happens when I "bounce"/"resend" a message with UTF8 in one of the > > headers. Pre-SMTPUTF8 Postfix would not care about UTF8 in e.g. From: > > or Subject: but in the new world order, such messages submitted locally > > bounce. > > > > I'm cool with that. The world needs to move on. > > > > Except ... I know that some parts of the world will take a while before > > they move on. I couldn't find anything in postconf(5) or in the mailing > > list archives about disabling SMTPUTF8 per destination. > > The simplest solution is to not enable SMTPUTF8 auto-detection in > the Postfix sendmail command (smtputf8_autodetect_classes = verify). > That is the root cause of the problem, after all. That had occurred to me but it happens rarely enough that I've not been too bothered (it pretty much only happens when I bounce Asian spam to spamcop.net). When it does happen, it reminds me to check if anything new is happening in the world of SMTPUTF8. :) If it starts bothering me, I'll do as you suggest. > > If a per-destination safety net existed, I would likely consider > > setting ``smtputf8_autodetect_classes`` to all. If others feel > > the same, maybe it would advance adoption of SMTPUTF8 in the wild. > > What should happen with TRANSIT EMAIL, after the Postfix SMTP server > has promised that it will deliver such email according to the rules > for SMTPUTF8? Argh. I see what you mean. I hadn't considered mail in transit. I was thinking only of mail coming in through submission (which, come to think of it, is actually also in transit). I should think before writing email rather than during. > > Prior art in Postfix is ``smtp_tls_policy_maps`` which allow > > overriding main.cf TLS settings per destination. > > There is no promise that email received with TLS will be forwarded > with TLS. With SMTPUTF8 (and 8BITMIME), the receiving MTA actually > makes such a promise. The MTA is required to respect the promise > that it made when it announced SMTPUTF8 (or 8BITMIME) support, and > if it can't keep that promise, to return email as undeliverable. You are correct of course. I had forgotten that the SMTPUTF8 promise applies to the entire message and all headers not simply the envelope. > Perhaps SMTPUTF8 autodetection could be more granular: UTF8 in the > envelope is definitely problematic for a receiver that does not > support SMTPUTF8, while UTF8 in a message header is less so. An option to accept/forward a message that arrives with SMTPUTF8 but only has UTF8 in the message headers but not the envelope to a nexthop that does not support SMTPUTF8 would only "fix" the problem for that one nexthop and still violates the end-to-end promise of SMTPUTF8. We can't (always) know that the nexthop configured like this is the final destination for the message. The more I think about this, the more I realise that an option like this would create a lot more problems than it solves. The rest of the world just needs to adopt SMTPUTF8. :-) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Disabling SMTPUTF8 per destination
My system is configured with default SMTPUTF8 settings, i.e.:
root@rincewind:~ # postconf -d | grep utf8
smtputf8_autodetect_classes = sendmail, verify
smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}
strict_smtputf8 = no
root@rincewind:~ # postconf -n | grep utf8
root@rincewind:~ # postconf compatibility_level
compatibility_level = 2
This works perfectly fine (probably because, sadly, SMTPUTF8 is still
quite rare in the wild) except occasionally I'll get an NDR for a
locally submitted message:
SMTPUTF8 is required, but was not offered by host
This happens when I "bounce"/"resend" a message with UTF8 in one of the
headers. Pre-SMTPUTF8 Postfix would not care about UTF8 in e.g. From:
or Subject: but in the new world order, such messages submitted locally
bounce.
I'm cool with that. The world needs to move on.
Except ... I know that some parts of the world will take a while before
they move on. I couldn't find anything in postconf(5) or in the mailing
list archives about disabling SMTPUTF8 per destination.
If a per-destination safety net existed, I would likely consider setting
``smtputf8_autodetect_classes`` to all. If others feel the same, maybe
it would advance adoption of SMTPUTF8 in the wild.
Prior art in Postfix is ``smtp_tls_policy_maps`` which allow overriding
main.cf TLS settings per destination.
Any views? Does a per-destination override exist and did I miss it in
the documentation and the archives? Has this been discussed before?
Thanks.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Re: Recommended way to pause postfix local delivery while taking snapshot for backup
On 2017-04-09 10:52:58 (+0200), Dominic Raferd wrote: Is there a best/recommended way to pause postfix local deliveries so that I can take an LVM snapshot of the local mails for backup purposes? The pause only has to be momentary, while the snapshot is taken, but the files need to be in a consistent state. If anyone also knows the way to pause Dovecot imap/pop3 similarly (as this could also be accessing the same files), that would be helpful too. You can kill two birds with one stone if you deliver mails using LMTP instead of letting Postfix local(8) deliver directly to mailboxes. As I understand it, Dovecot's LMTP implementation will ensure the mail store is always in a consistent state: either a message will be stored and indexed or it won't. If you want to ensure no deliveries are attempted while you're taking a snapshot, running LMTP over a TCP socket and blocking new connections with the firewall would do it. Postfix will queue messages for later delivery when it can't connect to the LMTP server. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
Re: postfix uses A record for MX less domains
On 2017-03-31 15:01:17 (+0200), Ralf Hildebrandt wrote: > * Mario Theodoridis : > > i'm having a curious issue with our postfix instance. > > > > It seems it is sending emails to a domain's A record when no MX is found. > > > > Is that standard? > > Yes. > > > If so, can i disable this somewhere? > > No. If you own a domain that should not be receiving email, you can prevent MTAs trying to send mail to it by explicitly specifying a null MX in the DNS: bikinibottom.com. IN MX 0 . Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
