kyle@uunet.UU.NET (Kyle Jones) (03/13/91)
Bill Wohler <wohler@sap-ag.de> writes: > the following diagram, from this paper describes the rulesets that > sendmail applies to messages. > > --> 0 -> resolved address > / > / /-> 1 -> S -\ > addr -> D- --> 4 -> msg > \-> 2 -> R -/ > > D - sender domain addition > S - mailer-specific sender rewriting > R - mailer-specific recipient rewriting 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. :-/ kyle jones <kyle@uunet.uu.net> ...!uunet!kyle
rickert@mp.cs.niu.edu (Neil Rickert) (03/13/91)
In article <125390@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: >Bill Wohler <wohler@sap-ag.de> 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 <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kyle@uunet.UU.NET (Kyle Jones) (03/14/91)
In article <1991Mar13.003432.14835@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > In article <125390@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: > > [...] 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. > > 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. I no longer have a pristine 5.61 sendmail to look at, but the problem is still there in sendmail 5.64. Here's the offending line from src/usersmtp.c: smtpmessage("RCPT To:<%s>", m, remotename(to->q_user, m, FALSE, TRUE)); > 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. RFC 821 doesn't seem to allow this usage. The way I read it, a domain spec is always required. But yes, it's a useful thing to do just the same. > 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. A reasonable thing to do is to use the host part of the (mailer, host, user) triple to qualify the user part if the host part doesn't match the MX host. Using the domain of the _sender_ is clearly not the answer.
rickert@mp.cs.niu.edu (Neil Rickert) (03/14/91)
In article <125491@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: >In article <1991Mar13.003432.14835@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > > In article <125390@uunet.UU.NET> kyle@uunet.UU.NET (Kyle Jones) writes: > > > [...] 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. >I no longer have a pristine 5.61 sendmail to look at, but the >problem is still there in sendmail 5.64. Here's the offending >line from src/usersmtp.c: > > smtpmessage("RCPT To:<%s>", m, remotename(to->q_user, m, FALSE, TRUE)); I just checked. You are indeed correct, and this is a SERIOUS bug. My sources contain instead: smtpmessage("RCPT To:<%s>", m, to->q_user); but in checking the RCS archives, I find this correction is part of the IDA mods. > > 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. Funny that I happened to mention that yesterday. Today I find that a neighboring machine which uses my host as a relay was recently misconfigured during installation of a new release of SunOS. The result is, it doesn't recognize its own address, and relays it back here. After 17 hops the message is rejected, breaking the mailing loop. I had to resort to the configuration change of removing the domainname before forwarding to the host. Fortunately my sendmail does not suffer from this bug. Incidently, if my 'sendmail' receives a message to 'user@[n1.n2.n3.n4]' it always relays it without a domain name, since many hosts do not recognize their own domain names. I have cross-posted this to comp.bugs.4bsd -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940