mail_host patch

Vernon Schryver
Thu Jun 12 16:01:51 UTC 2003

>From: Spike Ilacqua <>

> ...
> But this still begs the question of what mail_host should be.  What
> would you expect in the case of?
> bar!
> I *belive* that in all three cases sendmail will set "{mail_host}" to
> "", as my code will.  Canonify however will give you "" in
> the last case.  Obviously the ruleset could be writen to give you just
> about any result.

I been looking at this issue. 
{mail_host} is for the third case at least in 8.12.10.Beta0.
Section 3.3 RFC 2821 justifies that choice.

I see three alternatives:

  1. use ${mail_host}
  2. use something like Spike's patch
  3. a new macro set with a local rule about like
      Spike's suggestion.

Looking at the recent Canonify (3) ruleset, I was reminded of
stuff that sendmail does but that is not done by #2, including

    - canonicalizing the domain name into a consistant string.
	This matters for whitelisting.  For example, regardless of
	whether a user configures an MUA with
	or, it would be nice if the result were the same.

    - dealing with pure UUCP paths
	Does this still matter?  Probably somewhere.

    - dealing with SMTP mail lists
	Does this matter?  Should something reasonable happen with
	a list as a sender?  I don't know.

    - dealing with stray '\r' characters at the end of the env_from
	value that dccm now receives.  This matters because I've
	seen some spam with the oddity.  It is also trivial to fix.

#1 has the problem with smart relay hosts that Spike noted as well
as producing a null value for local senders.

#3 has compatibility worries.

My inclination is to change misc/dcc.m4 to create a ${dcc_mail_host} macro
much as Spike wrote, and have dccm use ${dcc_mail_host} it it is not
null and to fall back on ${mail_host}.  

What do you think?

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.