Re: Intelligently processing deferred mail

Kees Theunissen wrote:
Phil wrote:
On Mar 31, 4:07 pm, Phil <phillip.corch...@xxxxxxxxx> wrote:
Question - how to go about intelligently processing deferred mail?

Currently I have Timeout.queuereturn=30h. In a typical 24hr processing
period, I have 4,000-7,000 deferred emails, but these generate nearly
1million delivery attempts. (by comparison I'm delivering about
400,000 successful emails daily).

The deferred generally fall into these categories
1 incorrect domain (majority)

Solution: don't mail to incorrect domains.

2 user unknown at destination, or user mbox full at destination

Solution: don't mail to non existing users

3 remote MTA temp down for some legit reason, should wait for it to
come up

A remote system being down is out of your control. The only thing you
can do is wait and retry. This shouldn't be a big issue with normal mail
traffic.

4 greylisted

Just retry after some time.


In particular, I would like to be able to just dump (and log) all of
the #1 items.

You should not have the #1 (and #2) items in the first place.
Why do you want to try sending mail in hughe amounts to "incorrect
domains" and dump those message if that fails?

Do mail software other than sendmail (like postfix, etc that I have no
experience with) have ways to handle this more intelligently? Is this
a us for Milter?

Ideas, suggestions?

See above.

It seems to me that you accept messages that you can't (unknown user) or
don't want (spam) to deliver to your users and that you're sending
bounce messages in those cases. As virtually all spam has an invalid or
a spoofed sender address this is the wrong thing to do; you're just
annoying innocent people (the spoofed 'senders') and stressing your own
server with undeliverable messages.

The proper solution would be to check what you can and want to deliver
before you accept the responsibility for a message and just reject
anything you don't want during the smtp phase.

Sorry, I should have taken a better look at your figures before
replying. 4,000-7,000 deferred messages on a total of 400,000 delivered
messages is not an indication that you're bouncing/backscattering
big parts of your spam.
But still #1 and #2 look like backscatter.

Do you have any indication of the nature/origin of those messages?
I'm thinking about things as:
-- mail that you relay to back-end systems or customers and that is
rejected by the downstream server,
-- Out of office replies triggered by a spam message,
-- Possibly spam, forwarded by some of your users to an external
address and rejected by the external servers.
Knowing the source of these messages might help preventing them.

Furthermore you cold move messages that stay in your queue for
too long to an other -less frequently processed- queue.

Regards,

Kees.

--
Kees Theunissen.
.

Relevant Pages

  • Re: Random Email Bounces
    ... of my own registered domains that's currently blissfully free of spam - - ... my own wee server here is pretty busy as is :-) ... mailers used by spammers retry failed delivery attempts. ...
    (microsoft.public.exchange.admin)
  • Strange email deliveries
    ... Recently we have been getting a lot of spam past the Trend Micro Spam ... Small Business Server has removed potentially unsafe e-mail attachment ... The subject is Delivery reports about your e-mail ... The attachments are all the same though. ...
    (microsoft.public.windows.server.sbs)
  • Re: Intelligently processing deferred mail
    ... period, I have 4,000-7,000 deferred emails, but these generate nearly ... 1million delivery attempts. ... don't want (spam) to deliver to your users and that you're sending ... a spoofed sender address this is the wrong thing to do; ...
    (comp.mail.sendmail)
  • Re: Random Email Bounces
    ... your normal spam filters. ... My two inflow servers are separated by the Atlantic ocean. ... sending servers should retry delivery for several days, ...
    (microsoft.public.exchange.admin)
  • Re: Random Email Bounces
    ... If spam is delivered there you won't be subjecting it to anything ... you don't use any DNS RBLs? ... ORF, ... the "On Delivery" RBL check if the IP address is in that "Intermediate ...
    (microsoft.public.exchange.admin)