On 12/08/2010 15:32, John R Levine wrote:
>
>> True statement, but that means the senders of the other 5% are now left
>> in the dark as to what happened to their mail.
>> Is there a proposed solution to that?
>
> Talking out of my hat here, it is my impression that spam is much more
> likely to be sent to bogus addresses than legit mail is, so however
> the spam fraction of your mailstream, the spam fraction of your
> bounces is likely to be even higher.
>
> On my tiny mail system, most but not quite all of the bounces can be
> handled as rejections at SMTP time. The ones I can't are generally
> deliveries to scripts where the script decides whether it can accept
> the mail. When those say nope, can't deliver that, when is it worth
> generating a bounce?
We have had several cases where our customers have been blacklisted by
their ISP for sending 'spam', when, in fact, they have just been sending
NDNs to all the spam they receive.
Operationally speaking, once you've accepted responsibility for a message, you
lose a lot of handling options, one of them being to blindly send NDNs for
stuff like invalid recipients without first checking to see if the message is
spam.
This is why it's important to validate recipient addresses at the
administrative boundary, and if you cannot do that, you need to perform a
spam/virus check before generating any sort of response.
This is really quite tricky to handle in these cases - usually we just
turn off the NDN sending.
While that will solve the problem it is, IMO, a poor operational choice.
(It's tricky in these cases because it's a 'non-standard' setup -
You know, there might actually be a reason why the standards fail to describe
certain setups...
with a
catch-all POP3 account at an ISP, then a mail collector collecting from
there, and sorting messages out and rejecting messages to unrecognised
users - what should happen there?
What should happen is that you shouldn't be doing things this way. I'm sorry,
but POP3 wasn't designed to be used for this. (And neither is IMAP.) The
semantics are all wrong - final delivery has occurred and success DSNs may have
been sent, the message envelope is gone and is very difficult to reconstruct in
a reliable fashion, etc. etc.
If there's really a need for a "pull" rather than a "push" delivery solution,
you should be using ODMR. ETRN is also an option in some cases, although it's
more of a "triggered push" than a "pull".
Now, unfortunately, while ODMR and ETRN at least get the delivery semantics
right, they both fail to meet the needs of the present-day Internet in an
important way: They do not provide a means of performing address validation at
the point of ingress. (This is also a problem for secondary MXes.) Various
prooposals have been made to address this problem (e.g., use DNS protocols to
serve up validation rules and lists of valid recipients), but AFAIK none have
gotten much traction. There are also some nonstandard tricks you can use (e.g.,
forward-validating milters) but these tend not to work well in "pull"
scenarios.
You can't do an SMTP reject, because
the message has already been 'accepted for final delivery' by the ISP,
so you have to send an NDN or not - the user isn't going to read the
messages, so an NDN is appropriate, but causes problems.)
Your basic problem can be addressed by being more selective in the NDNs you
send. There's no need to eliminate NDNs altogether. But some of your issues are
due to the protocol misuse you're engaged in, so some reconsideration of that
is also in order.
Ned