RE: Programmatic access to the showq daemon/data
> -----Original Message-----mail
> From: owner-postfix-users@...
> [mailto:owner-postfix-users@...] On Behalf Of Ward, Martin
> Sent: Tuesday, 2 October 2007 6:40 PM
> To: Postfix users
> Subject: RE: Programmatic access to the showq daemon/data
> > > I ask because I have a number of mail servers that regularly have
> > > queues 300,000 emails and a lot of these queues are bounces andYou have to remember that most spammers are stupid. Simply by
> > > double-bounces.
> > EEEEKS!
> > Don't accept mail for bogus senders, so that you don't have to send
> > bounces later!
> > Talk about fixing the wrong problem at the wrong end!
> Unfortunately I didn't design or implement this system and I
> have to work with what I have been given, a complete rewrite
> of the System is not going to happen! As for bogus senders,
> this is something that will be looked at but how can I verify them?
> 1. DNS check of the mail domain, but mail domains are easily
reject_non_fqdn_recipient (after permit_mynetworks, in our environment)
reject_unknown_recipient_domain (probably not needed since we
(obviously!) have reject_unauth_destination and good relay_recipient
maps, but what the hey)
in the smtpd restrictions and "strict_rfc821_envelopes = yes", we cut
the amount of spam traffic we processed by 40%. Having a
"check_client_access" map and blocking the top 20 networks that
generated traffic to us (according to Pflogsumm reports - the biggies
for us are comcast.net, tpnet.net, res.rr.com, verizon.net, etc) reduced
the traffic we processed by another 20%. Adding the MAPS RBL (now owned
by Trend Micro) means that we now only accept 20% of the traffic we did
before we migrated to Postfix. Only 15% of that 20% is tagged as
malware/spam by our content scanner.
> 2. SPF. Not implemented widely enough to be useful, but isWe have it implemented - we reject less than a dozen messages a day by
> certianly one thing I will be looking at.
using it, though.
> 3. Forward/reverse resolution of the name/IP address of theSee above, re (mostly) "stupid spammers".
> sending server is not a good test by any means given the
> number of hosts that will route emails for other domains
> (my company offers such a service).
>Whatever you do, don't implement sender verification. One of the smaller
> How else can I use Postfix to verify the sender address?
ISPs here in Australia implemented it, and promptly ended up on the MAPS
RBL (due to the fact their outbound connections doubled (or more)
overnight), so we were rejecting their mail. And we couldn't send *them*
mail, because naturally we were rejecting their verification
For another strategy, you might want to look into "greylisting" (tons of
docos on the web, including at Postfix.org). Most spammers seem not to
have gotten the hang of that one yet either.