Re: Disabling user submission on port 25
On 26 Aug 2013, at 21:24 , John Allen wrote: > remove the permit_mynetworks from all the various smtpd__restrictions > stanzas of main.cf. Then modify the master.cf by adding > -o smtpd_client_restrictions=hash:Deny_Mynetworks_Access,. > to the smtp service, and add > -o smtpd_client_restrictions=permit_mynetworks,. > to the submission service. > > This should deny access to the smtp port (25) from the local networks while > allowing access to the submission port (587). That seem like a bit much. I allow the web-server (which hosts the webmail) in mynetworks, since users mailing from there are already authenticated. I can see there are situations where it would be a good idea. -- "If I were willing to change my morals for convenience or financial gain, we wouldn't be arguing, because I'd already *be* a Republican." -- Wil Shipley
Re: Disabling user submission on port 25
On 26 Aug 2013, at 19:00 , Noel Jones wrote: > # main.cf > smtpd_sasl_auth_enable = no Oh, right, of course. (I also needed to remove my fixed IP at home from my networks, which is why I was still able to send out via my machine). -- NOBODY LIKES SUNBURN SLAPPERS Bart chalkboard Ep. 7F23
Re: Disabling user submission on port 25
On 26/08/2013 9:00 PM, Noel Jones wrote: On 8/26/2013 7:49 PM, LuKreme wrote: OK, now that port 587 is working, I would like to disable user submission via port 25. Not right now, but in a bit once people have a chance to change their settings. What do I do to prevent users sending via port25? Super easy... # main.cf smtpd_sasl_auth_enable = no Your master.cf submission entry probably already includes -o smtpd_sasl_auth_enable=yes If not, go ahead and add it to submission now so things don't break unexpectedly later. This won't prevent users from sending local mail to port 25, but they won't be able to authenticate and won't be able to relay. This usually isn't considered a problem, and changing it often causes other issues. -- Noel Jones I based it something that Noel Jones wrote way back in 2008. Create a file of the networks you wish to deny access to eg. “Deny_Mynetworks_Access” the content of which will be the same networks as those found in the mynetworks parameter of the main.cf file for example: 192.168.0.0/16 REJECT local access not permitted n.n.n.n/28 REJECT local access not permitted [::::]/64 REJECT local access not permitted remove the permit_mynetworks from all the various smtpd__restrictions stanzas of main.cf. Then modify the master.cf by adding -o smtpd_client_restrictions=hash:Deny_Mynetworks_Access,. to the smtp service, and add -o smtpd_client_restrictions=permit_mynetworks,. to the submission service. This should deny access to the smtp port (25) from the local networks while allowing access to the submission port (587).
Re: Disabling user submission on port 25
On 8/26/2013 7:49 PM, LuKreme wrote: > OK, now that port 587 is working, I would like to disable user submission via > port 25. Not right now, but in a bit once people have a chance to change > their settings. > > What do I do to prevent users sending via port25? > Super easy... # main.cf smtpd_sasl_auth_enable = no Your master.cf submission entry probably already includes -o smtpd_sasl_auth_enable=yes If not, go ahead and add it to submission now so things don't break unexpectedly later. This won't prevent users from sending local mail to port 25, but they won't be able to authenticate and won't be able to relay. This usually isn't considered a problem, and changing it often causes other issues. -- Noel Jones
Disabling user submission on port 25
OK, now that port 587 is working, I would like to disable user submission via port 25. Not right now, but in a bit once people have a chance to change their settings. What do I do to prevent users sending via port25? -- >>Trying? >if you quote yoda, i swear upon everything holy that i will book a flight to >okinawa to kick your ass.
Re: MARC link on postfix.org/lists.html
On Mon, 2013-08-26 at 16:04:30 +0200, DTNX Postmaster wrote: > The MARC link on the mailing lists page no longer seems to work; > > http://www.postfix.org/lists.html > http://marc.theaimsgroup.com/?l=postfix-users > > As far as I can tell, the new link seems to be; > > http://marc.info/?l=postfix-users *nod* It seems the old link stopped working earlier this year; I remember seeing a mention of this on the SA issues tracker and just found it: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6898 -- Sahil Tandon
Re: Significantly different date observed in Received and Date fields
In article you write: >-=-=-=-=-=- > >It's possible to modify the Date field on MUA side, if one were so >inclined, right? > >If so, how would that be accomplished? The easiest way is to change the clock in your computer, then send the message, then change it back.
Re: Relay access denied on submission?
On 26 Aug 2013, at 16:47 , LuKreme wrote: > postfix/smtpd[4289]: Anonymous TLS connection established from > mobile-166-147-083-103.mycingular.net[166.147.83.103]: TLSv1 with cipher > ECDHE-RSA-AES256-SHA (256/256 bits) > > mail postfix/smtpd[4289]: NOQUEUE: reject: RCPT from > mobile-166-147-083-103.mycingular.net[166.147.83.103]: 454 4.7.1 > <*munged*@mac.com>: Relay access denied; from= > to=<*munged*@mac.com> proto=ESMTP helo=<[10.33.25.94]> > > postfix/smtpd[4289]: disconnect from > mobile-166-147-083-103.mycingular.net[166.147.83.103] Doh. Never mind. I was not connecting to the submission port. 'sall working properly if I connect to the right port. -- This was music that had not only escaped but had robbed a bank on the way out. It was music with its sleeves rolled up and its top button undone, raising its hat and grinning and stealing the silver. It was music that went down to the feet by way of the pelvis without paying a call on Mr. Brain. --Soul Music
Relay access denied on submission?
postfix/smtpd[4289]: Anonymous TLS connection established from mobile-166-147-083-103.mycingular.net[166.147.83.103]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) mail postfix/smtpd[4289]: NOQUEUE: reject: RCPT from mobile-166-147-083-103.mycingular.net[166.147.83.103]: 454 4.7.1 <*munged*@mac.com>: Relay access denied; from= to=<*munged*@mac.com> proto=ESMTP helo=<[10.33.25.94]> postfix/smtpd[4289]: disconnect from mobile-166-147-083-103.mycingular.net[166.147.83.103] $ postconf -M | grep submission submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/auth -o smtpd_sasl_security_options=noanonymous -o smtpd_sasl_local_domain=$myhostname -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o syslog_name=submit-tls $ postconf -n alias_database = hash:$config_directory/aliases alias_maps = hash:$config_directory/aliases, hash:/usr/local/mailman/data/aliases allow_percent_hack = no body_checks = pcre:$config_directory/body_checks.pcre bounce_size_limit = 10240 broken_sasl_auth_clients = yes command_directory = /usr/local/sbin config_directory = /etc/postfix daemon_directory = /usr/local/libexec/postfix data_directory = /var/db/postfix debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 disable_vrfy_command = yes header_checks = pcre:$config_directory/header_checks.pcre header_size_limit = 10240 home_mailbox = Maildir/ html_directory = /usr/local/share/doc/postfix inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailbox_command = /usr/local/bin/procmail -t -a $EXTENSION mailbox_size_limit = 52428800 mailq_path = /usr/local/bin/mailq manpage_directory = /usr/local/man maps_rbl_reject_code = 521 message_size_limit = 26214400 mime_header_checks = pcre:$config_directory/mime_headers.pcre mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost, ns1.$mydomain, ns2.$mydomain, mail.$mydomain, www.$mydomain, webmail.$mydomain mydomain = covisp.net myhostname = mail.covisp.net mynetworks = 75.148.117.88/29, 127.0.0.0/8, 23.24.150.141 myorigin = $mydomain newaliases_path = /usr/local/bin/newaliases postscreen_access_list = permit_mynetworks, cidr:$config_directory/postscreen_access.cidr postscreen_dnsbl_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..9]*3 list.dnswl.org=127.0.0.1*-1 list.dnswl.org=127.0.0.2*-3 list.dnswl.org=127.0.0.3*-9 dwl.spamhaus.org=127.0.2.[2;3]*-4 swl.spamhaus.org=127.0.2.[12;13]*-4 postscreen_dnsbl_ttl = 1d postscreen_greet_action = enforce postscreen_greet_banner = mail.covisp.net ESTMP -- Please wait postscreen_greet_ttl = 1d postscreen_greet_wait = 4s queue_directory = /var/spool/postfix readme_directory = /usr/local/share/doc/postfix recipient_delimiter = + sample_directory = /usr/local/etc/postfix sendmail_path = /usr/local/sbin/sendmail setgid_group = maildrop show_user_unknown_table_name = no smtp_tls_security_level = may smtpd_banner = $myhostname ESMTP $mail_name $mail_version smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce, permit smtpd_error_sleep_time = 28 smtpd_hard_error_limit = 8 smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit smtpd_recipient_limit = 100 smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_recipient, reject_unlisted_sender, reject_unknown_reverse_client_hostname, warn_if_reject reject_unknown_client_hostname, check_sender_access pcre:$config_directory/sender_access.pcre, check_client_access pcre:$config_directory/check_client_fqdn.pcre, check_recipient_access pcre:$config_directory/recipient_checks.pcre, check_client_access hash:$config_directory/access, permit smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 4 smtpd_starttls_timeout = 40s smtpd_tls_cert_file = /etc/ssl/certs/postfix.pem smtpd_tls_key_file = /etc/ssl/private/postfix.pem smtpd_tls_loglevel = 2 smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:$data_directory/smtpd_sessions smtpd_tls_session_cache_timeout = 1800s soft_bounce = no swap_bangpath = no transport_maps = hash:/etc/postfix/transport undisclosed_recipients_header = To: List of Bcc addresses:; unknown_local_recipient_reject_code = 550 virtual_alias_domains = kreme.com virtual_alias_maps = hash:$config_directory/virtual pcre:$config_directory/virtual.pcre, pcre:$config_directory/virtual_sql.pcre, proxy:mysql:$config_directory/mysql_virtual_al
Re: Significantly different date observed in Received and Date fields
On 25 Aug 2013, at 22:41 , Mike Seda wrote: > It's possible to modify the Date field on MUA side, if one were so inclined, > right? Yes, but I am having trouble thinking of a case where it is really actually truly a good idea. > If so, how would that be accomplished? I'd use procmail and formail? You could add a header X-Date-Received or simply overwrite the header, or even do something like put the contents of Date: into X-Old-Date and write the current date into a new Date: It's not as trivial as you might think to do it right. For example, you would need to account for pesky things like time zones. Also, if you use Maildir, the 'header' date is not really that important; it is the date stamp when the file was written that determines sorting, for example. I did this long ago in procmail to 'repair' some mbox files (so it rewrote the FROM_ header), but when I had to reprocess a bunch of mail that was munged, I had to grab the date out of the received header for my server and parse it to reformat it for the FROM_ header. The idea should be basically the same for rewriting the Date header, but is probably easier as I think, generally, Received dates and Date: headers are the same format? Received: Sun, 25 Aug 2013 22:42:02 -0600 (MDT) Date: Mon, 26 Aug 2013 00:41:35 -0400 Almost the same. Almost. If I were doing it now I would probably do something like feed the Received date into gnu date with a timezone change, and use the output to set the new header; that should work pretty easily. $ gdate --date='TZ="-0600" Mon, 26 Aug 2013 00:41:35 -0400' Sun Aug 25 22:41:35 MDT 2013 Put in a comma and the timezone offset -0600 and Robert is your mother's brother. I may write something to rename the Maildir files (which use an epoch timestamp) to the correct epoch time for their Date: headers. I have a few thousand messages from 2009 that sort incorrectly because their names are wrong in the maildir. -- Nihil est--in vita priore ego imperator Romanus fui.
Re: SMTP server error: 4.7.1 Error: too much mail from xx.xx.xx.xx
Wietse: > Look for these settings: > > $ postconf -n | grep smtpd_client > > Someone put these settings into your main.cf. Frank Barcenas: > Awesome! Thank you. Can't wait to see if it happens again this month. Note the default smtpd_client_message_rate_limit is zero, i.e. no limit. If you need finer control, for example, by sender address, you would need to use a policy server (postfwd, for example). Wietse
Re: email from comcast.net is bouncing
Grant: > >> >> SUBJECT: Delivery status notification > >> >> This is an automatically generated Delivery Status Notification. > >> >> Delivery to the following recipients was aborted after 7 second(s): > >> >> mas...@masked.com > >> > > >> > If you want that mail, whitelist them, > >> > >> They should already be whitelisted through my use of list.dnswl.org. > > > > Your SMTP server replied with 450. Either your configuration is > > wrong, or some DNS lookups time out. Note the above text says: > > > > Delivery to the following recipients was aborted after 7 second(s) > > > > This could be a symptom of DNS lookup timeout. > > Something must be wrong with my config. In my log I can see that > postfix is returning 450 to many more comcast.net messages than it's Please show "postconf -n" command output (not cut-and-paste from main.cf). Please show one complete logfile record from "connect from" until "reject" that demonstrates the problem (you may anonymize the email address). > >> I also have several of these: > >> > >> lost connection with mx1.comcast.net[68.87.26.147] while receiving the > >> initial server greeting > >> conversation with mx1.comcast.net[68.87.26.147] timed out while > >> receiving the initial server greeting > > > > Your SMTP *client* also has problems. Consider monitoring your > > packet loss rate. I run "mtr" from a cron job. > > Is it the sender's SMTP client that has problems? Please show one complete logfile record (you may anonymize the email address). Wietse
Re: email from comcast.net is bouncing
>> >> SUBJECT: Delivery status notification >> >> This is an automatically generated Delivery Status Notification. >> >> Delivery to the following recipients was aborted after 7 second(s): >> >> mas...@masked.com >> > >> > If you want that mail, whitelist them, >> >> They should already be whitelisted through my use of list.dnswl.org. > > Your SMTP server replied with 450. Either your configuration is > wrong, or some DNS lookups time out. Note the above text says: > > Delivery to the following recipients was aborted after 7 second(s) > > This could be a symptom of DNS lookup timeout. Something must be wrong with my config. In my log I can see that postfix is returning 450 to many more comcast.net messages than it's delivering. It doesn't make sense for DNS to be timing out the vast majority of the time. I use a reputable DNS provider. Should the whitelist be indicated anywhere in the log? I'm on postfix-2.11_pre20130818. Here's my config: main.cf: smtpd_recipient_restrictions = reject_unauth_destination, permit postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1 postscreen_dnsbl_whitelist_threshold = -1 smtpd_tls_security_level = may smtpd_tls_auth_only = yes master.cf: smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd tlsproxy unix - - n - 0 tlsproxy submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject >> I also have several of these: >> >> lost connection with mx1.comcast.net[68.87.26.147] while receiving the >> initial server greeting >> conversation with mx1.comcast.net[68.87.26.147] timed out while >> receiving the initial server greeting > > Your SMTP *client* also has problems. Consider monitoring your > packet loss rate. I run "mtr" from a cron job. Is it the sender's SMTP client that has problems? - Grant
Re: email from comcast.net is bouncing
>> >> SUBJECT: Delivery status notification >> >> This is an automatically generated Delivery Status Notification. >> >> Delivery to the following recipients was aborted after 7 second(s): >> >> mas...@masked.com >> > >> > If you want that mail, whitelist them, >> >> They should already be whitelisted through my use of list.dnswl.org. > > Your SMTP server replied with 450. Either your configuration is > wrong, or some DNS lookups time out. Note the above text says: > > Delivery to the following recipients was aborted after 7 second(s) > > This could be a symptom of DNS lookup timeout. Something must be wrong with my config. In my log I can see that postfix is returning 450 to many more comcast.net messages than it's delivering. It doesn't make sense for DNS to be timing out the vast majority of the time. I use a reputable DNS provider. Should the whitelist be indicated anywhere in the log? I'm on postfix-2.11_pre20130818. Here's my config: main.cf: smtpd_recipient_restrictions = reject_unauth_destination, permit postscreen_greet_action = enforce postscreen_pipelining_enable = yes postscreen_pipelining_action = enforce postscreen_non_smtp_command_enable = yes postscreen_non_smtp_command_action = enforce postscreen_bare_newline_enable = yes postscreen_bare_newline_action = enforce postscreen_dnsbl_sites = zen.spamhaus.org list.dnswl.org*-1 postscreen_dnsbl_whitelist_threshold = -1 smtpd_tls_security_level = may smtpd_tls_auth_only = yes master.cf: smtp inet n - n - 1 postscreen smtpd pass - - n - - smtpd tlsproxy unix - - n - 0 tlsproxy submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject >> I also have several of these: >> >> lost connection with mx1.comcast.net[68.87.26.147] while receiving the >> initial server greeting >> conversation with mx1.comcast.net[68.87.26.147] timed out while >> receiving the initial server greeting > > Your SMTP *client* also has problems. Consider monitoring your > packet loss rate. I run "mtr" from a cron job. Is it the sender's SMTP client that has problems? - Grant
Re: SMTP server error: 4.7.1 Error: too much mail from xx.xx.xx.xx
Awesome! Thank you. Can't wait to see if it happens again this month. > Look for these settings: > > $ postconf -n | grep smtpd_client > > Someone put these settings into your main.cf. > Wietse > Frank zello: barcef whatsapp: +5213331849895 "We hang petty thieves and appoint the great ones to public office. ~Aesop, Greek slave & fable author "
Re: SMTP server error: 4.7.1 Error: too much mail from xx.xx.xx.xx
Frank Barcenas: > I have moodle installed on my webserver. At peak times during the month, I > begin to see this error: SMTP server error: 4.7.1 Error: too much mail from > xx.xx.xx.xx in the logs. What value do I need to increase in my main.cf? Or > is there some sortof whitelist that I can use so that it won't limit my > webserver, even though they are one in the same. Look for these settings: $ postconf -n | grep smtpd_client Someone put these settings into your main.cf. Wietse
MARC link on postfix.org/lists.html
The MARC link on the mailing lists page no longer seems to work; http://www.postfix.org/lists.html http://marc.theaimsgroup.com/?l=postfix-users As far as I can tell, the new link seems to be; http://marc.info/?l=postfix-users Mvg, Joni
SMTP server error: 4.7.1 Error: too much mail from xx.xx.xx.xx
I have moodle installed on my webserver. At peak times during the month, I begin to see this error: SMTP server error: 4.7.1 Error: too much mail from xx.xx.xx.xx in the logs. What value do I need to increase in my main.cf? Or is there some sortof whitelist that I can use so that it won't limit my webserver, even though they are one in the same. Frank zello: barcef whatsapp: +5213331849895 "We hang petty thieves and appoint the great ones to public office. ~Aesop, Greek slave & fable author "
Re: TLS errors with GMX/web.de
On Mon, Aug 26, 2013 at 12:04:28PM +0200, Sebastian Wiesinger wrote: > > It may be overkill, but it should work. I am afraid the best path > > forward is for GMX to debug this with their client software. > > Yeah I'm not holding my breath for that. Send them (postmaster@) a pointer to this thread, over time they'll have similar problems with more sites. > Is there a way to exclude the > web.de/GMX mailservers from the EC certificate? Let postfix always > use the other certificate for them? Only by redirecting their connections to a different port via NAT. The Postfix SMTP server has very minimal client-specific TLS policy: - You can disable STARTTLS support for a set of clients. smtpd_discard_ehlo_keyword_address_maps - You can do access control based on client certificates smtpd_tls_ask_ccert permit_tls_clientcerts check_ccert_access One of the main problems is that while the client knows who the server is (it chose to connect there), the server has little idea who the client is (IP address ranges change over time). Policies intended to improve interoperability with legitimate clients (that don't lie about their identity) could in principle do lookups based on the client EHLO name. Postfix does not yet have such features. -- Viktor.
Re: email from comcast.net is bouncing
Grant: > >> SUBJECT: Delivery status notification > >> This is an automatically generated Delivery Status Notification. > >> Delivery to the following recipients was aborted after 7 second(s): > >> mas...@masked.com > > > > If you want that mail, whitelist them, > > They should already be whitelisted through my use of list.dnswl.org. Your SMTP server replied with 450. Either your configuration is wrong, or some DNS lookups time out. Note the above text says: Delivery to the following recipients was aborted after 7 second(s) This could be a symptom of DNS lookup timeout. > I also have several of these: > > lost connection with mx1.comcast.net[68.87.26.147] while receiving the > initial server greeting > conversation with mx1.comcast.net[68.87.26.147] timed out while > receiving the initial server greeting Your SMTP *client* also has problems. Consider monitoring your packet loss rate. I run "mtr" from a cron job. Wietse
Re: TLS errors with GMX/web.de
* Viktor Dukhovni [2013-08-24 05:27]: > > > I just did, here is the PCAP: > > > > http://www.karotte.org/smtp-gmx.pcap > > The client sends an "internal error" alert. It is not clear what > problem it is encountering. The server elects: > > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) > > and the client purports to support the curve in the server certificate. > I don't have the expertise to try to debug the server's key exchange > message, but it it is typically secp256r1 aka prime256v1, which the > client purports to support. > > It may be overkill, but it should work. I am afraid the best path > forward is for GMX to debug this with their client software. Yeah I'm not holding my breath for that. Is there a way to exclude the web.de/GMX mailservers from the EC certificate? Let postfix always use the other certificate for them? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
Re: iptables based spam prevention
On Aug 26, 2013, at 06:20, pe...@ixp.jp wrote: > On Aug/25.20:11:49, Niclas Arndt wrote: >> Here are my questions: Is the iptables approach at all viable in the long >> run? Is there any non-commercial way to upload a text file containing >> spamming IP addresses and have it verified for correctness? > > Your IP tables will get scary quite rapidly, possibly without bounds. > More so if you do not expire old records. > > The XBL component alone should make IP tables faint. > > DNS is almost certainly a saner way. In your case, shove your records in > your own local DNS server and make a private block list. If you have a > fit > of insanity, allow other people to query it too... Set up your own private rbldnsd; forward requests to it via your local caching resolver. It scales easily to millions of entries, it does not require a reload of Postfix for updates, the file format is very simple and therefore easy to build automatically, and so on. Also, you get the benefit of the RBL features of Postfix. You can have different replies for different types of IP addresses; have one type be rejected directly by postscreen and another type by your recipient restrictions, for example. Once you have it running it is trivial to add domain based rejections as well, and reject HELO hostnames, reverse DNS results, sender domains and such. HTH, Joni
