Re: Unsolicited bounces

The Doctor wrote:
Tilman Schmidt <t.schmidt@xxxxxxxxxxxxxxxxxx> wrote:
The Doctor wrote:

How does one prevent unsolicited bounces as documented below?

The first, essential step is to reject non-existent recipient addresses
during the SMTP conversation (...). After that, it gets tricky.

Let us get into the tricky part.
I am keen on avoiding being blackholed by Spamcop.

SpamCop doesn't blackhole. SpamCop lists. It's the recipients who
do the blackholing based on that listing, against SpamCop's own
recommendation.

http://www.spamcop.net/fom-serve/cache/329.html#bounces

is what I am referring to.

Well, let's have a look at what they are asking people to do:

Configure your software to either reject messages during delivery or accept them permanently.

This is, of course, desirable, but impossible to achieve completely.
In practice, there are always cases where acceptance cannot be decided
definitively during the SMTP conversation, or where delivery fails
unexpectedly later. That's why bounces are part of the RFCs.
You can and should try to minimize them, but not entirely avoid them.

Do not let your software make choices about delivery after it has accepted a message.

This is a valid point. It means that any check of the message which
might result in it being rejected for policy reasons, such as:
- validity of recipient address
- sender and/or recipient blacklists
- virus scanning
- spam detection (if resulting in rejection, not just marking)
must be done in real time during the SMTP conversation. For Sendmail
this means using a milter. MIMEDefang works quite well for me.

But that isn't enough. Choices of your own software aren't the only
possible source for message rejection. One big source of bounces is
forwarding to other servers who might in turn reject the message.
Avoid that if you can. If you can't, take care at least to align
your rejection criteria with those of the servers you forward to.
This gets arbitrarily tough, of course, if those servers aren't
under your control, don't tell you their exact policies, and make
policy changes without notifying you.

Another major source of bounces, at least on my servers, are mailbox
quotas, because Sendmail is, to my best knowledge, unable to check
these during the SMTP conversation.

And then there are a flurry of rarer conditions causing bounces,
such as hardware or software failures, which you'll probably be
hard pressed to elliminate, so one hopes they won't happen too
often, and just puts up with the temporary SpamCop listings they
might cause.

If you must accept delivery before you know the status of a message,

That is not completely avoidable. Even minimizing it means some tough
limitations:
- no forwarding to external addresses (they might bounce)
- no quotas on mailboxes (they might become exceeded)
- no procmail (has the potential of bouncing messages too)
- no "pipe" aliases (dto.)

then file it internally - do not send, forward or bounce it outside your organization.

This is, of course, a direct contradiction to the accepted rule that
if a mail server accepts a message, it has to either deliver it or
return it to the sender.

In the end it's your call how far you want to go in violating accepted
standard practice in order to please SpamCop. For myself I have decided
that given this policy, SpamCop is not a valid basis for rejecting mail.
If mail is blocked because of a SpamCop listing then it's the server
using SpamCop who is at fault, not the server listed by SpamCop.
In fact, SpamCop themselves don't recommend using their list for
outright blocking, see:
http://www.spamcop.net/fom-serve/cache/297.html#whatisthescbl

HTH
Tilman

--
Tilman Schmidt t.schmidt@xxxxxxxxxxxxxxxxxx
Phoenix Software GmbH Tel. +49 228 97199 0
Adolf-Hombitzer-Str. 12 Fax +49 228 97199 99
53227 Bonn, Germany http://www.phoenixsoftware.de
.

Relevant Pages

  • Re: Spamcop flagged a number of users from MSN as spam ?
    ... >>Thanks a lot Rich. ... >>be have been identified as spam. ... I have personal experience with SPAMCOP listing ... > because spoofed email would NDR to one of their servers. ...
    (microsoft.public.exchange.admin)
  • Re: Spamcop flagged a number of users from MSN as spam ?
    ... I mean, given the number of MSN, I doubt the entire domain would ... >be have been identified as spam. ... I have personal experience with SPAMCOP listing ... because spoofed email would NDR to one of their servers. ...
    (microsoft.public.exchange.admin)
  • Re: Spamcop flagged a number of users from MSN as spam ?
    ... I have personal experience with SPAMCOP listing ... >>because spoofed email would NDR to one of their servers. ... You can't do effective spam filtering without ... But I suspect that's to deflect the ...
    (microsoft.public.exchange.admin)