From: MacShane, Tracy (no email)
Date: Tue Oct 02 2007 - 21:03:40 EDT
> -----Original Message-----
> From:
> [mailto:] 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
mail
> > > queues 300,000 emails and a lot of these queues are bounces and
> > > 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
> faked.
You have to remember that most spammers are stupid. Simply by
implementing
reject_non_fqdn_hostname
reject_invalid_hostname
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)
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_non_fqdn_recipient
reject_unauth_pipelining,
reject_multi_recipient_bounce
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 is
> certianly one thing I will be looking at.
We have it implemented - we reject less than a dozen messages a day by
using it, though.
> 3. Forward/reverse resolution of the name/IP address of the
> 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).
See above, re (mostly) "stupid spammers".
>
> How else can I use Postfix to verify the sender address?
Whatever you do, don't implement sender verification. One of the smaller
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
connections.
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.
|
|
|