Re: Accessing the sending user from a canonical(5) table
> On Oct 17, 2020, at 2:55 AM, Demi M. Obenour wrote: > > Should I submit another patch? In addition to adding > local_sender_login_maps, I have fixed what appeared to be a bug in > the current postdrop and sendmail commands: root and $mail_owner were > not automatically allowed to submit mail. Since this is inconsi I don't see why either "root" or "postfix" should be exempt from authorized_submit_users. No such exemption is documented or intended. -- Viktor.
Re: possible bottlenecks
> On Oct 17, 2020, at 3:09 AM, Demi M. Obenour wrote: > >> The practical limit to the deferred queue size is therefore ~2 days of >> throughput, and depends heavily on the per-delivery latency. If >> delivery failures are slow (tarpitting or otherwise slow destinations) >> the impact is greater. > > Can the latency problems be worked around by increasing concurrency? Yes, so unsurprisingly, Postfix amortises latency via carefully managed concurrency. > My understanding is that Postfix might have problems at very high > concurrency due to using one process per connection, whereas some > other servers are event-driven and can handle thousands of connections > without using too much memory. Postfix reuses processes for multiple deliveries, so process creation is effectively amortised. SMTP delivery being a rather expensive operation (DNS lookups, connection setup, TLS handshakes, ...) the fractional (becase shared across multiple deliveries) cost of process creation is dwarfed by the actual SMTP transaction costs. On modern hardware (anything built in the last ~2 decades), you can run thousands of concurrent SMTP delivery agents, without any difficulty, their executables are loaded only once, and per connection memory utilisation is modest. You run out of remote sites' willingness to receive your email long before you run out of local capacity to send it. The event driven design mostly just makes those other servers more complex, and more prone to security bugs. Postfix 3.4 and later grudgingly do some event-driven work because TLS connection reuse with OpenSSL is not possible out-of-process. So the tlsproxy(8) process context switches between multiple TLS connections, but the rest of the SMTP delivery agent is one connection per process and performs just fine. The architecture is however more robust and secure. Postfix is not an HTTP server handling tens to hundreds of thousands of requests per second, and does not benefit from the optimisations needed for those kinds of workloads. Premature optimisations that sacrifice robustness and security for little gain are not part of the design. -- Viktor.
Re: Forward being rejected because of spf
On 16 Oct 2020, at 23:51, Joey J wrote: Hello All, I'm trying to figure out the workaround for when a domain sends an email to lets say 1...@abc.com and then that is supposed to forward to b...@xyz.com but b...@xyz.com postfix is rejecting the message: (Yes, names and IP's have been changed to protect the innocent) Oct 16 23:16:12 mgw postfix/smtpd[1443]: connect from postfix.xyz.com [152.30.131.212] Oct 16 23:16:12 mgw postfix/smtpd[1443]: Anonymous TLS connection established from postfix.xyz.com[152.30.131.212]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Oct 16 23:16:12 mgw postfix/smtpd[1443]: NOQUEUE: reject: RCPT from postfix.xyz.com[152.30.131.212]: 554 5.7.1 : Recipient address rejected: Rejected by SPF: 152.30.131.212 is not a designated mailserver for noreply%40e .fiverr.com (context mfrom, on mgw.innovativeinternet.net); from= to= proto=ESMTP helo= Oct 16 23:16:13 mgw postfix/smtpd[1443]: disconnect from postfix.xyz.com[152.30.131.212] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7 This a well-known feature of SPF: it is incompatible with traditional transparent forwarding as done with aliases or .forward files. The possible workarounds are: 1. If you run the destination mail server, don't enforce SPF so strictly. 2. Rewrite the sender using SRS. There are multiple tools that will do SRS via TCP lookup tables (e.g. PostSRSd) or milter (there appear to be multiple variants of "srs-milter"). 3. Encapsulate forwarded messages in new messages that you send with a sender in your own domain which you can programatically convert back to the original sender for bounces. If I was doing this I'd use MIMEDefang (a milter that can be extended to do anything you can write Perl for) but I'm biased. 4. Instead of forwarding, deliver locally and have the user pull their mail to the target mailbox via POP3 or IMAP. GMail (and probably other webmail providers) supports this. There are also tools like imapsync, getmail, and fetchmail which one can use to pull mail from one email account and dump it into another. The major advantages of this "pull" model for you as the intermediate system are: A. You aren't responsible for managing a 2-way address translation mechanism (e.g. SRS or encapsulation) to support bounces which will mostly end up being undeliverable anyway. B. The receiving system won't see you as a spam source for forwarding what they deem to be spam via SMTP. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: possible bottlenecks
On 10/16/20 9:24 PM, Viktor Dukhovni wrote: > The practical limit to the deferred queue size is therefore ~2 days of > throughput, and depends heavily on the per-delivery latency. If > delivery failures are slow (tarpitting or otherwise slow destinations) > the impact is greater. Can the latency problems be worked around by increasing concurrency? My understanding is that Postfix might have problems at very high concurrency due to using one process per connection, whereas some other servers are event-driven and can handle thousands of connections without using too much memory. > There is no magic that can make OpenSMTPD immune to the laws of > arithmetic. Indeed there is not. Any statement to that effect on my part was erroneous and based on a misunderstanding. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Mail server recently became an open relay
On 2020-10-16 21:16, Bill Cole wrote: > Based on your config and descriptions, it smells like a compromised > account being used to pump mail through your submission service. A full > set of log lines for one of the messages should reveal that. The > master.cf lines for smtpd and submission would also help. Thanks. I'll look into this. Rich Wales ri...@richw.org
Re: Accessing the sending user from a canonical(5) table
Should I submit another patch? In addition to adding local_sender_login_maps, I have fixed what appeared to be a bug in the current postdrop and sendmail commands: root and $mail_owner were not automatically allowed to submit mail. Since this is inconsistent with similar checks elsewhere, I believe it is unintentional. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Mail server recently became an open relay
On 16 Oct 2020, at 18:20, Rich Wales wrote: Hi. My mail server (memoryalpha.richw.org), running Postfix 3.3.0, recently started attracting open relay spam. I thought I had done all the appropriate things in Postfix to block open relay traffic, and I hadn't seen any such traffic for a very long time, but suddenly I've gotten three attacks in the last two days (plus another one a couple of weeks ago). I'm attaching the output of "postconf -nf". You'll note that I'm using amavisd-new as a spam filter (which has worked fine for a very long time). The log info from amavisd-new identifies the messages in question as probably coming via an open relay, but it still passes them. What confuses me is that I would expect Postfix to have identified and rejected these messages during the initial SMTP dialogue with the sender, and they should never reach amavisd-new. Any suggestions gratefully welcome. Based on your config and descriptions, it smells like a compromised account being used to pump mail through your submission service. A full set of log lines for one of the messages should reveal that. The master.cf lines for smtpd and submission would also help. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Forward being rejected because of spf
Hello All, I'm trying to figure out the workaround for when a domain sends an email to lets say 1...@abc.com and then that is supposed to forward to b...@xyz.com but b...@xyz.com postfix is rejecting the message: (Yes, names and IP's have been changed to protect the innocent) Oct 16 23:16:12 mgw postfix/smtpd[1443]: connect from postfix.xyz.com [152.30.131.212] Oct 16 23:16:12 mgw postfix/smtpd[1443]: Anonymous TLS connection established from postfix.xyz.com[152.30.131.212]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Oct 16 23:16:12 mgw postfix/smtpd[1443]: NOQUEUE: reject: RCPT from postfix.xyz.com[152.30.131.212]: 554 5.7.1 : Recipient address rejected: Rejected by SPF: 152.30.131.212 is not a designated mailserver for noreply%40e.fiverr.com (context mfrom, on mgw.innovativeinternet.net); from= to= proto=ESMTP helo= Oct 16 23:16:13 mgw postfix/smtpd[1443]: disconnect from postfix.xyz.com[152.30.131.212] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7 -- Thanks! Joey
Re: Mail server recently became an open relay
On Oct 16, 2020, at 11:17 PM, Rich Wales wrote: > > No, Viktor, I have not deleted my logs. However, there is so much stuff > in the Postfix log (/var/log/mail.log on my system) -- including both > good e-mail messages and bad, overlapped every which-way, multiple > Postfix processes, etc. -- that I don't think I can reasonably hope for > anyone to be able to decipher even a time-delimited excerpt. Well, of course I wasn't asking for the raw log file, just a sample of a few problem messages... > Are there any tools available to make sense of the Postfix log? In the > DEBUG_README document, there is mention of something called postfinger, > but it appears to be missing (the ftp.wl0.org site is nonexistent). https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate > I've enabled verbosity (smtpd -v) for the "smtpd" line in my master.cf, > in hopes that this may capture some additional detail of inbound SMTP > sessions. Any other debugging suggestions would be welcomed. No, turn that off. It just makes it much harder to see the important bits. -- Viktor.
Re: possible bottlenecks
On Fri, Oct 16, 2020 at 02:37:04PM -0400, Demi M. Obenour wrote: > > Unless there's a particularly good reason why you believe that OpenSMTPD > > would do better than Postfix in bulk mail delivery performance, it is not > > helpful to recommend it here. > > I misunderstood your previous message, sorry. I interpreted it as a > statement that Postfix struggles with very large mail queues, and I > know OpenSMTPD does not. There is no MTA which is able to retry an arbitrarily large queue in the face of remote tempfailures without the retry times stretching out to unnacceptably large values. This is a mathematical fact. Given that the output rate is bounded, the time taken to process a large backlog grows with the size of the backlog. The practical limit to the deferred queue size is therefore ~2 days of throughput, and depends heavily on the per-delivery latency. If delivery failures are slow (tarpitting or otherwise slow destinations) the impact is greater. There is no magic that can make OpenSMTPD immune to the laws of arithmetic. Otherwise, with appriate choices of hash_queue_depth and hash_queue_names, Postfix handles backlogs in the low millions of messages, because anything much higher simply will not get processed quickly enough in a reasonable time. -- Viktor.
Re: Mail server recently became an open relay
No, Viktor, I have not deleted my logs. However, there is so much stuff in the Postfix log (/var/log/mail.log on my system) -- including both good e-mail messages and bad, overlapped every which-way, multiple Postfix processes, etc. -- that I don't think I can reasonably hope for anyone to be able to decipher even a time-delimited excerpt. Are there any tools available to make sense of the Postfix log? In the DEBUG_README document, there is mention of something called postfinger, but it appears to be missing (the ftp.wl0.org site is nonexistent). I've enabled verbosity (smtpd -v) for the "smtpd" line in my master.cf, in hopes that this may capture some additional detail of inbound SMTP sessions. Any other debugging suggestions would be welcomed. I'll be back when I have something reasonably useful for you to look at. Rich Wales ri...@richw.org
Re: Mail server recently became an open relay
On Oct 16, 2020, at 10:28 PM, Rich Wales wrote: > > The next time I see this happen -- could be tomorrow, could be weeks > from now, I have no idea when -- I'll gladly forward a copy of my > "mailq" output. I deleted my earlier evidence, I'm afraid. No "mailq" output needed. Just the relevant entries from your logs. Have you deleted your logs? Also of course your configuration, per: http://www.postfix.org/DEBUG_README.html#mail -- Viktor.
Re: Mail server recently became an open relay
> Why do you believe that your server is an open relay, as in, it > will forward messages FROM spammers TO remote destinations. > Wietse Because it *is* accepting messages from outsiders (spammers) and is using my server to relay those messages to remote destinations. It was (and still is) my understanding that such messages should be rejected by Postfix during the SMTP dialogue, with an error to the client saying relay access is denied -- though I assume I inadvertently either failed to enable this check or have somehow broken it. I've run several open relay test sites on my server, and all of them claim it is clean, but I have seen numerous mail queue listings with such messages clogging up my system because the destination sites are correctly identifying them as being relayed and won't accept them. I didn't think such messages were supposed to make it into the queue, but should instead have been rejected by me with an SMTP error sent back to the sending client. One of these incidents, btw (two weeks ago), created a mail queue of over 50,000 messages before I noticed it and cleaned up the mess. It took about a day after that for my server to get taken off the GBUDB blacklist site. The next time I see this happen -- could be tomorrow, could be weeks from now, I have no idea when -- I'll gladly forward a copy of my "mailq" output. I deleted my earlier evidence, I'm afraid. Rich Wales ri...@richw.org
Re: Recommended milters for small setup
On Thu, Oct 15, 2020 at 12:44 PM PGNet Dev wrote: > On 10/15/20 8:19 AM, Ian Evans wrote: > > > Is there a more efficient, memory stingy, faster milter way to run > spamassassin, clamav, etc, or would you recommend sticking with amavis? > > > > very much personal choice. each comes with it's challenges. > for any set of choices, you'll get the usual assortment of pundits > telling you why it's Bad(tm). > > > i'm not a fan of 'swiss army knife' apps that try to be all things to all > people; i prefer the option to rip out & swap individual pieces if/as > needed. > > having _had_ that^ same stack, i first rm'd amavis > . > > > now, i've got: > > inbound: > > postscreen > > spf-engine (policy service) > > pre-q milters: > >opendkim >opendmarc >milter-regex >clamav-milter >spamassassin-milter (https://lib.rs/crates/spamassassin-milter) > > outbound: > > opendkim > > > for inbound, i'd like to replace opendkim/opendmarc with > fastmail/authentication_milter -- > -- but the project devs aren't terribly responsive. not clear yet whether > it's as bad as 'Trusted Domain Project' opendkim/opendmarc ... > > for outbound, i'd again like to get rid of opendkim. but, so far, i've > found no good packaged options that fit my needs. > > DIY with Mail::DKIM is a pain, but doable, and on my "I'll get around to > it eventually" list. > > atm -- although it all still _feels_ a bit fragile -- this current setup > is working well enough. > > certainly lighter-weight than b4, and for me simpler to configure/manage. > > my $0.02. > thanks to everyone for the suggestions. some food for thought. have a great weekend,
Re: rbl check debug
On Fri, Oct 16, 2020 at 06:04:20PM -0300, David Wells wrote: > > smtpd_recipient_restrictions = > > permit_mynetworks, permit_sasl_authenticated, > > check_sender_access hash:/etc/postfix/sender_access, > > check_recipient_access hash:/etc/postfix/protected_destinations, > > check_client_access hash:/etc/postfix/rbl_whitelist, > > check_client_access regexp:/etc/postfix/rbl_whitelist_regexp, > > reject_unauth_destination, Wietse's answer is the most obvious starting point, but if you want to also look elsewhere: Why is there a "check_sender_access" *before* "reject_unauth_destination", and before the RBL checks? Does the "sender_access" table have anything other than REJECT rules? > > reject_rbl_client zen.spamhaus.org, > > reject_rbl_client bl.spamcop.net, > > reject_rbl_client dnsbl.sorbs.net, > > reject_rbl_client dyna.spamrats.com, > > reject_rbl_client spam.spamrats.com, > > reject_rbl_client noptr.spamrats.com, > > reject_rbl_client auth.spamrats.com, > > reject_rbl_client dnsbl-1.uceprotect.net, > > reject_rbl_client dnsbl-2.uceprotect.net, > > reject_rbl_client dnsbl-3.uceprotect.net, > > reject_rbl_client b.barracudacentral.org, > > reject_rbl_client dnsbl.spfbl.net, > > reject_rbl_client rbl.blockedservers.com, > > reject_rbl_client bl.mailspike.net, > > reject_rbl_client bl.nosolicitado.org, > > reject_rbl_client all.s5h.net That's way too many, and many certainly too aggressive to be sufficient on their own for a definitive reject. Just zen.spamhaus.org is generally all you can use without combining results for scoring. And you certainly don't need a "noptr" list, just use: reject_unknown_reverse_client_hostname > > smtpd_restriction_classes = insiders_only Where does this come into play? -- Viktor.
Re: Mail server recently became an open relay
I would think running an open relay test would be step one. https://mxtoolbox.com/diagnostic.aspx There are probably half a dozen online services that do this. Which brings me to my question: Is there an open relay test website that is considered the best? I have noticed some run multiple tests which I assume means different methods. Original Message From: wie...@porcupine.org Sent: October 16, 2020 3:27 PM To: postfix-users@postfix.org Reply-to: postfix-users@postfix.org Subject: Re: Mail server recently became an open relay Rich Wales: > Hi. My mail server (memoryalpha.richw.org), running Postfix 3.3.0, > recently started attracting open relay spam. I thought I had done all Why do you believe that your server is an open relay, as in, it will forward messages FROM spammers TO remote destinations. Wietse
Re: Mail server recently became an open relay
Rich Wales: > Hi. My mail server (memoryalpha.richw.org), running Postfix 3.3.0, > recently started attracting open relay spam. I thought I had done all Why do you believe that your server is an open relay, as in, it will forward messages FROM spammers TO remote destinations. Wietse
Mail server recently became an open relay
Hi. My mail server (memoryalpha.richw.org), running Postfix 3.3.0, recently started attracting open relay spam. I thought I had done all the appropriate things in Postfix to block open relay traffic, and I hadn't seen any such traffic for a very long time, but suddenly I've gotten three attacks in the last two days (plus another one a couple of weeks ago). I'm attaching the output of "postconf -nf". You'll note that I'm using amavisd-new as a spam filter (which has worked fine for a very long time). The log info from amavisd-new identifies the messages in question as probably coming via an open relay, but it still passes them. What confuses me is that I would expect Postfix to have identified and rejected these messages during the initial SMTP dialogue with the sender, and they should never reach amavisd-new. Any suggestions gratefully welcome. Rich Wales ri...@richw.org alias_maps = hash:/etc/aliases append_dot_mydomain = yes compatibility_level = 2 default_destination_concurrency_limit = 1 default_destination_recipient_limit = 1 disable_vrfy_command = yes enable_long_queue_ids = yes fast_flush_domains = hopcount_limit = 150 inet_protocols = ipv4 lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3 lmtp_tls_protocols = !SSLv2, !SSLv3 local_destination_concurrency_limit = 1 local_destination_recipient_limit = 1 local_recipient_maps = $alias_maps mail_owner = postfix mailbox_transport = lmtp:[127.0.0.1] maximal_queue_lifetime = 30d message_size_limit = 5000 message_strip_characters = \0 milter_default_action = accept milter_protocol = 2 mydestination = richw.org, richw.ca, pcre:/etc/postfix/richw_subdomains, localhost, marywalesloomis.com mydomain = richw.org myhostname = memoryalpha.richw.org mynetworks = 127.0.0.0/8, 10.0.229.0/24, 96.82.71.8/29, mynetworks_style = subnet myorigin = $myhostname postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr postscreen_bare_newline_action = ignore postscreen_bare_newline_enable = yes postscreen_blacklist_action = enforce postscreen_dnsbl_action = enforce postscreen_dnsbl_max_ttl = 3h postscreen_dnsbl_min_ttl = 30m postscreen_dnsbl_sites = whitelist.richw.org=127.0.0.1*-100, hostkarma.junkemailfilter.com=127.0.0.1*-30, score.senderscore.com=127.0.4.[91..100]*-30, score.senderscore.com=127.0.4.[71..90]*-24, list.dnswl.org=127.0.[0..255].3*-16, list.dnswl.org=127.0.[0..255].2*-8, list.dnswl.org=127.0.[0..255].1*-4, list.dnswl.org=127.0.[0..255].0*-2, blacklist.richw.org=127.0.0.2*100, zen.spamhaus.org=127.0.0.[2..255]*40, dnsbl.justspam.org=127.0.0.[2..255]*20, hostkarma.junkemailfilter.com=127.0.0.2*10, dyna.spamrats.com=127.0.0.36*9, b.barracudacentral.org=127.0.0.2*8, truncate.gbudb.net=127.0.0.[2..255]*6, rbl.megarbl.net=127.0.0.2*4, hostkarma.junkemailfilter.com=127.0.0.4*3, psbl.surriel.com=127.0.0.[2..255]*2, dnsbl.sorbs.net=127.0.0.[2..255]*2, bl.spamcop.net=127.0.0.[2..255]*2, multi.surbl.org=127.0.0.[2..255]*2 postscreen_dnsbl_threshold = 7 postscreen_dnsbl_whitelist_threshold = -16 postscreen_greet_action = enforce postscreen_greet_banner = $myhostname Please stand by . . . postscreen_non_smtp_command_action = enforce postscreen_non_smtp_command_enable = yes postscreen_pipelining_action = enforce postscreen_pipelining_enable = yes relay_destination_recipient_limit = 1 relay_domains = indigo.richw.org, goldsmurf.randerzo.net smtp_address_preference = ipv4 smtp_destination_concurrency_limit = 1 smtp_destination_recipient_limit = 1 smtp_reply_filter = pcre:/etc/postfix/reply_filter smtp_sasl_auth_enable = yes smtp_sasl_mechanism_filter = PLAIN LOGIN smtp_sasl_password_maps = hash:/etc/postfix/sasl_fallback smtp_sasl_security_options = noanonymous smtp_sender_dependent_authentication = no smtp_tls_ciphers = medium smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtpd_banner = $smtpd_banner_regular smtpd_banner_fallback = $smtpd_banner_regular (fallback) smtpd_banner_regular = $myhostname ESMTP smtpd_banner_submission = $smtpd_banner_regular (Postfix $mail_version -- submission) smtpd_client_restrictions = permit_mynetworks, permit_dnswl_client whitelist.richw.org=127.0.0.1, permit_rhswl_client whitelist.richw.org=127.0.0.1, reject_rbl_client blacklist.richw.org=127.0.0.2, reject_rhsbl_client blacklist.richw.org=127.0.0.2, reject_rhsbl_client dbl.spamhaus.org=127.0.1.[0..255] smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_discard_ehlo_keywords = dsn etrn size vrfy silent-discard smtpd_etrn_restrictions = reject smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, permit_rhswl_client whitelist.richw.org=127.0.0.1, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, reject_rhsbl_helo blacklist.richw.org=127.0.0.2, reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[0..255] smtpd_recipient_restrictions =
Re: rbl check debug
David Wells: > Hi! > > I have a postfix-3.3.2 installation (installed from source on slackware > 14.2 from the slackbuilds package) that does rbl checks in the > smtpd_recipient_restrictions section. I have been seeing an increasing > amount of spam coming in so I added more reject_rbl_client instances > listing more and more rbl servers. However I still am seeing large > ammounts of spam getting through and I have checked several mails that > have come in using http://multirbl.valli.org/ and the servers from which > they arrive are listed in at least one of these rbl checks, most times > in more than one. Is there a way to debug why these mails are getting > through even though they come from an rbl blacklisted server? Check the time TIME STAMPS in your logs. Spammers are not immediately listed. There is a delay during which a DNSBL will not list a spammer's IP address. By the time that you do a maual DNSBL lookup, the DNSBL may have been updated. Another possible reason is that DNS lookup result times out or fails for other reasons; Postfix will log such problems. Wietse > >
rbl check debug
Hi!
I have a postfix-3.3.2 installation (installed from source on slackware
14.2 from the slackbuilds package) that does rbl checks in the
smtpd_recipient_restrictions section. I have been seeing an increasing
amount of spam coming in so I added more reject_rbl_client instances
listing more and more rbl servers. However I still am seeing large
ammounts of spam getting through and I have checked several mails that
have come in using http://multirbl.valli.org/ and the servers from which
they arrive are listed in at least one of these rbl checks, most times
in more than one. Is there a way to debug why these mails are getting
through even though they come from an rbl blacklisted server?
This is the output of postconf -n
command_directory = /usr/sbin
compatibility_level = 2
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
html_directory = /usr/doc/postfix-3.3.2/html
inet_protocols = ipv4
insiders_only = check_sender_access hash:/etc/postfix/insiders, reject
mail_owner = postfix
mailbox_command = /usr/libexec/dovecot/deliver -f "$SENDER" -a
"$RECIPIENT"
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/man
message_size_limit = 20971520
meta_directory = /etc/postfix
mydestination = $myhostname localhost.$mydomain localhost $mydomain
mydomain = alfavinil.com
myhostname = mail.alfavinil.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/doc/postfix-3.3.2/README_FILES
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
shlib_directory = /usr/lib/postfix
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access
smtpd_helo_required = yes
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, check_sender_access
hash:/etc/postfix/sender_access, check_recipient_access
hash:/etc/postfix/protected_destinations, check_client_access
hash:/etc/postfix/rbl_whitelist, check_client_access
regexp:/etc/postfix/rbl_whitelist_regexp, reject_unauth_destination,
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net, reject_rbl_client
dyna.spamrats.com, reject_rbl_client spam.spamrats.com,
reject_rbl_client noptr.spamrats.com, reject_rbl_client
auth.spamrats.com, reject_rbl_client dnsbl-1.uceprotect.net,
reject_rbl_client dnsbl-2.uceprotect.net, reject_rbl_client
dnsbl-3.uceprotect.net, reject_rbl_client b.barracudacentral.org,
reject_rbl_client dnsbl.spfbl.net, reject_rbl_client
rbl.blockedservers.com, reject_rbl_client bl.mailspike.net,
reject_rbl_client bl.nosolicitado.org, reject_rbl_client all.s5h.net
smtpd_restriction_classes = insiders_only
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_tls_CApath = /etc/ssl/certs
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/fullchain.pem
smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_key_file = /etc/ssl/private/privkey.pem
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
These are the contents of rbl_whitelist
axoft.com OK
rgcc.com.ar OK
arnetbiz.com.ar OK
websitewelcome.com OK
messagelabs.com OK
perfora.net OK
toservers.com OK
grupooperadores.com OK
ecs-publi.erreparmail.com OK
mx236-39.interman.com.ar OK
interquimica.com.uy OK
bma-borrachas.com.br OK
repicky.com.ar OK
200.47.67.78 OK
srv25.repicky.local OK
ecs-srv5.erreparmail.com OK
adiel.toservers.com OK
190.61.250.130 OK
These are the contents of rbl_whitelist_regexp
/^mail-.*\.google\.com$/ OK
/^sonic.*\.yahoo\.com$/ OK
/^rout.*\.hes\.trendmicro\.com$/ OK
/^semf.*\.mfg\.siteprotect\.com$/ OK
/^mx.*-.*\.interman\.com\.ar$/ OK
/^sender.*-of-o.*\.zoho\.com$/ OK
/^hm.*-.*\.locaweb\.com\.br$/ OK
/^srv.*\.repicky\.local$/ OK
/^ecs-srv.*\.erreparmail\.com$/ OK
Thanks!
Best regards,
David Wells.
Re: Mail server without MX record
Someone mentioned earlier that the OP (Jason Long) might be a bot. While I personally don't think this is the case, I do think we might be getting trolled... A quick Google search shows that this same username\email is on several different sites recently asking similar questions for a variety of products. Just my .02... https://www.google.com/search?q=jason+long+hack3rcon
Re: implementing offline/maintenance mode, with SMTP reply?
PGNet Dev:
> my usual postfix front-end workflow is
>
> postscreen
> if 'fail', reject
> if 'pass', then
> internal smtp
> etc
>
> i'd like to implement a 'maintenance/offline mode' -- WITH smtp response --
> effectively adding
>
> postscreen
> if 'fail', reject
> if 'pass', then
> + if 'maintenance mode' = ON, then
> + reply SMTP 4XX, msg = (user specified message,
> e.g. down 4 maintenance, try again in X hours)
> + else if 'maintenance mode' = OFF, then
> internal smtp
> etc
>
> there are many paths to that particular mountain.
>
> is there an already built-in maintenance-mode, or somesuch, in postfix?
> it'd be most convenient; if it's in docs, i've missed it.
Just let it pass to real smtpd, then reject there.
smtpd_client_restrictions =
check_client_access static:{421 Service down for maintenance}
# Use if you don't care what mail you aren't receiving.
smtpd_relay_reject = no
With 421, Postfix will hang up.
Wietse
Re: implementing offline/maintenance mode, with SMTP reply?
On Fri, Oct 16, 2020 at 10:51:52AM -0700, PGNet Dev wrote: > is there an already built-in maintenance-mode, or somesuch, in postfix? > it'd be most convenient; if it's in docs, i've missed it. Just shut down Postfix, that's equivalent to returning 4xx. Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, "Obsession", stardate 3620.7
Re: implementing offline/maintenance mode, with SMTP reply?
On Fri, Oct 16, 2020 at 10:51:52AM -0700, PGNet Dev wrote:
> my usual postfix front-end workflow is
>
> postscreen
> if 'fail', reject
> if 'pass', then
> internal smtp
> etc
>
> i'd like to implement a 'maintenance/offline mode' -- WITH smtp response --
> effectively adding
>
> postscreen
> if 'fail', reject
> if 'pass', then
> + if 'maintenance mode' = ON, then
> + reply SMTP 4XX, msg = (user specified message,
> e.g. down 4 maintenance, try again in X hours)
> + else if 'maintenance mode' = OFF, then
> internal smtp
> etc
That can just be handled via smtpd(8) (your 'internal smtp'):
> is there an already built-in maintenance-mode, or somesuch, in postfix?
> it'd be most convenient; if it's in docs, i've missed it.
If the custom 4XX response is not a hard requirement, the simplest
solution is:
main.cf:
# To defer all email, change to: lunchtime = y
lunchtime =
smtpd_recipient_restrictions =
${lunchtime?defer_if_permit}
...
Which will still reject invalid recipients, ... and only defer what
you'd otherwise accept.
See:
http://www.postfix.org/postconf.5.html#defer_if_permit
http://www.postfix.org/postconf.5.html
If you really must have a custom 4XX response, then you can use:
main.cf:
# To defer all email, change to: lunchtime = y
lunchtime =
smtpd_client_restrictions =
${lunchtime?check_client_access static:{450 4.3.2 Scheduled
downtime, come back later}}
...
Note that sites that do sender-address-verification (does anyone still
do that?) may then tempfail your outbound mail, during the downtime and
likely for some time after after you restore service.
--
Viktor.
Re: possible bottlenecks
On 10/16/20 2:10 PM, Viktor Dukhovni wrote: >> On Oct 16, 2020, at 3:14 PM, Demi M. Obenour wrote: >> >> I don’t recommend stock OpenSMTPD for security reasons, although I >> have some patches that make it much better in this regard. However, >> all of those relate to local deliveries. If you can afford to disable >> local deliveries, OpenSMTPD is actually a good choice for this work. >> It can handle multi-million-message queues without any problems. > > Well, for good performance one should not have much of a queue at all, > the mail should go out as quickly as it comes in. If you're queueing > a lot of email, then your output is not keeping up with the input. Not necessarily. It is quite possible for the peak rate of incoming traffic to be greater than the average rate at which it can be delivered, even though the average rate of incoming mail is lower than the average delivery rate. That will result in queues forming and eventually draining. If the bursty traffic is distributed among multiple recipients with their own, separate rate limits, it is quite possible to have a queue of finite size at quasi-steady-state. > Unless there's a particularly good reason why you believe that OpenSMTPD > would do better than Postfix in bulk mail delivery performance, it is not > helpful to recommend it here. I misunderstood your previous message, sorry. I interpreted it as a statement that Postfix struggles with very large mail queues, and I know OpenSMTPD does not. Apologies, Demi M. Obenour OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: possible bottlenecks
> On Oct 16, 2020, at 3:14 PM, Demi M. Obenour wrote: > > I don’t recommend stock OpenSMTPD for security reasons, although I > have some patches that make it much better in this regard. However, > all of those relate to local deliveries. If you can afford to disable > local deliveries, OpenSMTPD is actually a good choice for this work. > It can handle multi-million-message queues without any problems. Well, for good performance one should not have much of a queue at all, the mail should go out as quickly as it comes in. If you're queueing a lot of email, then your output is not keeping up with the input. Unless there's a particularly good reason why you believe that OpenSMTPD would do better than Postfix in bulk mail delivery performance, it is not helpful to recommend it here. -- Viktor.
implementing offline/maintenance mode, with SMTP reply?
my usual postfix front-end workflow is postscreen if 'fail', reject if 'pass', then internal smtp etc i'd like to implement a 'maintenance/offline mode' -- WITH smtp response -- effectively adding postscreen if 'fail', reject if 'pass', then + if 'maintenance mode' = ON, then + reply SMTP 4XX, msg = (user specified message, e.g. down 4 maintenance, try again in X hours) + else if 'maintenance mode' = OFF, then internal smtp etc there are many paths to that particular mountain. is there an already built-in maintenance-mode, or somesuch, in postfix? it'd be most convenient; if it's in docs, i've missed it. i thought about monkeying with stress-adaptive behavior, but that seems like a bad rabbit-hole for this ...
Re: possible bottlenecks
On 10/16/20 8:57 AM, @lbutlr wrote: > On 13 Oct 2020, at 22:47, Zsombor B wrote: >> I know this is a complicated question but what/where do you see possible >> bottlenecks in postfix? >> Is it CPU? RAM? Disk IO? > > In theory? Sure, any of those could be a bottle neck. On actuality, the > bottles necks are processing spam if you receive mail and not appearing to be > a spammer. > >> I'm building an infra to send out ~3-5 million emails a day. > > If you pop onto the Internet all of a sudden sending 5 million emails a day > you better be sure that your DKIM SPF DMARC and DNS are perfect and that your > IP address has never been associated with a spammer. Because if there is one > thing that will cripple your mail server it is having mail sit in queue > because it's been throttled. The big email hosts do this a lot (especially > Outlook.com and yahoo.com). And if you get on their (automated) bad side, you > are well and thoroughly screwed. If you messages LOOK spammy enough that > users will mark them as spam, then you will, again, be completely hosed > whether the email is spam or not. > > Other than that, I think a raspberry pi 4 with a USB SSD might be able to > mange 5 million emails a day. I don’t recommend stock OpenSMTPD for security reasons, although I have some patches that make it much better in this regard. However, all of those relate to local deliveries. If you can afford to disable local deliveries, OpenSMTPD is actually a good choice for this work. It can handle multi-million-message queues without any problems. That said, you will run into numerous other problems. https://www.mail-archive.com/misc@opensmtpd.org/msg05153.html is a good introduction to them. Gilles Chehade (the author of that post, and formerly one of the two main developers of OpenSMTPD) is an expert on the subject, and I trust his recommendation. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Mail server without MX record.
Thank you. I got my answer with your text. On Friday, October 16, 2020, 02:19:20 PM GMT+3:30, Jaroslaw Rafa wrote: Dnia 16.10.2020 o godz. 08:02:30 Jason Long pisze: > Thank you. > Thus, in Postfix or Dovecot configuration file I can't change the standard > record? We already wrote you a few times, that DNS configuration (A/MX record) has NOTHING TO DO with Postfix or Dovecot configuration. NOTHING. These are COMPLETELY DIFFERENT SERVICES. Period. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Trualias: tcp_virtual_server doesn't require patching local(8)
We're friends, right? Regardless, I appreciate your reading the documentation. On Fri, 16 Oct 2020, Wietse Venema wrote: Please correct the following misinformation: [...] This is is not a Postfix limitation, it is a Milter protocol limitation. Enough information is exchanged during option negotiation to fast-forward a milter which only rewrites recipients based on RCPT TO to EOB immediately, and pass those rewrites on to other chained milters. I wrote about this here at the time I implemented milters and you told me to go away. Most milter executor implementations behave this way so you have herd immunity, sure. This is not the only limitation with using milters with Postfix for this use case (which is the context). There is no mailing list for Trualias, although I'll answer emails within reason; however the proper thing to do would be to open an issue. Maybe some suggested language addressing the assocated issues (local_recipient_maps), you know, the specifics of the use case. Conversely http://www.postfix.org/LOCAL_RECIPIENT_README.html doesn't mention that it doesn't apply to milter recipient rewrites. Thanks again for reading the documentation... -- Fred Morris
Re: Trualias: tcp_virtual_server doesn't require patching local(8)
Please correct the following misinformation: Postfix has some issues with milters. For starters, although the milter protocol supports rejecting recipients during SMTP RCPT, it doesn't support rewriting them until EOB (end of message). This is is not a Postfix limitation, it is a Milter protocol limitation. Below are links to the official documentation which says that add_rcpt/del_rcpt/etc. may be called only from the EOM callback. https://web.archive.org/web/20100713211121/https://www.milter.org/developers/api/smfi_addrcpt https://web.archive.org/web/20100713212400/https://www.milter.org/developers/api/smfi_delrcpt There is enough wrong information, please do not add to it. Wietse Fred Morris: > Hello, > > I've implemented tcp_virtual_server.py which can be utilized with > virtual_alias_maps in main.cf, eliminating the need for patching > local(8) which is required with tcp_table_server.py/alias_maps. > > * No need to patch local(8) > * No need to specify virtual_alias_domains (mixes and matches local > addresses and aliases). > > The only difference I've noticed in the delivered mail is that the > Delivered-To: header no longer contains the alias; so as a consequence > any filtering during delivery will need to reference the X-Original-To: > header. > > TruAlias on GitHub: https://github.com/m3047/trualias > > Regards... > > -- > > Fred Morris > > Wietse
Re: possible bottlenecks
On 13 Oct 2020, at 22:47, Zsombor B wrote: > I know this is a complicated question but what/where do you see possible > bottlenecks in postfix? > Is it CPU? RAM? Disk IO? In theory? Sure, any of those could be a bottle neck. On actuality, the bottles necks are processing spam if you receive mail and not appearing to be a spammer. > I'm building an infra to send out ~3-5 million emails a day. If you pop onto the Internet all of a sudden sending 5 million emails a day you better be sure that your DKIM SPF DMARC and DNS are perfect and that your IP address has never been associated with a spammer. Because if there is one thing that will cripple your mail server it is having mail sit in queue because it's been throttled. The big email hosts do this a lot (especially Outlook.com and yahoo.com). And if you get on their (automated) bad side, you are well and thoroughly screwed. If you messages LOOK spammy enough that users will mark them as spam, then you will, again, be completely hosed whether the email is spam or not. Other than that, I think a raspberry pi 4 with a USB SSD might be able to mange 5 million emails a day. -- 'What is this thing, anyway?' said the Dean, inspecting the implement in his hands. 'It's called a shovel', said the Senior Wrangler. 'I've seen the gardeners use them. You stick the sharp end in the ground. Then it gets a bit technical.' --Reaper Man
Re: Mail server without MX record.
> Date: Friday, October 16, 2020 08:02:30 + > From: Jason Long >> On Friday, October 16, 2020, 01:13:45 AM GMT+3:30, Richard >> wrote: >> >> >>> Date: Thursday, October 15, 2020 18:57:29 + >>> From: Jason Long >>> >>> If the DNS administrator give me an A record then can I sending >>> and receiving emails from the Internet by the current >>> configuration? >> >> Assuming no MX, if an A-record is set up to point to a machine >> (properly configured, including with postfix or some other MTA) >> reachable on port 25 at the IPnumber, then it should be able to >> receive mail inbound. >> >> To be able to send mail directly to target mail servers you'll need >> to be able to connect outbound on port 25. To successfully deliver >> it, including to correspondents' inboxes, you'll need a matching >> Rdns record as well as the following: >> >> (this list is taken from an earlier message from Ahsan Khan >> responding to one of your questions): >> >> 1. SPF >> 2. DKIM records >> 3. DMARC records >> 4. IP Warmup >> 5. Check the scores at mail-tester.com. >> 6. Domain reputation >> >> There are a range of nitty things underlying all this which you >> will need to read up on so that you understand how mail, DNS, >> etc. work. >> >> You may be better off sending your mail outbound by way of a >> smarthost at your provider. > > Thank you. > Thus, in Postfix or Dovecot configuration file I can't change the > standard record? > Asked and already answered, multiple times, by various people. It's also not clear how that question follows on from the q/a that it is in reply to. To run a mail server successfully takes a base-level knowledge of the underlying protocols (and interoperability), not something gotten from scattershot questions. Try looking at some of the references previously mentioned.
Re: Mail server without MX record.
Dnia 16.10.2020 o godz. 08:02:30 Jason Long pisze: > Thank you. > Thus, in Postfix or Dovecot configuration file I can't change the standard > record? We already wrote you a few times, that DNS configuration (A/MX record) has NOTHING TO DO with Postfix or Dovecot configuration. NOTHING. These are COMPLETELY DIFFERENT SERVICES. Period. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Mail server without MX record.
On Fri, 16 Oct 2020, Jason Long wrote: Thank you. Thus, in Postfix or Dovecot configuration file I can't change the standard record? You a bot or something? I think GPT-3 can understand more than you appear to do. Good luck.
Re: Mail server without MX record.
Thank you. Thus, in Postfix or Dovecot configuration file I can't change the standard record? On Friday, October 16, 2020, 01:13:45 AM GMT+3:30, Richard wrote: > Date: Thursday, October 15, 2020 18:57:29 + > From: Jason Long > > If the DNS administrator give me an A record then can I sending and > receiving emails from the Internet by the current configuration? > Assuming no MX, if an A-record is set up to point to a machine (properly configured, including with postfix or some other MTA) reachable on port 25 at the IPnumber, then it should be able to receive mail inbound. To be able to send mail directly to target mail servers you'll need to be able to connect outbound on port 25. To successfully deliver it, including to correspondents' inboxes, you'll need a matching Rdns record as well as the following: (this list is taken from an earlier message from Ahsan Khan responding to one of your questions): 1. SPF 2. DKIM records 3. DMARC records 4. IP Warmup 5. Check the scores at mail-tester.com. 6. Domain reputation There are a range of nitty things underlying all this which you will need to read up on so that you understand how mail, DNS, etc. work. You may be better off sending your mail outbound by way of a smarthost at your provider.
