Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
Done: https://github.com/k9mail/k-9/issues/4125 -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Building new mail server
My existing mail server is running Centos 4 (yes, VERY old -- which is a testament as to the continuing quality of Postfix), with port 25 exposed to the whole wide world. Everything else is restricted by an IPTABLES firewall and TCPwrapper. I was going to wait for CentOS 8 to be released and get some run time by early adopters, but my poor mail server is starting to show signs of wearing out and I may have to pull the trigger sooner. My question for the user community is this: any gotchas in bringing up Postfix on Centos 7.6.1810 from the Red Hat distribution? Integration with the version of Dovecot in 7.6 from same? Other questions: I'm not going to port over the mail directories from the old server. Everything will be from scratch, so conversions are not an issue. I will be carrying over my header_checks file, though. Do I need to buy a certificate for my domain satchell.net, or will a self-signed certificate be sufficient? The MX is mail.satchell.net for that domain. The other domains described on the old box have expired, so I won't be bringing those over. Significant services running on the new box: PostFix, DoveCot, BIND 9, NTP (actually chrony) Outside access and inside access are split using VLANs on an HP switch (already in my network) to the one and only Ethernet port on the new server, which is a laptop board in a mini-tower case. The outside port will be on an external (access to the world) netblock (75.140.42.118/29?), while the inside port will be in the 10.1.1.0/24 netblock. If needed, I can also have the inside port be on the 10.1.2.0/24 and 10.1.3.0/24 to access isolated equipment. I'm planning on exposing only port 25 (smtp) and rate-limited ICMP to the world. All the rest of the ports, TCP and UDP, plus other IP protocols, will be blocked to outsiders. The local LAN has access to ecerything. I'm considering how to handle output port blocking for those services not needed by a mail server.
Re: Question respecting the headers?
> >> Received: from theguardian.com (regtreis.viverindia.com.br > >> [31.172.134.4]) The remote SMTP client sent theguardian.com in the EHLO or HELO command. 31.172.134.4 is the client IP address. The Postfix SMTP server looks up the domain name for that client IP address, regtreis.viverindia.com.br, and uses that domain name only if it resolves to the remote client IP address. Otherwise, the Postfix SMTP server will use "unknown" instead. If you want to enforce that the HELO/EHLO matches the client domain name, then Postfix does not do that. Wietse
Re: Question respecting the headers?
On Wed, July 24, 2019 13:21, Bill Cole wrote: > On 24 Jul 2019, at 12:56, James B. Byrne wrote: > >> I am sure that the message associated with the header extract >> reproduced below is fraudulent. But, I would like to know how this >> particular header line was constructed at the source: >> >> Received: from theguardian.com (regtreis.viverindia.com.br >> [31.172.134.4]) >> >> How did they get 'from theguardian.com' into the Received header >> generated by our mx? > > The token immediately following the "from" in a Received header > generated by Postfix is the name offered in the EHLO or HELO command > from the SMTP client. > I am not asking this question correctly. theguardian.com is not the domain that is sending this traffic. The people who are sending it connect from an array of IP addresses but they always use theguardian.com as the server name. I had believed up until this moment that we were checking that the remote server name matched the server domain but perhaps we are just checking that the server name exists in DNS. Can we configure Postfix to prevent fraudulent use of a valid DNS host? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
On 24.07.19 10:37, jean52 wrote: Testing with swaks, I can see the 450 returned by the server (reverting workaround rules beforehand): ~> RCPT TO: <~* 450 4.1.2 : Recipient address rejected: Domain not found But swaks handles it properly and the other recipients receive the email. I'll keep the workaround, it'll make it K9 proofed for my users and won't change much for others. maybe sending bugreport is worth trying: https://github.com/k9mail/k-9/issues -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity...
Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
Yes, I reached the same conclusion, and used 'Option 1' eventually: smtpd_recipient_restrictions = reject_unauth_pipelining, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, check_policy_service inet:localhost:10022, check_policy_service unix:private/policy-spf, permit My problem is 'fixed', though it's interesting to see that I could reproduce only on K9-Mail. I tested on Sogo webmail and Thunderbird, both handle the reject message properly and request you to fix it. Testing with swaks, I can see the 450 returned by the server (reverting workaround rules beforehand): ~> RCPT TO: <~* 450 4.1.2 : Recipient address rejected: Domain not found But swaks handles it properly and the other recipients receive the email. I'll keep the workaround, it'll make it K9 proofed for my users and won't change much for others. Thanks to all for your help. -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Installation and configuration problem Postfix / Dovecot Debian Buster
On 24.07.19 07:24, Alex wrote: I am trying to install and configure Postifx / Dovecot on Debian Buster. Note that the following procedure I used for the last time on a 8.6 and that it worked very well. I have no idea of the blockage and what has changed since. I searched several days but I could not find my answer. Here are my configuration files: /etc/postfix/main.cf seems you have forgot content of those files. Don't post it here, use pastebin or something alike. telnet output is fine here. /etc/postfix/master.cf /etc/dovecot/dovecot.conf here is the following error: In the file /etc/dovecot/dovecot.conf I added : But I still have some mistakes that I do not understand: If I do a telnet: I've done a lot of research in recent days, but until now I have not found anything ... It may be something stupid, but I can not find. This configuration I used, as I said, on a Debian 8.6 (procedure that I had for the last time set up in June 2016). So can be obsolete for sure, there must be something that has changed but that escapes me totally -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
Re: Question respecting the headers?
On 24 Jul 2019, at 12:56, James B. Byrne wrote: I am sure that the message associated with the header extract reproduced below is fraudulent. But, I would like to know how this particular header line was constructed at the source: Received: from theguardian.com (regtreis.viverindia.com.br [31.172.134.4]) How did they get 'from theguardian.com' into the Received header generated by our mx? The token immediately following the "from" in a Received header generated by Postfix is the name offered in the EHLO or HELO command from the SMTP client. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
jean52: > Jul 24 15:31:25 postfix/smtpd[1758]: 27584FA3: > client=***.226.threembb.co.uk[***.226], sasl_method=PLAIN, > sasl_username=p***@***.fr > Jul 24 15:31:25 postfix/smtpd[1758]: 27584FA3: reject: RCPT from > ***.226.threembb.co.uk[***226]: 450 4.1.2 : Recipient > address rejected: Domain not found; from= to= .com> proto=ESMTP helo=<[10.***]> You can avoid this by not rejecting unknown domains in mail from an authenticated client. Option 1: insert 'permit_sasl_authenticated' to the main.cf line that blocks unknown recipient domains. Option 2: exclude authenticated clients from things that block unknown recipient domains: In master.cf: submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING In main.cf: mua_client_restrictions = mua_helo_restrictions = mua_sender_restrictions = And have clients send mail to port 587 (submission) or 465 (smtps) instead of port 25. Wietse
Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
@Chistros I just tried, but that does not change this issue, still getting a mangled/broken header, again showing early on in dkim/dmarc milters results (= no changes): Jul 24 15:31:24 postfix/smtpd[1758]: connect from ***.226.threembb.co.uk[***.226] Jul 24 15:31:24 postfix/smtpd[1758]: Anonymous TLS connection established from 92.40.249.226.threembb.co.uk[***.226]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) Jul 24 15:31:25 postfix/smtpd[1758]: 27584FA3: client=***.226.threembb.co.uk[***.226], sasl_method=PLAIN, sasl_username=p***@***.fr Jul 24 15:31:25 postfix/smtpd[1758]: 27584FA3: reject: RCPT from ***.226.threembb.co.uk[***226]: 450 4.1.2 : Recipient address rejected: Domain not found; from= to= proto=ESMTP helo=<[10.***]> Jul 24 15:31:25 postfix/cleanup[1579]: 27584FA3: message-id=<> Jul 24 15:31:25 opendkim[19808]: 27584FA3: can't determine message sender; accepting Jul 24 15:31:25 opendmarc[619]: 27584FA3: RFC5322 requirement error: missing >From field; accepting Jul 24 15:31:25 postfix/qmgr[1457]: 27584FA3: from=, size=34, nrcpt=2 (queue active) Jul 24 15:31:25 postfix/smtp[1663]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c04::1b]:25: TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits) Jul 24 15:31:25 postfix/smtpd[1758]: disconnect from 92.40.249.226.threembb.co.uk[92.40.249.226] ehlo=2 starttls=1 auth=1 mail=1 rcpt=2/3 data=1 quit=1 commands=9/10 Jul 24 15:31:25 dahlia postfix/smtp[1663]: 27584FA3: to=, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c04::1b]:25, delay=0.79, delays=0.57/0/0.11/0.11, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[2a00:1450:400c:c04::1b] said: 550-5.7.1 [2a01:4f8:10a:2493:b827:a8ff:fe4b:b71c 11] Our system has 550-5.7.1 detected that this message is not RFC 5322 compliant: 550-5.7.1 'From' header is missing. 550-5.7.1 To reduce the amount of spam sent to Gmail, this message has been 550-5.7.1 blocked. Please visit 550-5.7.1 https://support.google.com/mail/?p=RfcMessageNonCompliant 550 5.7.1 and review RFC 5322 specifications for more information. 135si37543938wmb.130 - gsmtp (in reply to end of DATA command)) However again, from the webmail the reject from Postfix results in full stop until the recipients list is fixed by sender. I'll test from Thunderbird tonight, but this looks like a K9-Mail issue (using the stock version installed on /e/). -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Installation and configuration problem Postfix / Dovecot Debian Buster
Hello, I am trying to install and configure Postifx / Dovecot on Debian Buster. Note that the following procedure I used for the last time on a 8.6 and that it worked very well. I have no idea of the blockage and what has changed since. I searched several days but I could not find my answer. Here are my configuration files: /etc/postfix/main.cf /etc/postfix/master.cf /etc/dovecot/dovecot.conf here is the following error: In the file /etc/dovecot/dovecot.conf I added : But I still have some mistakes that I do not understand: If I do a telnet: I've done a lot of research in recent days, but until now I have not found anything ... It may be something stupid, but I can not find. This configuration I used, as I said, on a Debian 8.6 (procedure that I had for the last time set up in June 2016). So can be obsolete for sure, there must be something that has changed but that escapes me totally Thanks you for help -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
Can you add this line to your main.cf and check if it solves the issue? default_destination_recipient_limit = 1 > On 24 Jul 2019, at 15:22, jean52 wrote: > > The content of the email was really not a concern, I could reproduce will > emails containing a simple 'test' text in it. > > After further testing and trying from a different endpoint/platform, it > turns out I am not getting the same behaviour from all clients/MUA. > > Re-enabling 'reject_unknown_recipient_domain', if I send another test email > from my webmail, I get a notification from the webmail that the email was > not sent due to a bad address. The email is not sent to anyone and I have to > edit/fix my list of recipients before being able to send the email. > > If I test from K9-Mail on Android, I get the same error as yesterday, the > sending of the email is considered failed but stays in the Outbox, where it > keeps trying to send the email periodically, but with a header that is now > actually broken, missing several fields. > > From one of the recipients'mail server I received a notification mentioning: > > Missing required header field: "Date" > Missing required header field: "From" > MIME error: error: unexpected end of header > > So, my guess is that the issue resides with K9-Mail way of handling the > reject server response, as it somehow mangles its own header. > > Does that make sense? > > > > -- > Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Sending to multiple recipients fails entirely if any of the RCPT is rejected (unknown domain)
The content of the email was really not a concern, I could reproduce will emails containing a simple 'test' text in it. After further testing and trying from a different endpoint/platform, it turns out I am not getting the same behaviour from all clients/MUA. Re-enabling 'reject_unknown_recipient_domain', if I send another test email from my webmail, I get a notification from the webmail that the email was not sent due to a bad address. The email is not sent to anyone and I have to edit/fix my list of recipients before being able to send the email. If I test from K9-Mail on Android, I get the same error as yesterday, the sending of the email is considered failed but stays in the Outbox, where it keeps trying to send the email periodically, but with a header that is now actually broken, missing several fields. >From one of the recipients'mail server I received a notification mentioning: Missing required header field: "Date" Missing required header field: "From" MIME error: error: unexpected end of header So, my guess is that the issue resides with K9-Mail way of handling the reject server response, as it somehow mangles its own header. Does that make sense? -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
