Re: mail aliases spam
Ronald F. Guilmette wrote: cake and eat it to. My belief is that by employing the marvelous flexibility of Postfix there must be a way to _both_ accept all incoming messages bound for valid local recipient addresses _and_ also reject some subset of those messages just after the end of the DATA phase of the associated SMTP transaction. Right. You can do this pretty easily right now by running amavisd-new as a smtpd_proxy_filter and setting it to reject quarantine spam. The benefits of doing this are certainly debatable... but let's not. -- Noel Jones
Re: mail aliases spam
- Original Message - From: Noel Jones [EMAIL PROTECTED] To: Ronald F. Guilmette [EMAIL PROTECTED] Cc: postfix users list postfix-users@postfix.org Sent: Friday, August 15, 2008 3:46 PM Subject: Re: mail aliases spam Ronald F. Guilmette wrote: cake and eat it to. My belief is that by employing the marvelous flexibility of Postfix there must be a way to _both_ accept all incoming messages bound for valid local recipient addresses _and_ also reject some subset of those messages just after the end of the DATA phase of the associated SMTP transaction. Right. You can do this pretty easily right now by running amavisd-new as a smtpd_proxy_filter and setting it to reject quarantine spam. Proxy filter == before-queue filter?
Re: mail aliases spam
John Heim wrote: - Original Message - From: Noel Jones [EMAIL PROTECTED] To: Ronald F. Guilmette [EMAIL PROTECTED] Cc: postfix users list postfix-users@postfix.org Sent: Friday, August 15, 2008 3:46 PM Subject: Re: mail aliases spam Ronald F. Guilmette wrote: cake and eat it to. My belief is that by employing the marvelous flexibility of Postfix there must be a way to _both_ accept all incoming messages bound for valid local recipient addresses _and_ also reject some subset of those messages just after the end of the DATA phase of the associated SMTP transaction. Right. You can do this pretty easily right now by running amavisd-new as a smtpd_proxy_filter and setting it to reject quarantine spam. Proxy filter == before-queue filter? Yes. http://www.postfix.org/SMTPD_PROXY_README.html -- Noel Jones
Re: mail aliases spam
On 8/14/2008 11:54 AM, John Heim wrote: Get it? Somebody tries to spam [EMAIL PROTECTED] and user12 has his mail forwarded to his gmail account. Gmail detects the spam, rejects the message and my mta then generates a bounce back to the original forged from address. I don't see anything in the backscatter howto about this. I believe my machine is properly configured to not generate normal (for lack of a better term) backscatter. I mean, it doesn't bounce incoming spam. But this is almost like spam coming from inside my own system. This is one of the problems with auto-forwarders and auto-responders. It looks to me like the main problem is why so much actual spam is getting through to your users - what anti-spam measures do you take? -- Best regards, Charles
Re: mail aliases spam
- Original Message - From: Charles Marcus [EMAIL PROTECTED] To: John Heim [EMAIL PROTECTED] Cc: postfix-users@postfix.org Sent: Thursday, August 14, 2008 12:17 PM Subject: Re: mail aliases spam On 8/14/2008, John Heim ([EMAIL PROTECTED]) wrote: Exactly! Except that the reason our anti-spam measures are ineffective is that the addresses are aliased. ?? What difference does an alias make? Either a recipient is valid or not... We filter spam bvia a procmail rule that runs it through spamc. With a mail alias, procmail is never run. It appears that if the user creates a .forward file, it has the same effect. We have 2 MTAs running postfix with pre-queue spam filters and then a delivery machine running postfix, spamassassin, dovecot. The pre-queue spam filter gets about 50% of incoming spam. Of course, that means that about 50% gets through. Thats ridiculous... ;) A properly configured postfix ALL BY ITSELF should stop 90+% with virtually ZERO false positives... Keep in mind that that's just the pre-queue filter on the mta. I'm basing my estimate on the output from pflogsumm: Postfix log summaries for Aug 13 Grand Totals messages 91708 received 42450 delivered 0 forwarded 233 deferred (2390 deferrals) 439 bounced 26497 rejected (38%) 0 reject warnings I didn't actually configure postfix on any of these machines. My predecessor did. He's really good but it's possible he made a mistake. Plus, I've tweaked the config considerably since he left. I added the pre-queue spam filtering. Still there's a lot I haven't delved into and don't entirely understand. postconf on the mta: alias_database = alias_maps = append_dot_mydomain = yes biff = no body_checks = regexp:/etc/postfix/body_checks canonical_classes = envelope_recipient canonical_maps = ldap:/etc/postfix/canonical_ldap config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 header_checks = pcre:/etc/postfix/header_checks inet_interfaces = all local_header_rewrite_clients = permit_mynetworks local_recipient_maps = local_transport = error:local mail delivery is disabled message_size_limit = 50485760 mydestination = myhostname = mta2.math.wisc.edu mynetworks = 127.0.0.0/8 144.92.166.0/24 144.92.149.128/25 myorigin = math.wisc.edu relay_domains = math.wisc.edu, .math.wisc.edu relay_recipient_maps = hash:/etc/postfix/relay_recipients, hash:/etc/postfix/rel ay_aliases, hash:/etc/postfix/relay_aliases_mailman, ldap:/etc/postfix/relay_rec ipients.ldap.cf relocated_maps = hash:/etc/postfix/relocated smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_helo_required = yes smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_unknown_sender_dom ain, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc /postfix/access, permit transport_maps = hash:/etc/postfix/transport virtual_alias_maps = hash:/etc/postfix/virtual postconf on the destination server: alias_database = hash:/etc/postfix/maps/aliases alias_maps = hash:/etc/postfix/maps/aliases, hash:/usr/local/mailman/data/aliases allow_mail_to_commands = alias, forward allow_mail_to_files = alias, forward append_dot_mydomain = yes biff = no broken_sasl_auth_clients = yes config_directory = /etc/postfix mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail mailbox_delivery_lock = fcntl mailbox_size_limit = 10 masquerade_domains = math.wisc.edu masquerade_exceptions = root message_size_limit = 50485760 mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, .math.wisc.e du mydomain = math.wisc.edu myhostname = ulam.math.wisc.edu mynetworks = 144.92.166.0/24, 144.92.149.128/25, 127.0.0.0/8 myorigin = $mydomain qmgr_message_active_limit = 5000 queue_directory = /var/spool/postfix relay_domains = $mydestination relayhost = math.wisc.edu relocated_maps = hash:/etc/postfix/maps/relocated setgid_group = postdrop smtp_tls_note_starttls_offer = yes smtp_use_tls = yes smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject smtpd_data_restrictions = reject_unauth_pipelining, permit smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_un auth_destination smtpd_sasl_application_name = smtpd smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/ssl/mailhost.crt smtpd_tls_key_file = /etc/postfix/ssl/mailhost.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_use_tls = yes tls_random_source = dev:/dev/urandom virtual_mailbox_lock = fcntl
Re: mail aliases spam
John Heim wrote, at 08/14/2008 02:09 PM: postconf on the mta: smtpd_recipient_restrictions = reject_non_fqdn_sender, reject_unknown_sender_dom ain, permit_mynetworks, reject_unauth_destination, check_sender_access hash:/etc /postfix/access, permit Try this: smtpd_recipient_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain permit_mynetworks reject_unauth_destination check_sender_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname warn_if_reject reject_unknown_reverse_client_hostname warn_if_reject reject_unknown_client_hostname check_helo_access pcre:/etc/postfix/helo reject_rbl_client zen.spamhaus.org reject_rbl_client insert favorite RBL here In my experience, reject_unknown_reverse_client_hostname and reject_unknown_client_hostname produce false positives. However, the numbers have gone down, and several members of this list have reported the risk to be acceptable, so I am rejecting them with pretty good results. I am reporting misconfigurations to the legitimate sites and crossing my fingers. I've prepended warn_if_reject to these lines, so you can evaluate them before committing. I do *not* recommend changing unknown_client_reject_code from its default of 450. While it may result in more log lines from retries, I can testify from experience that DNS errors do happen and you don't want to permanently reject mail due to a transient DNS failure. Use the check_helo_access map to effectively catch some popular obvious spam. In /etc/postfix/helo, I have (among others): # Block illegal unbracketed IP addresses and bare numbers (including negatives) # Examples: 192.168.1.34, 12345678, -12345678 /^[\d\.-]*$/ REJECT Unacceptable hostname in helo # Block legal IPv4 address literals (bracketed IP addresses) due to surge in spam # NOTE: Make sure your site does not need to support address literals in HELO # Example: [192.168.1.34] /^\[[\d\.]*\]$/ REJECT Policy prohibits address literals in helo # Block localhost (unusual in HELO) /^localhost(\.localdomain)?$/ REJECT Unacceptable hostname in helo In addition, my first line of defense is Nolisting, which still works effectively against certain zombies and helps to reduce load upfront, using any packet filter: http://nolisting.org/ I supplement this with Selective Unlisting (which relies on iptables at the moment): http://unlisting.org/selective.html With all of these in place, you are in a good position to add some RBLs without overloading them. At the very least, consider zen.spamhaus.org, which to date has been safe enough to use for outright rejection (others you may want to continue to score in SA).
Re: mail aliases spam
John Heim wrote: - Original Message - From: Jorey Bump [EMAIL PROTECTED] Don't rely solely on SpamAssassin. There are other techniques that are less expensive and can eliminate obvious spam with virtually no false positives (and others that may have an acceptable level of false positives, though YMMV). Note, however, that there may be equivalents available in SpamAssassin, where you can tweak the scores to a degree you find acceptable. If you already have the hardware to run SA in a before-queue filter, this may be worth investigating. On the other hand, if you're under heavy load, the other techniques can help reduce SA's overhead. In setting up the pre-queue spam filter, I followed the instructions here: http://www.postfix.org/SMTPD_PROXY_README.html What are you using as your smtpd_proxy_filter? Seems it could do better... ISTM that reject_rbl_client zen.spamhaus.org will reject about 50% of spam all by itself with very low probability of false positives. Spamhaus is not free for everyone, check their usage policy: http://www.spamhaus.org/organization/dnsblusage.html This list is good enough that I would recommend buying their service if you don't qualify for the free deal. Some free access RBLs to consider are cbl.abuseat.org (excellent; included in zen.spamhaus.org so don't bother using them both), bl.spamcop.net (used to have too many false positives, but seems better now), and dul.dnsbl.sorbs.net (possibly some real MTAs running on dynamic IPs listed). Check their web sites for listing policy. reject_unknown_reverse_client_hostname may be safe for you to use. Use it with warn_if_reject for a while to see what would be rejected by this rule. Also safe is a check_helo_access map that rejects your own domain or a bare IP address. Make sure to put this somewhere after permit_mynetworks, permit_sasl_authenticated. -- Noel Jones
Re: mail aliases spam
John Heim wrote: - Original Message - From: Noel Jones [EMAIL PROTECTED] In setting up the pre-queue spam filter, I followed the instructions here: http://www.postfix.org/SMTPD_PROXY_README.html What are you using as your smtpd_proxy_filter? Seems it could do better... Spampd and spamassassin. I have spent a lot of time tweaking the spamassassin settings but I'm afraid of false positives and of increasing the load on my mta too much. I didn't really intend to ask spamassassin questions here. When I asked my original question, I thought we were doing pretty well wrt catching spam before it even entered the system. I thought there was something else misconfigured in my postfix config. I agree that false positives are bad... but hopefully you're rejecting mail and not discarding it. When (legit) mail is rejected, the sender is notified and you'll hear about it... Note that if you use some of the suggested RBLs and other postfix restrictions, load on your server will go way down compared to running spamassassin on everything. I also strongly suggest clamav if you're not using it. And I also strongly recommend the Sanesecurity add-on signatures for clamav; they catch lots of phish and scam mail that spamassassin seems to have trouble with. The clamav-milter (part of clamav) works well with postfix, or there is a plug-in for SpamAssassin if you don't want to set it up separately. What? There's no DO_NOT_FORWARD_SPAM flag I can set to 'yes'? Bummer. I'm waiting on the NO_SPAM_HERE flag. -- Noel Jones
