Re: [exim] Feature I REALLY need - SMTP response strings

Marc Perkel wrote:
> I have one feature I really need. When verifying, in this case recipient
> verify, I need to be able to read the string I get back from the target
> server.
>

IF you fix the underlying issue, you probably won't need that...

> I'm in the front end spam filtering business. Most of what I do is front
> end filtering. The set their MX records to me, I fliter the spam, and
> forward the good email to the original server. When people sign up I
> read their current lowest MX and add it to a table that is used to
> forward the mail to when I get done with it. Generally it works well.
>

By itself, that is 'not good enough'.

So long as the 'original' server mx record is still in a nameserver (think
caching, TTL, etc.), you shoudl have an initial period of uncertainty wherein
some mail goes thru the filter, other goes to the old address.

No doubt you can, and do, live with that.

But where next?

Is the 'original' server still pubished at all, in either A or MX records?

If not, how are you managing to direct traffic TO it?

If so, how do you insure it will not be treated as a fallback mx?

> When I get an incoming email I do a forward callout to the recipient
> server to verify that the recipient is good. If the target server
> rejects the recipient in the RCPT TO phase then I reject the incoming
> email indicating that the user doesn't exist.
>
> Here's the problem I'm trying to solve. The user changes their MX
> records to my servers and at first everything works. Then 2 hours later
> I get a call saying that email is being bounced. What happens is that in
> some cases the original server thinks it is no longer the server for
> that domain because it is no longer the lowest MX record so it replies
> that my server is not authorized to relay through their server.
>

That sounds wrong, as your traffic is not for 'relay', but for local users.

Why not send to your clients in 'submission' mode over 587 with a bespoke uid:pwd?

> What I need to do is detect that this is happening and at least store
> the incoming email and alert me that there's a problem.

Better to prevent it in the first place.

One presumes these cannot be guaranteed to be any particular breed of MTA, let
alone conveniently Exim.

But to the extent the clients can grant you ONE valid uid:pwd, it should matter
not how else they are configured. Such arrivals generally have 'most favored'
privileges, *especially* when all their traffic is for on-box users.


> I have yet to
> find a solution. But if I could do a callout and look at the response to
> see if the word RELAY is in it then that would be a very good indication
> that the target server is misconfigured.

Perhaps. But you would be treating the symptom, not the disease, moreover that
of an environment you cannot reasonably expect will be altered to suit you.

>
> Similarly, and this happens less often, that because all the email for
> the domain is coming from a few IP addresses that I run into rate
> limiting. Too many connections from one IP address. This results in
> delayed email and I am usually not aware of the problem until the
> customer complains.

That does not need to happen unless you are secretly running QMail, and/or the
clients you are servicing [1] has a rather large number of virtual domains on
one IP.

Even so...

Look into 'queue_only', and ways you can control the frequency of queue runs and
the 'batch' size.

Exim (per RFC 822 onward) can easily put 100 messages to 100 recipients down a
single connection to the target domain, and even very draconian configs usually
allow 3 per sending host as sender verification callouts etc. need one open -
by definition specifically when another session is in process.

>
> I would also like to get the response from the target server on 550
> errors so that I can put it in my log files so I can review why the
> target server rejected email.

You should already be getting that, and stock settings can allow selecting it
for logging.

> Some times the target server is also still
> running spam filtering and it rejects on a false positive on their end.
> That would be something I'd like to be able to log so that I can find
> the problem.
>
> Thoughts?
>
>

Dig deeper into other means of becoming 'man in the middle' gracefully, and you
should find less need for failure analysis.

HTH,

Bill

[1] As the term is used in the field of animal husbandry.