Re: [exim] Exim Development

Bernd Jendrissek wrote:
> Eduardo M KALINOWSKI wrote:
>
>> Marc Perkel wrote:
>>
>>> There's another issue here that supersedes the RFCs. If the recipient
>>> server intends to reject the message then I agree. However if the
>>> recipient server is a customer of mine and I know for sure based on the
>>> response code that the rejection is in error, that it was unintended,
>>> and that the customer would want me to detect, report, and preserve the
>>> email then that's different. In my case I know that if I forward email
>>> to the customer and I get a 500 - Relaying Denied error that is not what
>>> the customer really wants to happen.
>>>
>>> My point - if the server replies with 550 but is doing so in error -
>>> that's different
>>>
>>>
>> If server A sends a message to server B, and server B replies with a 5xx
>> code, but does not mean it, and so it should instead be treated (by
>> server A) as a 4xx error, then you should fix server B, and not try to
>> make A interpret B's reply differently.
>>
>
> Of course he should fix server B. But how does he know it needs
> fixing? Either:
>
> 1. His angry client calls him demanding to know why their customers'
> emails are bouncing (if they didn't just go to a competitor instead).
>
> or
>
> 2. A buildup of emails intended (by reading the recipient addresses, not
> by reading minds) for his client in his misconfiguration-catcher queue.
>
> If I were Marc I would also want (2). Of course his client who
> misconfigures their MTA to reject their own mail deserves a LART. But
> what incentive does Marc have to deliver said LART? Answer: none.
> He'll just lose business.
>
> My suggestion to Marc is to pony up some money and pay someone to teach
> exim to do what he wants. It seems obvious that he isn't going to get
> what he wants for free.
>
>
>

Here's what typically happens. As many of you know I do front end spam
filtering. The customer points their MX records to my servers, I filter
the spam, and send the good email to the customer's server. Generally
this just works.

But sometimes what happens is as soon as the MX records are moved away
from the customer's server their server starts rejecting email inbound
for their domains. This happens a lot with Postfix customers. Their
server thinks that because it's not the lowest MX record that it is
supposed to froward the email and since my IPs aren't authorized to
forward the email is rejected (550 relaying denied). So their server is
working correctly until they start using my spam filtering.

What makes it even worse is often the customer is on a shared server of
a hosting company where they have no control that the hosting company is
staffed with morons who can't grasp the concept that their servers
should accept email even though the MX doesn't point to them.

I have implemented a number of things to reduce the problem. I do use
forward recipient callouts. On new customers by default if the recipient
callout is rejected I return a temp (4xy) error to the incoming
connection. It isn't until the customer actually accepts some good email
that they make my "known good customer list" where forward callouts
determine if the recipient is good.

However - the process is still crude. So - an important feature to me
would be if when I do a forward callout and get a 5xy error if I had the
string it returned I could then test that string for either "relay
denied" which indicates a server misconfiguration, it "invalid
recipient" which indicates the recipient is bad.

If I could detect "relay denied" in the forward callout I might accept
the incoming email and store it in a file so that later when the problem
is fixed I can then send the stored email on to the customer.

So - is there a reason that on forward callouts we can't get the
rejection string?