>>>>> "DavidW" == David Woodhouse <dwmw2@???> writes:
DavidW> On Thu, 2007-10-25 at 13:36 +0200, bremner@??? wrote:
>> Can anyone think of an easy way to to start rejecting a sender
>> after it defers X times in Y hours? I guess eventually the
>> edge MTA will give up, but I can afford to be a lot more
>> agressive than they can in terms of what I reject.
DavidW> As a general rule, you should strive _not_ to reject more
DavidW> than any server which will receive mail for you and relay
DavidW> it (such as, traditionally, a backup MX). That leads to
DavidW> bounce messages being sent to innocent bystanders whose
DavidW> address was _faked_ as the sender of the mail you reject.
Well, OK, I take your point about the general rule. On the other hand,
it won't inconvenience any actual users, since I am only rejecting
mail without verifiable addresses. I agree it does place load on
innocent servers. Luckily the volume is small.
DavidW> Instead, you should filter at the 'edge MTA'
[snip]
DavidW> If you can't control the 'edge MTA' even to that extent,
DavidW> then the best course of action would be to stop relying on
DavidW> it.
OK, that would be in principle correct, but then I would not get any
email :-). I don't have any control over the edge MTA; on the other
hand it is where all my mail goes. Such is life in a big organization.
Maybe given that the mail has already been stored on the other server,
the right way to proceed is to just to tag incoming mail that fails
sender verification with a header, and let the MDA black hole it. For
mail that fails sender verification there seems to no advantage really
to rejecting, then bouncing the mail since with pretty high
probability, the bounce will not reach anyone (other than possibly
some bemused postmaster) anyway.
This still leaves the question of how to detect senders that defer
persistently; what I do with those messages is a somewhat orthogonal
question. As it is, I can accept them the first time they defer, or
do nothing and let them bounce (from the edge MTA) eventually.
Thanks,
David
