Re: [exim] Callout

Thomas Hochstein wrote:
> W B Hacker schrieb:
>
>>>> 2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
>>>> I=[234.234.234]:25 sender verify fail for <sender@???>: response
>>>> to "MAIL FROM:<>" from a.mx.domain.com [217.153.18.125] was: 550 5.5.0
>>>> Sender domain is empty.
> [...]
*snip* (previously covered)

Thomas,

Here are my relevant log portions for the send to you:

=====

2010-10-01 23:34:48 [29662] SMTP connection from [217.160.95.119]:52820
I=[203.194.153.81]:25 (TCP/IP connection count = 2)


2010-10-01 23:34:52 [97816] H=greenmeadow.szaf.org [217.160.95.119]:52820
I=[203.194.153.81]:25 F=<> rejected RCPT
<greenmeadow.szaf.org-1285976102-testing@???>: 0
greenmeadow.szaf.org-1285976102-testing@??? invalid address: No such
account here.

2010-10-01 23:34:52 [97816] H=greenmeadow.szaf.org [217.160.95.119]:52820
I=[203.194.153.81]:25 incomplete transaction (RSET) from <>

2010-10-01 23:34:53 [97816] H=greenmeadow.szaf.org [217.160.95.119]:52820
I=[203.194.153.81]:25 incomplete transaction (QUIT) from <> for wbh@???

2010-10-01 23:34:53 [97816] SMTP connection from greenmeadow.szaf.org
[217.160.95.119]:52820 I=[203.194.153.81]:25 closed by QUIT

===

first off, using a machine-generated bogus destination address such as;

<greenmeadow.szaf.org-1285976102-testing@???>

.. is probably going to get you a rejection in ALL cases where the target does
*recipient* verification. There is controversy about sender-_verify callouts,
but AFAICS, *recipient* verification is unchallenged as always a good idea.

At least the actual message makes it through:

2010-10-01 23:34:57 [97807] 1P1p7f-000PRV-Jg => exim-users@???
F=<wbh@???> P=<wbh@???> R=dnslookup T=remote_smtp S=1732
H=mx3.th-h.de [217.160.95.119]:25 X=TLSv1:AES256-SHA:256 CV=no
DN="/C=DE/ST=RLP/O=Greenmeadow Server/CN=greenmeadow.szaf.org" C="250 OK
id=1P1p88-0001r1-Os" QT=18s DT=15s

2010-10-01 23:34:57 [97807] 1P1p7f-000PRV-Jg Completed QT=18s

====

By comparison, tahini mailing list server made the more 'classical'
sender-verification roughly interleaved in time:

++++

2010-10-01 23:34:48 [29662] SMTP connection from [131.111.8.192]:43205
I=[203.194.153.81]:25 (TCP/IP connection count = 1)

2010-10-01 23:34:49 [97815] H=tahini.csx.cam.ac.uk [131.111.8.192]:43205
I=[203.194.153.81]:25 incomplete transaction (QUIT) from <> for wbh@???

2010-10-01 23:34:49 [97815] SMTP connection from tahini.csx.cam.ac.uk
[131.111.8.192]:43205 I=[203.194.153.81]:25 closed by QUIT

2010-10-01 23:34:49 [97807] 1P1p7f-000PRV-Jg => exim-users@???
F=<wbh@???> P=<wbh@???> R=dnslookup T=remote_smtp S=1732
H=tahini.csx.cam.ac.uk [131.111.8.192]:25 C="250 OK id=1P1p7z-0007gL-LL" QT=10s
DT=7s

++++

Resulting in 9 seconds shorter delay (compare my QT= and DT= log times as well
as the log timestamps).

What tahini is asking of my server will not get them blacklisted.
Not here, anyway.

Attempts to machine-generated non-existent addresees, OTOH, CAN get blacklisted
here as zombies. That has nothing to do with callouts.

So - if you feel you 'must' make sender-verification callouts, it would be
better to at least do them 'by the book', as tahini does.

HTH,

Bill