On Thu, 12 May 2005, Peter J. Holzer wrote:

> The main problem with this solution is that many MTAs will retry only after
> the queue interval (typically several minutes to a few hours, but
> sometimes with an exponential backoff). If the list of recipients is
> large, it will take a long time to deliver the mail to all recipients (I
> have seen legitimate mails to 100+ recipients in our logs - assuming a
> queue interval of 30 minutes, that means more than two days until it has
> been delivered to the last recipient).

        So far in my testing, this is only the case with postfix. qmail,
Intermail, and sendmail split everything into separate queue entries, so
they are all separate connections in roughly the same time span. With
iPlanet, the MTA does a RSET between each retry, so it can still all be
dealt with by a single connection.

        I'm still waiting for a couple of EXCHANGE users for test
messages, and my Exim user may have a configuration problem - it's being
routed through the ISP's servers.

        Still missing: Courier. Others?

> A smarter approach (which I think I proposed on this list before) is to
> assume that for most messages with multiple recipients either all
> recipients want it or none. And for those messages which only some want,
> the decision will be the same for each recipient as for other messages
> with the same sender.

        My philosphy, at this point, is to err on the conservative side,
and allow everything through. This does mean some cleanup after-the-fact,
though.

        Though I like your suggested implementation, it wouldn't work in
my case, since legit mail has to get through, period. We can't have the
lone recipient who wants delivery to be overruled by the majority.

> At the time of the RCPT command you generally don't have enough
> information to decide whether you want to accept or reject.

        It depends on what you do, actually, but generally speaking, you
are correct. I don't do any DNSBL or other DNS or public DB stuff, and I
can typically reject 98% of spam connections without doing DATA (over 90%
of all connections here are spam), so I have very little to deal with
internally. Still, for my setup, it would be best to be able to deal with
one sender/receiver/message at a time.

Reply via email to