Re: [exim] verify = recipient/callout --> Exchange2013

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Heiko Schlittermann
Fecha:  
A: exim-users
Asunto: Re: [exim] verify = recipient/callout --> Exchange2013
Jeremy Harris <jgh@???> (So 16 Nov 2014 23:37:07 CET):
> On 16/11/14 22:11, Heiko Schlittermann wrote:
> > Jeremy Harris <jgh@???> (Fr 14 Nov 2014 11:29:09 CET):
> >> On 14/11/14 10:10, Heiko Schlittermann wrote:
> >>> Currently it seems that they are not able to reject at RCPT, they
> >>> reject after DATA: "550 5.1.1 User unknown".
> >>
> >> One has to wonder what the Exchange response to an SMTP session
> >> with one good, one bad RCPT is.
> >
> > It just rejects the complete message…
>
> Brilliant!
>
> Your only recourse would seem to be "max_rcpt = 1" on
> the transport feeding the Exchange system.
> I don't know up front how this will interact with
> cutthrough. It seems that the extension you suggested
> isn't going to be useful (for Exchange).


Right, but it would motivate them, to fix the exchange,
because we would just "mirror" its strange behaviour to the outside, and
hope that there'll be lots of complaints in cases like

    <foo@???>           OK
    <bar@???>           OK
    <unknown@???>       NOT OK


where the sender just gets "550 User unknown" with no further indication.
They broke it, they need to fix it.

As a temporary work around we can use some acl like

    acl_check_rcpt:
                # $recipients_count contains the number of already(!)
                # accepted recipients
                defer   condition = $recipients_count
                accept


But this has some impact too, foo gets it's mail, but bar gets the
message after the next retry of the sending server. For normal users
this will be irritating.

    Best regards from Dresden/Germany
    Viele Grüße aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: 7CBF764A -
 gnupg fingerprint: 9288 F17D BBF9 9625 5ABC  285C 26A9 687E 7CBF 764A -
(gnupg fingerprint: 3061 CFBF 2D88 F034 E8D2  7E92 EE4E AC98 48D0 359B)-