Re: Replace subject with recipient localpart for one domain
For cases like the one you have in mind, it is necessary to use a milter. Thank you for saving me some head scratching. It wouldn't be the end of the world to spin up an Exim VM (its system_filtering is capable of this black magic), but would prefer staying in Postfix. Do you have a milter in mind for this task? MIMEDefang could do it: a few lines of Perl in the filter() callback. Yes, that would be the standard milter to do what you want. But if I were you I would ask myself if what you'd like to do is really necessary, and worth the price of maintaining a specific tool for it. Note also that, if you control more than Postfix, it might be possible to do what you want outside of Postfix. For example, if you have a Dovecot server behind your Postfix, you could do what you want with Sieve filters. Gregory
Re: Replace subject with recipient localpart for one domain
My Postfix server handles message for a dozen domains, for one of these domains, I want the subject replaced with the recipient's local part, so something like this, but put in a format that Postfix understands: # domain3.com is the one recipient domain we want affected by this rule # $recipient_name the recipient localpart, so "joe" if the recipient is # j...@domain3.com IF $recipient_domain = 'domain3.com' REPLACE $subject WITH $recipient_name ENDIF I think I need to setup a smtp_header_checks file, but the more I look at it the harder my head hurts. That's not possible alas, see the section BUGS at http://www.postfix.org/header_checks.5.html : "Many people overlook the main limitations of header and body_checks rules. These rules operate on one logical message header or one body line at a time. A decision made for one line is not carried over to the next line." IOW, the only things you can do with smtp_header_checks is to replace a Subject: line with another Subject: line, possibly based on the contents of the original Subject: line if you use regexp backreferences. But there is no way to use the recipient name or domain in such rules. For cases like the one you have in mind, it is necessary to use a milter. Gregory
Re: Postfix "IPv6-only" - experience/recommendation question
michae...@rocketmail.com: I've a generic question to all more experienced than me postfix users here: Is it nowadays (reasonable) possible to run postfix with IPv6 only? E.g "mail.example.com" and "smtp.example.com" with only ipv6 records in the DNS, no A / ipv4 anymore? In theory, yes: it is possible. In practice, no: it won't work. The vast majority of mail servers do not (and will never) use IPv6. I'd suggest you to read D. J. Bernstein's opinion on IPv6 ( http://cr.yp.to/djbdns/ipv6mess.html ). He might be an unpleasant person, but twenty years (!) later it seems reasonable to conclude that he was mostly right, that it is regrettable his opinion was not taken into account, and that IPv6 will never happen as it was supposed to happen. Gregory
Re: delaying postfix until/unless VPN is up/connected
Ranjan Maitra:
Wietse Venema:
Corrected code follows (missing do/done).
Save to file, chmod +x name-of-file, don't run this script from cron.
It needs to be started at boot time, or before you make a VPN
connection.
#!/bin/sh
while :
do
ifconfig xxx | egrep 'UP|DOWN'
sleep 2
done | while read status
do
case "$status" in
*UP*) if [ "$prev" -ne up ]
then
prev=up
postconf -X defer_transports
postfix reload
fi;;
*) if [ "$prev" -ne down ]
then
prev=down
postconf defer_transports=smtp
postfix reload
fi;;
esac
done
Wietse
line 10: [: : integer expression expected
Line10: is the following line:
*UP*) if [ "$prev" -ne up ]
Wietse wrote earlier that this was "totally untested code".
You should replace the two "-ne" with "!=".
Also, $prev has not been assigned the first time the second loop ("while
read status do ... done") is executed. So you should add "prev=down"
before the "while :".
Finally, note that you should also replace the "xxx" (in "ifconfig xxx")
with the actual name if your VPN interface, typically "tun0" or "tap0".
Gregory
Re: modifying outbound email headers
Stefan Claas: postfix should modify outgoing email headers that *only* go to mail2news gateways, using the email gateway addresses for parsing, so that the right part of the message ID, after the @ charachter, will be modified with a defined string. Do you mean "should modify outgoing email headers that only go to mail2news gateways" or "should only modify outgoing email headers that go to mail2news gateways"? What should happen if an email is sent both to one or more regular email addresses and to a mail2news gateway? What you want to do seems to be a job for a milter: Depending on the "RCPT TO" line (or on the "To:" header), modify the "Message-ID:" header. Such a conditional header modification cannot be done from inside Postfix. The only available mechanism to modify email headers is smtp_header_checks, but it works line by line: "Each message header or message body line is compared against a list of patterns. When a match is found the corresponding action is executed, and the matching process is repeated for the next message header or message body line." Gregory
Re: DMARC usage opinion
Hi,
I'd second Viktor Dukhovni's opinion. For the vast majority of mail
servers, a minimalistic DMARC policy suffices, just add the following
record in the domain's DNS root zone:
_dmarc 10800 IN TXT "v=DMARC1; p=none;"
If you want to go a step further, you can just monitor how DMARC is
applied by receiving mail servers to mails that (pretend to) come from
your domain. Just add a "rua" ("reporting aggregate reports") entry:
_dmarc 10800 IN TXT "v=DMARC1; p=none; rua=mailto:postmas...@yourdomain.com;
You'll then start receiving a daily report from the mail servers that
implement DMARC reporting *and* that received at least one mail coming
from (or pretending to come from) your domain. In most cases you'll only
receive reports from Google and Yahoo. These reports are XML files, which
are difficult to read, so you should find a tool that helps you to make
sense of them.
The possible next steps are to use "p=quarantine", which basically means
"deliver the mail but flag it as spam", and "p=reject", which means what
it means: do not accept the email. But as Viktor said these policies are
not recommended for a domain which does not handle sensitive information
(bank, government, hospital, ...).
Gregory
Re: reject mail if dns and rdns differ
Plain old greylisting can yield many false positives, but recent implementations of milter-greylist for example will not greylist messages that validates SPF. It helps *a lot*. The question is: does it only help "a lot", or is the result "zero false positives"? I personally don't believe SPF was a good idea, so for me it's not clear that it fully solves the problem mentioned by Jaroslaw Rafa. Gregory
Re: reject mail if dns and rdns differ
And there are various techniques (for example connection rate limits, response delays, greylisting) that prevent you from "accepting all mail" and that have zero false positives. As for greylisting, it's no more true now. Some large and popular mail sending services started some time ago to send mail in a way that is incompatible with greylisting. Greylisting assumes that after first 4xx reject, the sending server will retry: a) after a few minutes; b) from the same IP address. These services: a) retry immediately, after 5-10 seconds; b) use different IP address on each retry and c) give up after a few unsuccessful attempts. Thus it is possible you never get mail sent from these services if you use greylisting. I stand corrected, I shouldn't have mentioned greylisting, I don't have enough experience of that technique. The two other techniques I mentioned are still valid; I did experience them in the long term, and they have zero false positives. Gregory
Re: reject mail if dns and rdns differ
*Everything* short of accepting all mail regardless has false positives. Rejecting emails for non-existing users, or for domains of which your are neither the final destination nor a relay, or coming from non-existing domains, are filtering schemes that have zero false positives. And there are various techniques (for example connection rate limits, response delays, greylisting) that prevent you from "accepting all mail" and that have zero false positives. Gregory
Re: Will configuring a backup MX actually do me much good?
Sending systems will automatically back off and retry at intervals (I have seen this happen when I have upgraded my home server in the past) so will a secondary/backup MX actually help at all? It's up to you to decide what your priorities are. It's true that sending systems automatically retry delivering emails, but this means at least (1) that you experience delivery delays when your main MX is down, (2) that if your main MX is down for a long period (e.g. you're on vacation and cannot reboot, your internet connection is physically down and needs to be repaired, ...), and (3) some sending systems (typically mailing lists) maintain a record of delivery failures and will stop trying to send emails for you when there are too many failures. In cases (2) and (3) you might lose emails. Gregory
Re: how to setup storage for two different MX in different locations
My purpose is to setup two MX servers in different locations for high availability. I'm not sure I understand your question, but I guess that what you want is a secondary MX in case the primary MX becomes unavailable for some reason (power outage, server crash, whatever). If this is indeed what you want to do, you could check http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup , or https://www.howtoforge.com/postfix_backup_mx , or any other howto. Gregory
Re: Relay attempt questions
This should really be fixed. SMTPD_ACCESS_README (five times), ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README specify that "reject_unauth_destination is not needed here [= in smtpd_recipient_restrictions] if the mail relay policy is specified under smtpd_relay_restrictions". Sorry: it's SMTPD_ACCESS_README, SMTPD_POLICY_README (four times), ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README. Gregory
Re: Relay attempt questions
Nick wrote: But postconf(5) says "smtpd_recipient_restrictions ... applies in the context of a client RCPT TO command, after smtpd_relay_restrictions." If smtpd_relay_restrictions applies first, why didn't its reject_unauth_destination cause rejection before anything in smtpd_recipient_restrictions was consulted? Sorry, I did not see that part of your question. Viktor Dukhovni wrote: Sadly, the implementation changed without a documentation update. Perhaps there were competing interests dependent on the evaluation order, and issuing better backwards compatibility warnings prevailed? I agree that the documented order seems more optimal otherwise. This should really be fixed. SMTPD_ACCESS_README (five times), ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README specify that "reject_unauth_destination is not needed here [= in smtpd_recipient_restrictions] if the mail relay policy is specified under smtpd_relay_restrictions". Gregory
Re: Relay attempt questions
1 Nov 18 01:28:37 rolly postfix/postscreen[26770]: CONNECT from [162.246.19.201]:61693 to [46.235.227.79]:25 2 Nov 18 01:28:43 rolly postfix/postscreen[26770]: PASS NEW [162.246.19.201]:61693 3 Nov 18 01:28:43 rolly postfix/smtpd[26774]: warning: hostname rever.aftermathdevelopment.com does not resolve to address 162.246.19.201: Name or service not known 4 Nov 18 01:28:43 rolly postfix/smtpd[26774]: connect from unknown[162.246.19.201] 5 Nov 18 01:28:44 rolly postfix/cleanup[26776]: 564F4A0054: message-id=<20191118012844.564f4a0...@mail.acrasis.net> 6 Nov 18 01:28:44 rolly postfix/qmgr[5583]: 564F4A0054: from=, size=266, nrcpt=1 (queue active) 7 Nov 18 01:28:44 rolly postfix/smtp[26777]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c07::1a]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 8 Nov 18 01:28:44 rolly postfix/smtp[26777]: 564F4A0054: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:4013:c07::1a]:25, delay=0.5, delays=0.01/0.03/0.33/0.13, dsn=2.1.5, status=deliverable (250 2.1.5 OK j5si12868810edc.195 - gsmtp) 9 Nov 18 01:28:44 rolly postfix/qmgr[5583]: 564F4A0054: removed 10 Nov 18 01:28:47 rolly policyd-spf[26779]: prepend Authentication-Results: mail.acrasis.net; spf=none (no SPF record) smtp.mailfrom=test.com (client-ip=162.246.19.201; helo=win-sa71d6ou2qs.domain; envelope-from=t...@test.com; receiver=) 11 Nov 18 01:28:47 rolly postfix/smtpd[26774]: NOQUEUE: reject: RCPT from unknown[162.246.19.201]: 554 5.7.1 <***@gmail.com>: Relay access denied; from= to=<***@gmail.com> proto=SMTP helo= 12 Nov 18 01:28:47 rolly postfix/smtpd[26774]: lost connection after RCPT from unknown[162.246.19.201] As far as I can see everything works as it should. In lines 1-2 postscreen checks that 162.246.19.201 is a legitimate client. In lines 3-4 that client connects to your server. In lines 5-9 your server checks that the recipient address of the email the client would like to send, namely "***@gmail.com", is deliverable. This happens because you have "reject_unverified_recipient" in "smtpd_recipient_restrictions" (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). The SMTP session ends with "2.1.5 status=deliverable", not with "2.0.0 status=sent", so no email is actually sent. In lines 10-12 the client tries to actually send the email, but it is rejected because, as you wrote, "gmail.com" is not in relay_domains. Gregory
Re: Client host rejected
Now I try to send mail to box and what happen: Nov 18 17:12:35 netcup.silviosiefke.com postfix/smtpd[6215]: NOQUEUE: reject: RCPT from unknown[81.91.160.182]: 450 4.7.25 Client host rejected: cannot find your hostname, [81.91.160.182]; from= to= proto=ESMTP helo= This means that a reverse lookup of 81.91.160.182 on netcup.silviosiefke.com fails. Log into netcup.silviosiefke.com, try "dig -x 81.91.160.182", and see what happens. My guess is that if you replace the contents of /etc/resolv.conf by: nameserver 8.8.8.8 nameserver 8.8.4.4 your problem will likely be solved. Gregory
Re: IP addresses in helo
Two other users replied to your question. For real-world mail servers,
my experience is that the only safe restriction (safe = no false
positives) is "reject_unknown_reverse_client_hostname".
Irrelevant to HELO argument filtering.
Relevant to rejecting emails. Perhaps I should have written "the only
safe reject restriction at that stage of the SMTP session". Once again,
the string that follows HELO/EHLO is purely informational, it should not
be used for filtering purpose.
The OP asked "is it safe", without explaining what "safe" means for him.
For me it means "safe in general", in particular for servers handling
large amounts of email.
Rejecting mail is a far better choice than delivering to a 'spam box'
since most users never bother looking there for anything. Rejections at
least stand some chance of making enough noise on the sender side to get
misconfigurations fixed.
IMO this is naive. As Kris Deugau wrote in most cases nobody ever looks
at that noise, your users will just not receive their email.
And for the particular question of the OP ("HELO ") there is
not even a reason to consider that it is a "misconfiguration", given that
what you call a "misconfiguration" is explicitly permitted by the
standards. I agree with you that "there are no RFC police". But the
purpose of RFCs is cooperation.
It is true indeed that most users do not look at their spam folder, but
they can (and should) be educated to do so, given that every spam
filtering system I know of has false positives.
Gregory
Re: IP addresses in helo
Hi, I know it’s an RFC violation, but I see no email that is delivered with a bare IP helo that is legitimate. That might be your experience, but RFC 2821 (3.6) and RFC 5321 (2.3.5 and 4.1.4) explicitly state that an address literal can be used after HELO/EHLO. So it's a RFC violation to reject mail for that sole reason. How much legitimate mail do you get with an IP helo? Two other users replied to your question. For real-world mail servers, my experience is that the only safe restriction (safe = no false positives) is "reject_unknown_reverse_client_hostname". With other restrictions, your users will never receive emails from administrations, schools, hospitals, etc., not even in their spam box. Rejecting mail is an extreme measure, see RFC 5321 (7.9): "considerable care should be taken and balance maintained if a site decides to be selective about the traffic it will accept and process." Gregory
Re: IP addresses in helo
Hi, Is it safe (or mostly safe) to simply block attempts to deliver mail with a helo that is only an IP address? (I am talking about only on postfix/stmpd and obviously not on postfix/submit or related). No it is not, it's a RFC violation. The string that follows HELO/EHLO is purely informational, it should not be used for any filtering purpose. If you use it for this, you'll end up rejecting legitimate emails. Gregory
Re: Vague error message - SASL plain authentication failed:
Hi, Postfix is giving me a very unhelpful message of just "SASL plain authentication failed:". My guess is that you have set "log_path" in your dovecot.conf. If this is the case, the other line of the message appears in the dovecot log file, for instance: mail.log: ... SASL PLAIN authentication failed: dovecot.log: ... auth: Info: passwd-file(...): unknown user (given password: ...) If "log_path" is not set in dovecot.conf, Dovecot's log messages appear in the same place as Postfix, typically mail.log, and the two lines follow each other. Gregory
