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? -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
