Loading ...
Sorry, an error occurred while loading the content.

RE: Programmatic access to the showq daemon/data

Expand Messages
  • MacShane, Tracy
    ... mail ... You have to remember that most spammers are stupid. Simply by implementing reject_non_fqdn_hostname reject_invalid_hostname
    Message 1 of 8 , Oct 2, 2007
    • 0 Attachment
      > -----Original Message-----
      > 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
      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.
    Your message has been successfully submitted and would be delivered to recipients shortly.