On Mon, 1 Mar 2004, Russell King wrote:
> They are wrong. As I've stated here before, I strongly advise people
> to refuse to accept mail from people blocking <>. The reason is that
> if you are unable to deliver their message, you have no way to tell
> the sender that you were unable to deliver.
Indeed. I'd recommend using callout selectively, however, because
there's sure to be irresistible pressure (i.e from someone
sufficiently high enough in manglement to make the technical arguments
irrelevant) on the mail admin to accept mail from a few of those
broken MTAs.
What we do is to have a list (partially wildcarded) of domains where
callout *is* used. Having an exception list where callout is *not*
used would be another possible approach, obviously - note, however,
that there are vast numbers of MTAs out there which swallow just any
preposterous local-part at RCPT time, and only reject later (too late
for callouts to work), and it would be a waste of effort doing
callouts to them.
> However, if you don't accept the message in the first place, at least
> the user stands a chance of receiving a bounce message back explaining
> that his ISP sucks, and that he should find a more responsible ISP.
Unfortunately, he's by no means sure to get that message. Quite
likely his MTA-from-hell will invent a diagnostic, such as I saw the
other day:
550 5.1.1 <A.Flavell@???>... User unknown
- a diagnostic which they had most certainly not got from us! (in this
particular case, we /had/ told them that their IP was blacklisted at
sorbs).
> Hopefully, with enough people doing this to these ISPs, customer
> pressure will eventually cause the ISP to eventually suck less.
If you can keep your action afloat in the face of hostile users, then
I can only wish you good luck ;-)
> (Maybe the exim sender verification failure message should state
> something like this in teh case of MAIL FROM:<> failing? 8))
There's a main-configuration option which has to be enabled before the
detailed reason gets included in exim's response:
smtp_return_error_details = true
There *should* then be an $acl_verify_message with details that can be
included in a rejection message.
But my notes (from exim 4.14) say that it /still/ reported nothing
more exciting than "Sender verify failed" in this particular context.
cheers
