[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

zmailer transports smtp.c "bug"



ZMailer/transports/smtp.c bug and fix
-------------------------------------

This is in reference to the Finnish distribution package
zmailer2.2.1-mea-m8. I haven't back-checked on the earlier
code I was running, so it's not clear that the problem is new
or old, since I don't have the source handy.(I have a feeling it
has been there all along).

On my system, getmyhostname() returns a simple unqualified hostname
(just as 'hostname' does), whereas other machines may choose to
define their hostname as host.domain. This case applies to the simple
hostname scenario.

In zmailer, one way of forcing the smtp transport agent to spit out
a correct domain parameter in a EHLO/HELO transaction is to specify
it with the -h flag in the smtp call (from the smtp manpage):

     smtp [ -dersxV ] [ -c channel ] [ -h heloname ] [ -l logfile
     ] [ -T timeout ] host

     -h host
          specifies the hostname for the SMTP HELO greeting.  The
          default is the hostname of the local system, as
          returned by gethostname(2) or uname(2).

Adding the -h <myhost.domain> to the smtp call in scheduler.conf
didn't work as I expected - it still spat out my simple hostname during
the greeting ( and rudely shows up in the smtp log when chatting to
another zmailer site.).

Clearly goes against the intent of rfc.1123, especially when mail is
sent via smtp outside of the local subnet to another domain:

      5.2.5  HELO Command: RFC-821 Section 3.5
 

         The sender-SMTP MUST ensure that the <domain> parameter in a
         HELO command is a valid principal host domain name for the
         client host.  As a result, the receiver-SMTP will not have to
         perform MX resolution on this name in order to validate the
         HELO parameter.

A Full host+domain is also something smtpserver prefers (and also complains
when other hosts violate it). Just odd that smtp is inconsistent with it.

This minor bug in the (at least current version) transports/smtp/smtp.c
code prevents the -h flag from doing anything at all:

At the beginning of the code:
line 218:
	myhostname[0] = '\0';

Then the case statement where myhostname can be stuffed:
lines 240:243 :
	  case 'h':		/* my hostname */
	    strcpy(myhostname, optarg);
	    break;

First it does grab the optarg and set myhostname equal to it,
but then right after those case statements we see:
lines 293:294:
	getmyhostname(myhostname, sizeof myhostname);
	stashmyaddresses(myhostname);

which just resets it back to hostname, effectively obliterating
the functionality of the -h flag.

My fix is to check to see whether optarg was stuffed into the
variable, and if not, then ensure that at least something half-valid
is there (some machines may have a FQDN as hostname, and so won't
have to worry about this):

line 293:
if(myhostname == '\0') getmyhostname(myhostname, sizeof myhostname);


Now it works just fine, and those :

250-That hostname is inconsistent with your address to name mapping.

lines in the smtp logs are gone.

Perhaps this can be put into the next distribution :-)

Cheers,


--
James S. MacKinnon             Office: P-139 Avahd-Bhatia Physics Lab
Computing/Networking           Voice : (403) 492-8226
Department of Physics
University of Alberta          email : jmack@phys.ualberta.ca
Edmonton, Canada T6G 2N5       bitnet: jmack@triumfcl  jsm1@ualtamts