Re: Hiding Spamhaus key from replies
On Mon, 18 Nov 2019, Merrick wrote: hello On 2019/11/18 3:42 下午, Bernardo Reino wrote: How can I configure postfix to do like postscreen_dnsbl_reply_map but for smtpd? can spamassassin do that as well? I don't know, that was not my question :) (I use rspamd for spam filtering, where I also intend to use the various Spamhaus lists, but this is another topic, and for another mailing list :) Cheers.
Re: What am I missing? DNSBL on submission port?
On Thu, Oct 31, 2019 at 07:52:11PM -0400, Andrew Sullivan wrote: I _know_ I am overlooking something, and I need a clue-bat. On 17.11.19 22:03, Andrew Sullivan wrote: Thanks to the list for the help. I tracked this down to a mistake in main.cf with a too-restrictive smtpd_client_restrictions (I seem to have commented out the line that had permit_sasl_authenticated, which I think was a leftover elision from testing where I was trying to force the condition). main.cf options should be overridden in master.cf and thus too restrictive smtpd_client_restrictions should not affect submission port. Thanks for the clues. Intermittent failures are hard to debug. the question was if you are sure it was the submission port. smtpd on submission port should log as "postfix/submit/smtpd" due to proper options in master.cf: -o syslog_name=postfix/submit -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject you can also add -o smtpd_client_restrictions= or move rejection from smtpd_client_restrictions to e.g. smtpd_recipient_restrictions to avoid the problem you've had. This would also add possibility to whitelist certain recipients e.g. postmaster so they could receive mail from blacklisted sites -- 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. Enter any 12-digit prime number to continue.
Re: Hiding Spamhaus key from replies
On 18.11.19 08:42, Bernardo Reino wrote: I currently use postscreen with postscreen_dbl_sites pointing to my instance of spamhaus.net. With postscreen_dnsbl_reply_map I hide the secret key from the server responses. Now, I also have/had "reject_rbl_client zen.spamhaus.org" a part of my smtpd_recipient_restrictions. I want to change that to use my secret key, but I can't seem to find a way to map the server name to something else (to hide the key). I've read about default_rbl_reply, and I believe that what I need is rbl_reply_maps but -- at least as of now -- I can't seem to be able to make sense of it :-? How can I configure postfix to do like postscreen_dnsbl_reply_map but for smtpd? What's the point of using spamhaus in smtpd_recipient_restrictions when you have already done so in postscreen? -- 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. You have the right to remain silent. Anything you say will be misquoted, then used against you.
Re: Hiding Spamhaus key from replies
On Mon, 18 Nov 2019, Matus UHLAR - fantomas wrote: On 18.11.19 08:42, Bernardo Reino wrote: I currently use postscreen with postscreen_dbl_sites pointing to my instance of spamhaus.net. With postscreen_dnsbl_reply_map I hide the secret key from the server responses. Now, I also have/had "reject_rbl_client zen.spamhaus.org" a part of my smtpd_recipient_restrictions. I want to change that to use my secret key, but I can't seem to find a way to map the server name to something else (to hide the key). I've read about default_rbl_reply, and I believe that what I need is rbl_reply_maps but -- at least as of now -- I can't seem to be able to make sense of it :-? How can I configure postfix to do like postscreen_dnsbl_reply_map but for smtpd? What's the point of using spamhaus in smtpd_recipient_restrictions when you have already done so in postscreen? My plan is/was to use only one blacklist (zen, IP-based) during postscreen but then have the option of using other blacklists (dbl, zrd) at smtpd time. Even if at some point I will only leave the postscreen filter active, I wanted to nevertheless know how I would use it during smtpd. I have now done it with: rbl_reply_maps = texthash:/etc/postfix/dnsbl_reply_smtpd where that file has lines like: $KEY.zrd.dq.spamhaus.net=127.0.2.[2..24] $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked where $KEY is my key, and the LHS of that line is exactly as it looks in reject_rhsbl_reverse_client (to give an example). Seems to work (meaning: postfix hasn't complained, and I continue to receive mail :), but given the little traffic I have I wanted an "offline verification" that this is the right way to do this. Hence my question. Thanks.
Re: Hiding Spamhaus key from replies
On 18.11.19 08:42, Bernardo Reino wrote: I currently use postscreen with postscreen_dbl_sites pointing to my instance of spamhaus.net. With postscreen_dnsbl_reply_map I hide the secret key from the server responses. Now, I also have/had "reject_rbl_client zen.spamhaus.org" a part of my smtpd_recipient_restrictions. I want to change that to use my secret key, but I can't seem to find a way to map the server name to something else (to hide the key). On Mon, 18 Nov 2019, Matus UHLAR - fantomas wrote: What's the point of using spamhaus in smtpd_recipient_restrictions when you have already done so in postscreen? On 18.11.19 10:12, Bernardo Reino wrote: My plan is/was to use only one blacklist (zen, IP-based) during postscreen but then have the option of using other blacklists (dbl, zrd) at smtpd time. I moved all blacklist filtering from smtpd to postscreen, because postscreen can weigh blacklists, so I considered it more safe. e.g. if something is whitelisted in dnswl, and blacklisted in zen, it's allowed, but if it's blacklisted in zen and in other BL, it's denied even if in dnswl... Thus I avoid many false-positives. Now I only run rhsbl checks in smtpd (postscreen can't do that). Even if at some point I will only leave the postscreen filter active, I wanted to nevertheless know how I would use it during smtpd. I recommend moving dnsbls to postscreen and keep them off smtpd. I have now done it with: rbl_reply_maps = texthash:/etc/postfix/dnsbl_reply_smtpd where that file has lines like: $KEY.zrd.dq.spamhaus.net=127.0.2.[2..24] $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked where $KEY is my key, and the LHS of that line is exactly as it looks in reject_rhsbl_reverse_client (to give an example). Seems to work (meaning: postfix hasn't complained, and I continue to receive mail :), but given the little traffic I have I wanted an "offline verification" that this is the right way to do this. I think key should be separated from value by tab, not '='. anything in the logs yet? -- 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. 99 percent of lawyers give the rest a bad name.
Re: Hiding Spamhaus key from replies
On Mon, 18 Nov 2019, Matus UHLAR - fantomas wrote: On 18.11.19 10:12, Bernardo Reino wrote: My plan is/was to use only one blacklist (zen, IP-based) during postscreen but then have the option of using other blacklists (dbl, zrd) at smtpd time. I moved all blacklist filtering from smtpd to postscreen, because postscreen can weigh blacklists, so I considered it more safe. e.g. if something is whitelisted in dnswl, and blacklisted in zen, it's allowed, but if it's blacklisted in zen and in other BL, it's denied even if in dnswl... Thus I avoid many false-positives. Now I only run rhsbl checks in smtpd (postscreen can't do that). My plan is also to use ip-based bl[ao]cklists with postscreen, and RHSBL in smtpd, once I know things are working OK (but I'm 99% this is the case :) I have now done it with: rbl_reply_maps = texthash:/etc/postfix/dnsbl_reply_smtpd where that file has lines like: $KEY.zrd.dq.spamhaus.net=127.0.2.[2..24] $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked where $KEY is my key, and the LHS of that line is exactly as it looks in reject_rhsbl_reverse_client (to give an example). Seems to work (meaning: postfix hasn't complained, and I continue to receive mail :), but given the little traffic I have I wanted an "offline verification" that this is the right way to do this. I think key should be separated from value by tab, not '='. anything in the logs yet? The "=" is part of the blacklist definition, i.e. smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rbl_client $KEY.zen.dq.spamhaus.net=127.0.0.[2..255], check_client_access pcre:/etc/postfix/client_access.pcre (I'm aware that this, (which is what I currently have in main.cf) doesn't match with the example I quoted above of my reply map, which contains other entries (dbl, zrd) in case I add them to my recipient restrictions later). AFAIK the domain, including (if present) the IP regex should be present on the left hand side of the rbl_reply_maps. Cheers and thanks again for you reply.
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
Re: Hiding Spamhaus key from replies
On Mon, 18 Nov 2019, Matus UHLAR - fantomas wrote: anything in the logs yet? I just got a hit, and it worked as expected :) Nov 18 11:47:17 regenbogen postfix/smtpd[17564]: NOQUEUE: \ reject: RCPT from 71-10-166-63.dhcp.stls.mo.charter.com[71.10.166.63]: \ 554 5.7.1 Service unavailable; Client host [71.10.166.63] blocked; \ from= to= proto=ESMTP \ helo= (Oddly enough, it was apparently a DMARC report, but the server is indeed blacklisted in zen.spamhaus.net) Thanks for your input Matus! I guess my issue is solved :)
IP addresses in helo
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). I have about 50,000 NOQUEUE reject from "helo=<[193.32.160.151]>" over the last week, for example. I see very few otherwise, and all are obviously spam with return addresses like account-security-nore...@091773.com or apple_supp...@0904.ru. -- A sadder and a wiser man he rose the morrow morn.
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: IP addresses in helo
On Mon, 18 Nov 2019 at 12:00, @lbutlr wrote: > 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). > > I have about 50,000 NOQUEUE reject from "helo=<[193.32.160.151]>" over the > last week, for example. I see very few otherwise, and all are obviously > spam with return addresses like account-security-nore...@091773.com or > apple_supp...@0904.ru. > Interesting idea. But I checked my records and - although YMMV - for us it would have a lot of false positives. (BTW I couldn't do this through mail logs because mine don't record the helo except when an incoming email is rejected.)
Re: IP addresses in helo
On 18 Nov 2019, at 05:22, Gregory Heytings wrote: >> 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. I know it’s an RFC violation, but I see no email that is delivered with a bare IP helo that is legitimate. And I reject TFC compliant mails all the time. In fact, the vast majority of mail that is attempted on my server is RFC compliant and rejected. > 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. How much legitimate mail do you get with an IP helo? -- "Love is the triumph of imagination over intelligence." - H. L. Mencken
Re: IP addresses in helo
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). On 18.11.19 13:22, Gregory Heytings wrote: 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. can you provide RFC and section? AFAIK the only violation is if you reject based on HELO string not equivalent to reverse resolution of connecting client and other helo string rejections are fine from RFC point of view. If you use it for this, you'll end up rejecting legitimate emails. this can happen anytime anyone rejects any e-mail. -- 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. Chernobyl was an Windows 95 beta test site.
Non-ASCII bytes in email header and similar
Looking for protocol expertise that some here might have … I understand that email header content should contain 7-bit ASCII-only. However, as an implementor of email software such as a milter, how do I best deal with non-conforming input? Say I receive a header line in my milter that isn’t ASCII-only, what is the most sensible (standards-compatible?) decoding I should apply – Latin1? UTF-8? What works best with real email traffic? Please ignore if this is completely off-topic here. Thank you. -- David
Re: IP addresses in helo
Hello On 2019/11/18 8:32 下午, @lbutlr wrote: How much legitimate mail do you get with an IP helo? I just saw postfix in my Vps, the default configuration is using IP for Helo command. I use this postfix to send monitor stuff to myself, received in gmail. regards.
Re: Hiding Spamhaus key from replies
Merrick skrev den 2019-11-18 08:48: On 2019/11/18 3:42 下午, Bernardo Reino wrote: How can I configure postfix to do like postscreen_dnsbl_reply_map but for smtpd? can spamassassin do that as well? https://github.com/spamhaus/spamassassin-dqs/blob/master/sh.cf with meta its solved, but its really not possible in spamassassin yet to hide seensitive info
Re: block 'new style' TLDs ?
Hi, On Mon, Nov 18, 2019 at 01:11:22PM +0200, George Papas wrote: > this still works : > > https://www.davidmartinwhite.com/2016/10/25/fighting-spam-block-entire-ttld-with-postfix/ > To be clear, I believe in, "Your network, your rules." Each operator should do what s/he wants. At the same time, there are a _lot_ of anti-abuse techniques for mail that don't rely on the broad hueristic of, "This TLD seems to suck," and that don't rely on establishing that rule as a permanent part of your configuration. If we want the domain name system to be scalable and we want to have interoperable mail, hand-crafting the list of "these suck" domains is not a good way to go. That makes for the kind of brittle configuration that introduces later problems when some new operator takes over .TLD-THAT-SUCKS and cleans it up (or the same operator makes it better and starts producing reliably good, well-behaving registrations). Hard coding the TLD into blocklists means that there is never any reward for fixing stuff: everything is broken anyway, permanently, so the operator of that TLD has zero incentive to make it better, ever. So, I would like to encourage people to find ways to stanch mail from bad sources using reputation lists and so on, rather than wholesale blocking of whole TLDs. Best regards, A (Full disclosure: in my day job I work for the Internet Society, but I am not speaking for them now.) -- Andrew Sullivan a...@anvilwalrusden.com
Re: Hiding Spamhaus key from replies
Bernardo Reino skrev den 2019-11-18 10:12: I have now done it with: rbl_reply_maps = texthash:/etc/postfix/dnsbl_reply_smtpd where that file has lines like: $KEY.zrd.dq.spamhaus.net=127.0.2.[2..24] $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked where $KEY is my key, and the LHS of that line is exactly as it looks in reject_rhsbl_reverse_client (to give an example). add it to github ? Seems to work (meaning: postfix hasn't complained, and I continue to receive mail :), but given the little traffic I have I wanted an "offline verification" that this is the right way to do this. its still postfix postscreen that logs dnsbllog with key it could be mapped before syslog so postfix-logwatch does not reveal keys
Re: Hiding Spamhaus key from replies
On Mon, 18 Nov 2019, Benny Pedersen wrote: Bernardo Reino skrev den 2019-11-18 10:12: I have now done it with: rbl_reply_maps = texthash:/etc/postfix/dnsbl_reply_smtpd where that file has lines like: $KEY.zrd.dq.spamhaus.net=127.0.2.[2..24] $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked where $KEY is my key, and the LHS of that line is exactly as it looks in reject_rhsbl_reverse_client (to give an example). add it to github ? Of postfix? :) (If you mean of spamassassin-dqs, I'm not using it. I do use rspamd-dqs -- see below -- but there would still be nothing to add to that project, as my question is/was about postfix configuration). Seems to work (meaning: postfix hasn't complained, and I continue to receive mail :), but given the little traffic I have I wanted an "offline verification" that this is the right way to do this. its still postfix postscreen that logs dnsbllog with key it could be mapped before syslog so postfix-logwatch does not reveal keys I had the masking/censoring of the key already implemented for postscreen, using postscreen_dnsbl_reply_map. My question was about doing the same with smptd, i.e. if postscreen (for whatever reason) hasn't rejected the attempt. I also have spamhaus filtering with rspamd (so postscreen -> smtpd -> rspamd), so that even if both postscreen *and* smtpd do not reject the message (again, for whatever reason, e.g. misconfiguration), rspamd will deal with it (according to scoring rules, etc.) Logging (and logwatch) is not an issue, as I actually want to be able to see (for whatever reason) which blacklist was triggered and which response it gave, but thanks for the idea, which I'll keep mind, of filtering it out with rsyslog if/as necessary. Cheers.
Re: Problems with header checks
On Fr, Nov 08, 2019 at 03:31:05 +0100, Jaroslaw Rafa wrote: But in that case probably LDA is the best place to do such change. Some time ago I was doing something similar via procmail. I found a great program for procmail: https://fex.belwue.de/fstools/#aw2re It fixes the subject and can remove ML information from the subject as well. Shade and sweet water! Stephan -- |If your life was a horse, you'd have to shoot it.|
Re: block 'new style' TLDs ?
On 18 Nov 2019, at 06:04, Andrew Sullivan wrote: > At the same time, there are a _lot_ of anti-abuse techniques for mail that > don't rely on the broad hueristic of, "This TLD seems to suck,” and that > don't rely on establishing that rule as a permanent part of your > configuration. Yeah, but so many of the new TLDs entirely suck, and there are new ones all the time and no way to keep up until you start getting flooded with connections. > If we want the domain name system to be scalable and we want to have > interoperable mail, hand-crafting the list of "these suck" domains is not a > good way to go. The reality is that I’ve been looking at .top since it first started blasting spam across the Internet and I’ve never seen a single email that looked even like it could possibly be legitimate. I do not have the time (especially since no one is paying me) to keep track of however many hundreds (over a thousand, for sure) of TLDs there are to see which ones are maybe not entirely garbage fires. The fact that email still works at all is a testament to how much effort people are willing to put into getting the 1-3% of legitimate mail out of the unending onslaught of malware, spyware, phishing, and just run-of-the-mill spam that comprises the vast majority of email traffic. > That makes for the kind of brittle configuration that introduces later > problems when some new operator takes over .TLD-THAT-SUCKS and cleans it up > (or the same operator makes it better and starts producing reliably good, > well-behaving registrations). *IF* that happens, and I doubt it will, then that new owner will have gotten .TLD-THAT-SUCKS super cheap precisely because it is a garbage fire. They will have to spend some money letting people know it has been fixed. If AOL ever gets cleaned up (it won’t) and stops publishing all their users email addresses and passwords (they won’t) I might consider taking them off my blacklist. But it will take a LOT of convincing, just like I’m not going to hire a serial killer to babysit just because he says he stopped killing people and hasn’t for the last 15 minutes. > Hard coding the TLD into blocklists means that there is never any reward for > fixing stuff: everything is broken anyway, permanently, so the operator of > that TLD has zero incentive to make it better, ever. The way that the TLDs were expanded was idiotic and broken by design. Everyone knew this was exactly what was going to happen, and it did. There are no surprises here. If you have a domain in .xyz or .top you are surrounded by criminals, scammers. and scum. There’s going to be fallout. Get a better domain. > So, I would like to encourage people to find ways to stanch mail from bad > sources using reputation lists and so on, rather than wholesale blocking of > whole TLDs. I block *ALL* TLDs and then have a whitelist of the few TLDs I allow. That’s how bad it is. And yes, I do look periodically to see what sort of traffic there is (you can tell a whole lot by the from and the to that are logged with the NOQUEUE) and there has been three new TLDs that I have added to the whitelist, and I still get mostly spam from those (info, biz, and name). Even with rejecting 97% of mail, or more, most of the mail received is still junk mail. And I pay to store that and I pay to back it up. I’m not going to dedicate 40 times more storage for mail just because someone out there might have “legitimate” mail they want to send me from sexyp...@child.pron.ru, or even ap...@iphone.y9867842378423.top. -- On nights such as this, evil deeds are done. And good deeds, of course. But mostly evil deeds. --Wyrd Sisters
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: Non-ASCII bytes in email header and similar
David B?rgin: > Looking for protocol expertise that some here might have ? > > I understand that email header content should contain 7-bit ASCII-only. It can be UTF8 if Postfix has SMTPUTF8 support enabled and the client specified the SMTPUTF8 request in the MAIL FROM command. > However, as an implementor of email software such as a milter, how do I > best deal with non-conforming input? If it's not SMTPUTF8, then there is no way to specify the encoding for 'raw' text. See also http://www.postfix.org/SMTPUTF8_README.html for how Postfix handles headers. Wietse
Re: IP addresses in helo
On 18 Nov 2019, at 6:59, @lbutlr wrote: 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). Yes. There are cases of Special Needs Nodes (printers, antique Cisco gear, random IoT devices) which may not be able to do port 587 or 465 and can't contain the concept of their very own real hostname. Generally these are rare enough these days that it is feasible to handle them as exceptions. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: IP addresses in helo
On 18 Nov 2019, at 7:22, Gregory Heytings wrote: 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. So what? RFCs are not laws. There are no RFC police. 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. Hasn't happened for me in over a decade. I use a variety of patterns to match against the HELO argument and reject on that basis, of which a few (e.g. /.*\.local$/) have needed special exemptions for specific persistently stupid systems. I haven't needed to add to the special cases since 2008. e.g.: # Patterns used only by bad actors. /^local$/REJECT I don't know you /localhost$/REJECT you are not me /[REDACTED: INTERNAL RFC1918 RANGE PATTERN]/REJECT you are not me /[REDACTED: EXTERNAL ADDRESS RANGE PATTERN]/REJECT you are not me /127\.0\.0\.[0-9]/ REJECT you are not me # My public MX names, which are not used internally /^toaster.scconsult.com$/ REJECT you are not me /^sc1.scconsult.com$/ REJECT you are not me # My public mail domains, which are not the names of any actual hosts /^scconsult.com$/ REJECT you are not me /^billmail.scconsult.com$/ REJECT you are not me # Spamming botnets /^friend$/ REJECT You're not my friend /^DM$/ REJECT You are not the DM /^mail.com$/REJECT Suresh says no one is mail.com /^-/REJECT Try an imaginary number instead of a negative one. # Various well-meaning incompetents do dumb stuff [DUNNO EXEMPTIONS REDACTED] # Various commonly-seen bad patterns that may need exemptions (above) /.*\.local$/ REJECT You can't call yourself local when introducing yourself to the world. /.*\.localdomain$/ REJECT You can't call yourself local when introducing yourself to the world. /^[^.]*$/ REJECT Care to qualify that claim? /^[^a-z]*$/ REJECT USE YOUR WORDS LIKE A GROWN-UP! # # Places I absolutely do not want any mail from. [REDACTED: VALID-ISH NAMES IN NOMINALLY LEGIT DOMAINS THAT ONLY SEND SPAM] -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: IP addresses in helo
On 18 Nov 2019, at 8:55, Gregory Heytings wrote: 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". Irrelevant to HELO argument filtering. With other restrictions, your users will never receive emails from administrations, schools, hospitals, etc., not even in their spam box. 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. FWIW, across multiple mail systems and decades, I have never needed to exempt external sources from a requirement that a HELO/EHLO argument must contain letters and do not recall ever seeing a legitimate mail source using an IP literal or bare IP in HELO/EHLO in cases where such a restriction was impossible. Obviously your mail stream may differ, particularly if you accommodate submission on port 25. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: block 'new style' TLDs ?
On 11/18/2019 7:46 AM, @lbutlr wrote: On 18 Nov 2019, at 06:04, Andrew Sullivan wrote: At the same time, there are a _lot_ of anti-abuse techniques for mail that don't rely on the broad hueristic of, "This TLD seems to suck,” and that don't rely on establishing that rule as a permanent part of your configuration. Yeah, but so many of the new TLDs entirely suck, and there are new ones all the time and no way to keep up until you start getting flooded with connections. Globe Life is free to do what serves their interests, but it would be interesting to know what they were thinking when they decided to use "Globe.life" for transactional emails. Nothing screams scam louder than these new TLDs.
Re: IP addresses in helo
Bill Cole wrote: 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. IME exactly the opposite is true, because all too many automated notices are fire-and-forget - the senders don't even have the infrastructure to handle bounce messages, never mind bring them up to the attention of someone who can fix things. Or the notices are sent entirely by hand, but some "helpful" IT support monkey has gone and blacklisted all postmaster notices (or worse, sent them to /dev/null automatically). At least if the message gets misfiled in the recipient's spam folder they've got some chance of finding the actual message, and a better chance of then informing someone who can fix the misfiring filter. We had a case recently where a customer's one-man-band IT "support provider" couldn't seem to understand the idea that if our server tries to pass on a message and gets: 550 Rejected for spammy content back in a postmaster notice, any further investigation MUST be started by the recipient, because it's the recipient's mail system doing the rejecting. They had a couple of examples of rejected messages sent through other outbound servers to the same recipients, too, so it really was something to do with the content of their mail, not some property of our mail cluster. I have a feeling there will be Words Spoken when (almost certainly not "if") their move to Office 365 doesn't fix the problem. -kgd
Client host rejected
Hello,
I try to run postfix, rspamd and dovecot. The 3 stars :)
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 is example and this happen with Gmail and Mail.ru.
postconf -n
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
inet_interfaces = 127.0.0.1, 195.128.103.214
local_recipient_maps = $virtual_mailbox_maps
mailbox_size_limit = 0
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
minimal_backoff_time = 5m
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
mua_relay_restrictions =
reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions =
permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
mydestination =
myhostname = netcup.silviosiefke.com
mynetworks = 127.0.0.0/8
non_smtpd_milters = inet:127.0.0.1:11332
postscreen_access_list = permit_mynetworks cidr:/etc/postfix/postscreen_access
postscreen_blacklist_action = drop
postscreen_dnsbl_action = drop
postscreen_dnsbl_sites = ix.dnsbl.manitu.net*2 zen.spamhaus.org*2
postscreen_dnsbl_threshold = 2
postscreen_greet_action = drop
queue_run_delay = 5m
recipient_delimiter = +
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = high
smtp_tls_policy_maps = mysql:/etc/postfix/sql/tls-policy.cf
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_restrictions = permit_mynetworks check_client_access
hash:/etc/postfix/without_ptr reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_milters = inet:127.0.0.1:11332
smtpd_recipient_restrictions = check_recipient_access
mysql:/etc/postfix/sql/recipient-access.cf
smtpd_relay_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
smtpd_tls_cert_file =
/etc/letsencrypt/live/netcup.silviosiefke.com/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_key_file = /etc/letsencrypt/live/netcup.silviosiefke.com/privkey.pem
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_high_cipherlist =
EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
virtual_alias_maps = mysql:/etc/postfix/sql/aliases.cf
virtual_mailbox_domains = mysql:/etc/postfix/sql/domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/sql/accounts.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
Have here someone a idea what goes wrong? If need more infos ask.
Thank you
Silvio
Re: Client host rejected
On 18.11.19 17:16, siefke_lis...@web.de wrote: 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= smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/without_ptr reject_unknown_client_hostname cannot find your hostname indicated reject_unknown_client_hostname hit. 182.160.91.81.in-addr.arpa. 86294 INPTR office.denic.de. office.denic.de.3480IN A 81.91.160.182 seems something is wrong with your (or maybe their) reverse DNS resolution... however that's temporary error (4xx) and the client should try again. -- 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. Spam is for losers who can't get business any other way.
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
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.
On 18.11.19 18:10, Gregory Heytings wrote:
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.
Incorrect, content of helo might be safely used for filtering purposes.
hosts pretending to be you are safe to be rejected.
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.
Care must be taken about what is being rejected.
Examples are bogus or invalid helo (reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname), helo pointing to nonexistent hostname
(reject_unknown_helo_hostname) helo pretending to be the destination
domain/server (put your server name and IP here) and some others
("hotmail.com" hlo was common for spambots some time ago).
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.
A common answer to this is that the sender was supposed to get
error message. Since the message might be rejected anywhere between sender
and recipient, it's usually a must.
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.
If you want to receive any possible spam and send them to spam folder, it's
completely up to you. Just note that people with too many spams in spam folder
may start ignoring it and complain...
--
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.
On the other hand, you have different fingers.
Re: IP addresses in helo
On Mon, 18 Nov 2019 at 12:23, Dominic Raferd wrote: > > > On Mon, 18 Nov 2019 at 12:00, @lbutlr wrote: > >> 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). >> >> I have about 50,000 NOQUEUE reject from "helo=<[193.32.160.151]>" over >> the last week, for example. I see very few otherwise, and all are obviously >> spam with return addresses like account-security-nore...@091773.com or >> apple_supp...@0904.ru. >> > > Interesting idea. But I checked my records and - although YMMV - for us it > would have a lot of false positives. (BTW I couldn't do this through mail > logs because mine don't record the helo except when an incoming email is > rejected.) > Correction: actually I can't find any false-positives in my records (after I eliminated the false-false-positives...)
Re: Client host rejected
On Mon, 18 Nov 2019 17:23:43 +0100 Matus UHLAR - fantomas wrote: > cannot find your hostname indicated reject_unknown_client_hostname hit. Ah thank you this what I had search. > seems something is wrong with your (or maybe their) reverse DNS > resolution... This is what I had: [siefke@sisi-dell ~]$ nslookup 195.128.103.214 214.103.128.195.in-addr.arpaname = netcup.silviosiefke.com. Authoritative answers can be found from: [siefke@sisi-dell ~]$ dig mx silvio-siefke.de ; <<>> DiG 9.14.7 <<>> mx silvio-siefke.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54615 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;silvio-siefke.de. IN MX ;; ANSWER SECTION: silvio-siefke.de. 12745 IN MX 20 asia.silviosiefke.com. silvio-siefke.de. 12745 IN MX 10 netcup.silviosiefke.com. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mo Nov 18 18:34:50 CET 2019 ;; MSG SIZE rcvd: 105 Thank you for help & Nice day Silvio -- Silvio Siefke
Re: Client host rejected
On Mon, 18 Nov 2019, siefke_lis...@web.de wrote: On Mon, 18 Nov 2019 17:23:43 +0100 Matus UHLAR - fantomas wrote: cannot find your hostname indicated reject_unknown_client_hostname hit. Ah thank you this what I had search. seems something is wrong with your (or maybe their) reverse DNS resolution... This is what I had: [siefke@sisi-dell ~]$ nslookup 195.128.103.214 214.103.128.195.in-addr.arpaname = netcup.silviosiefke.com. The question is whether your resolver can reverse-resolve the IP address where the message was coming from, i.e. 81.91.160.182, and not your own (of your mail server). $ dig -x 81.91.160.182 office.denic.de.3600IN A 81.91.160.182 $ dig office.denic.de office.denic.de.3508IN A 81.91.160.182 which looks OK. See if your resolver also produces the above results. Cheers.
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
Relay attempt questions
Below is a postmaster notification about a relay attempt. The notification is from my server running 3.4.7 on debian stable. Out: 220 mail.acrasis.net ESMTP Postfix (Debian/GNU) In: HELO win-sa71d6ou2qs.domain Out: 250 mail.acrasis.net In: MAIL FROM: Out: 250 2.1.0 Ok In: RCPT TO:<***@gmail.com> Out: 554 5.7.1 <***@gmail.com>: Relay access denied (I've obscured the recipient address.) This notification makes sense to me. # postconf smtpd_relay_restrictions smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination # postconf smtpd_recipient_restrictions smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unverified_recipient, check_policy_service unix:private/policyd-spf The destination domain, gmail.com, is not mine and is not a relay domain, so the RCTP TO gets rejected. So far so good. (If I've already misunderstood something, let me know!) In the log however are things I don't understand. The log extract is below, with lines numbered for reference. Why did my server contact google (lines 7 and 8)? Is line 8 an "address verification probe"? Why did reject_unauth_destination (line 11) only take effect after the probe (line 8, if that's what it is) and after check_policy_service (line 10)? Did smtpd_relay_restrictions apply only after smtpd_recipient_restrictions? What have I misunderstood or misconfigured? Thanks. [Begin log] 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] [End log] -- Nick
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: Relay attempt questions
On 2019-11-18 23:05 GMT, Gregory Heytings wrote: > 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. 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? -- Nick
Re: IP addresses in helo
On 11/18/19 8:55 AM, Gregory Heytings wrote: > > 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. I don't believe the RFC has any MUST about the receiver having to accept any specific message of this kind, thus it isn't an RFC violation to reject it. (See your next comment quoting the RFC which admit that it is allowed (if discouraged) for a site to be selective on what mail it accepts. > >> >> 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 -- Richard Damon
Re: Relay attempt questions
On Mon, Nov 18, 2019 at 09:40:24PM +, Nick wrote: > Why did reject_unauth_destination (line 11) only take effect after the > probe (line 8, if that's what it is) and after check_policy_service > (line 10)? Because Postfix evaluates smtpd_relay_restrictions *after* it checks smtpd_recipient_restrictions. > Did smtpd_relay_restrictions apply only after > smtpd_recipient_restrictions? Yes. -- Viktor
how to setup storage for two different MX in different locations
Hello, We plan to setup two postfix as MX servers. One is in west location, such as CA state. Another is in east location, such as NYC. The question is, how to make storage shared by two MX servers? The messages should be stored in one place, such as webmail/IMAP could read all messages directly from this location. Thanks for any suggestion. regards.
Re: how to setup storage for two different MX in different locations
On Tue, 19 Nov 2019, Merrick wrote: The question is, how to make storage shared by two MX servers? MX (SMTP) servers don't store messages. They deliver them to whatever system makes them available to the users. (or do you mean you want have a shared queue? -- not recommended!) The messages should be stored in one place, such as webmail/IMAP could read all messages directly from this location. Use a single IMAP server. Have both mail servers deliver the messages to the single IMAP server.
Re: how to setup storage for two different MX in different locations
Bernardo Reino wrote: The messages should be stored in one place, such as webmail/IMAP could read all messages directly from this location. Use a single IMAP server. Have both mail servers deliver the messages to the single IMAP server. Do you mean I setup a single IMAP server in middle location (such as Dallas) then both MX servers deliver messages to the IMAP? regards.
