Callout

[tower]

Hi

How can i modify my callout option to resolve problem with:

2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
I=[234.234.234]:25 sender verify fail for <***@domain.com>: response
to "MAIL FROM:<>" from a.mx.domain.com [217.153.18.125] was: 550 5.5.0
Sender domain is empty.

My callout option in ACL:

deny
message = Unable to verify sender address ($sender_address).
!verify =
sender/callout=4m,maxwait=4m,connect=30s,defer_ok

I'm a little bit confused, because in exim log i dont see message
"Unable to verify sender address" but default(?) exim warning: "Sender
verify fail"

[Heiko Schlittermann]

Post by tower
Hi
2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
to "MAIL FROM:<>" from a.mx.domain.com [217.153.18.125] was: 550 5.5.0
Sender domain is empty.


 I'd say, it is a misconfiguration of the other side, since the sender
*can* be empty (for bounces). Checking the sender using a callback to
the responsible MX IMHO has to use an empty sender itself.

Post by tower
deny
message = Unable to verify sender address ($sender_address).
!verify =
sender/callout=4m,maxwait=4m,connect=30s,defer_ok

Check for use_postmaster and postmaster_mailfrom in the spec.txt.

Best regards from Dresden/Germany
Viele GrÌße aus Dresden
Heiko Schlittermann

[Bryn Jones]

-----Original Message-----
On Behalf Of tower
Sent: 28 September 2010 12:43
To: Exim-Users
Subject: [exim] Callout
Hi
2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
to "MAIL FROM:<>" from a.mx.domain.com [217.153.18.125] was: 550 5.5.0
Sender domain is empty.

That is an error from the site you are calling out to, the remote server is
refusing to admit the validity of a localpart when the sender (to the remote
server) is empty. That is broken as it's not going to be accepting bounces
or other automated messages (like vacation messages, etc).

Your choices are:

1. Try to get the other mail server fixed (good luck), or at least try to
inform them they are broken.
2. Skip the callout for that site (and any others which are similarly
broken).
3. Let the mail be rejected (as now).
4. Give up on offsite callouts (there are sites which report you as a
spammer and blacklist you for doing just a single callout).

Your best bets are 1 and 3, i.e.: tell them why there messages are not going
to get delivered to your site, and let them work out if they want to fix it;
or 1 and 2, Tell them they are broken (in the hope they fix it), and work
around it. The path of least disruption is of course 4.

deny
message = Unable to verify sender address
($sender_address).
!verify =
sender/callout=4m,maxwait=4m,connect=30s,defer_ok
I'm a little bit confused, because in exim log i dont see message
"Unable to verify sender address" but default(?) exim warning: "Sender
verify fail"

The message goes to the SMTP session, so in this case you should get
something like:

[...]
MAIL FROM: <***@some.valid.domain>
550 Unable to verify sender address

Bryn
--
Network Administrator
Parrs Wood High School

[W B Hacker]

Post by Bryn Jones

-----Original Message-----
On Behalf Of tower
Sent: 28 September 2010 12:43
To: Exim-Users
Subject: [exim] Callout
Hi
2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
to "MAIL FROM:<>" from a.mx.domain.com [217.153.18.125] was: 550 5.5.0
Sender domain is empty.

That is an error from the site you are calling out to, the remote server is
refusing to admit the validity of a localpart when the sender (to the remote
server) is empty. That is broken as it's not going to be accepting bounces
or other automated messages (like vacation messages, etc).

Someone needs to test what is traveling with the callout to confirm that..

If the text is correct, it didn't complain that the $local_part was empty.

It said the sender *domain* was empty.

That's either a misleading error message, or whole 'nuther issue.....

Bill Hacker

Post by Bryn Jones
1. Try to get the other mail server fixed (good luck), or at least try to
inform them they are broken.
2. Skip the callout for that site (and any others which are similarly
broken).
3. Let the mail be rejected (as now).
4. Give up on offsite callouts (there are sites which report you as a
spammer and blacklist you for doing just a single callout).
Your best bets are 1 and 3, i.e.: tell them why there messages are not going
to get delivered to your site, and let them work out if they want to fix it;
or 1 and 2, Tell them they are broken (in the hope they fix it), and work
around it. The path of least disruption is of course 4.

deny
message = Unable to verify sender address
($sender_address).
!verify =
sender/callout=4m,maxwait=4m,connect=30s,defer_ok
I'm a little bit confused, because in exim log i dont see message
"Unable to verify sender address" but default(?) exim warning: "Sender
verify fail"

The message goes to the SMTP session, so in this case you should get
[...]
550 Unable to verify sender address
Bryn
--
Network Administrator
Parrs Wood High School

[W B Hacker]

Post by W B Hacker

Post by tower
2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
to "MAIL FROM:<>" from a.mx.domain.com [217.153.18.125] was: 550 5.5.0
Sender domain is empty.

[...]

Post by W B Hacker
If the text is correct, it didn't complain that the $local_part was empty.
It said the sender *domain* was empty.

That doesn't matter, does it? With an empty sender ("<>"), local part
_and_ domain part of the sender are empty.

True. Of course.. ignore my comment.

Post by W B Hacker
That's either a misleading error message, or whole 'nuther issue.....

I don't think so.
-thh

ACK. What else *would* they say...

(also copying you 'direct', so we can see what OUR servers see ...)

I dont want to re-open the 'war' as to whether sender_verify callouts to any but
your own server pool are/are not a good idea, but HAVE tried them and found they
added significant pain for ZERO gain.

... in MY environment, anyway.

YMMV,

Bill

[W B Hacker]

Post by tower
2010-09-27 11:19:32 H=domain.com [123.123.123.123]:56505
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-***@conducive.org>: 0
greenmeadow.szaf.org-1285976102-***@conducive.org 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 ***@conducive.org

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-***@conducive.org>

.. 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-***@ml.th-h.de
F=<***@conducive.org> P=<***@conducive.org> 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 ***@conducive.org

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-***@exim.org
F=<***@conducive.org> P=<***@conducive.org> 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