Path: utzoo!news-server.csri.toronto.edu!rutgers!att!linac!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.sendmail Subject: Re: surprises from the `C' mailer flag (was: Re: -bt test option) Keywords: -bt Message-ID: <1991Mar13.003432.14835@mp.cs.niu.edu> Date: 13 Mar 91 00:34:32 GMT References: <187@rand.mel.cocam.oz.au> <2655@sapwdf.UUCP> <125390@uunet.UU.NET> Organization: Northern Illinois University Lines: 43 In article <125390@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: >Bill Wohler writes: > > the following diagram, from this paper describes the rulesets that > > sendmail applies to messages. > > [ diagram removed for brevity] >I discovered recently that this diagram isn't quite right with >regard to the addition of the sender domain, at least in sendmail >5.61. > >If the recipient mailer is sendmail's builtin SMTP mailer, then >the user part of the (mailer, host, user) triple of ruleset 0 >will have the sender's domain appended, if the sending mailer has >the C flag set and the user part doesn't have a domain spec. >This means that the RCPT To: SMTP command is sent out with the >_sender's_ domain appended to the recipient, instead of the >recipient's own domain. > >The `C' flag is great for fixing up headers lacking a FQDN, but >applying it to recipient addresses in the envelope is going more >than a little overboard I think. The fix is easy: always resolve to >(tcp, domain, user@domain) when sending via SMTP. Older >sendmail.cf's already do this, I'm sure. Now I know why. :-/ Are you SURE about this. This does not happen with my sendmail (5.65-IDA). An envelope recipient address is resolved with parseaddr() which does not act on the C-flag. All other addresses (envelope sender and header) are processed with remotename() which does act on the C-flag. While I agree you should normally resolve to (tcp,domain,user@domain) there are circumstances where it is useful to resolve to just (tcp,domain,user) -- in particular this lets you get mail to someone on a badly misconfigured host which does not recognize its own domain name. The real problem with resolving to (tcp,domain,user) is that if there is an MX record directing the message to a different domain, that receiving domain will have lost the necessary information on the proper domain for handling the message. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940