[exim] helo_data and callouts

Top Page
Delete this message
Reply to this message
Author: Michael F. Sprague
Date:  
To: exim-users
Subject: [exim] helo_data and callouts
Hi folks,

I've noticed something else strange this morning. My setup is a relay/smarthost
running exim v4.43 on a DMZ and a final delivery server running exim v4.43 and
cyrus-imapd on the LAN. The relay handles messages coming in from the Internet
and as part of that does recipient verification via callout to the final
delivery server.

Due to circumstances not under my control, the relay sets smtp_active_hostname
to a different name than it's really called. I hope this can go away soon,
though. But when the relay communicates to the final delivery server, I need to
use its 'real' name during the SMTP transaction. The router to send to the
final delivery server looks like this:

internal_smtp:
driver = smtp
connect_timeout = 3m
helo_data = $primary_hostname
delay_after_cutoff = false

Whereas the router for mail leaving the site looks like this:

remote_smtp:
driver = smtp
connect_timeout = 3m
helo_data = ACTIVE
delay_after_cutoff = false
headers_remove = x-scan-signature

Where 'ACTIVE' is a macro.

So I set helo_data to use its 'real' name in internal_smtp. This all works fine
when it's doing a normal delivery to the final delivery server.

But, when it does a callout for recipient verification, it seems to ignore
helo_data. Here is a sample from my log on the final delivery server (hostnames
and domains and IPs changed to protect the innocent):

1) 2005-03-15 09:55:53 SMTP connection from [192.168.1.24] (TCP/IP connection count = 1)
2) 2005-03-15 09:55:53 H=relay.example.com (final-delivery.example.com) [192.168.1.24] Warning: remote host presented unverifiable HELO/EHLO greeting
3) 2005-03-15 09:55:53 H=relay.example.com (final-delivery.example.com) [192.168.1.24] Warning: Forged hostname detected in HELO: final-delivery.example.com
4) 2005-03-15 09:55:53 H=relay.example.com (final-delivery.example.com) [192.168.1.24] F=<> rejected RCPT <lett@???>: RVFY (response to "RCPT TO:<lett@???>" from localhost.dcunet.org [127.0.0.1] was: 550-Mailbox unknown. Either there is no mailbox associated with this\n550-name or you do not have authorization to see it.\n550 5.1.1 User unknown) RCPT=lett@??? SUB=NA MSGID=NA: response to "RCPT TO:<lett@???>" from localhost.dcunet.org [127.0.0.1] was: 550-Mailbox unknown. Either there is no mailbox associated with this\n550-name or you do not have authorization to see it.\n550 5.1.1 User unknown
5) 2005-03-15 09:55:53 SMTP connection from relay.example.com (final-delivery.example.com) [192.168.1.24] closed by QUIT

Line #3 is the important one. My HELO ACL detects that the relay forged the
HELO line. Now if this was a real SMTP transaction, it works fine:

1) 2005-03-15 10:00:56 SMTP connection from [192.168.1.24] (TCP/IP connection count = 2)
2) 2005-03-15 10:00:57 1DBDXU-0000Bm-JN <= sender@??? H=relay.example.com [192.168.1.24] P=esmtps X=TLSv1:AES256-SHA:256 S=42847 id=20050315092626.3D7974404FD07392@??? T="Liquidity, Community Charters, Auto Sales, and More..." from <sender@???> for user@???
3) 2005-03-15 10:00:57 SMTP connection from relay.example.com [192.168.1.24] closed by QUIT
4) 2005-03-15 10:00:57 1DBDXU-0000Bm-JN => user@??? F=<sender@???> R=cyrus_vdom T=cyrus_ltcp S=43415 H=localhost.example.com [127.0.0.1]
5) 2005-03-15 10:00:57 1DBDXU-0000Bm-JN Completed

See, no complaint about a forged HELO.

I was under the impression that a callout was treated like a 'normal' message
except for 2 things: a) it's a bounce message and b) we disconnect after we
determine the status of the recipient.

Is the behavior I'm seeing expected? Is it because it's a bounce message?

thanks,
mikeS

--
Michael Sprague | mfs@???
System and Network Engineering (SaNE), Inc
use STD::disclaimer;