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 <[email protected]>: 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 <[email protected]>: 0 [email protected] 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 [email protected] 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; <[email protected]> .. 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 => [email protected] F=<[email protected]> P=<[email protected]> 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 [email protected] 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 => [email protected] F=<[email protected]> P=<[email protected]> 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 -- ## 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/
