jw@sics.UUCP (05/28/87)
Index: /usr/lib/sendmail.cf
This is a report of a pitfall rather than a bug. It concerns both BSD4.2
and BSD4.3. We had a problem with mail forwarding when the mail was
forwarded over ethernet by SMTP (that's the built in ether mailer in
sendmail).
More specifically: suppose that we have three machines A, B and C connected
by a local area network. Mail is transported between the machines by SMTP.
Suppose "a@A" sends a letter to "b@B" and that "b@B" is defined as the
alias "c@C" (or "b@B" has a .forward file that redirects mail to "c@C").
The letter will be received at host B. We now have a letter with
sender "a@A" and receiver "b@B". Sendmail redirects the letter to
"c@C". The letter is stuffed into an envelope on host B with the
S-field (the sender field) set to "a@A", and an R-field (the receiver
field) set to "c@C". SMTP (that is sendmail itself) connects to host C
and begins to send the letter to host C. Host C will agree that the
letter is originally from "a@A".
So far everything is OK. The next step is the problematic one:
host B will tell host C what the receiver address is.
Now suppose that sendmail.cf on host B has specified the C flag for
the SMTP mailer. Sendmail on host B will then try to be clever and
rewrite some receiver addresses relative to host C. This is done in
routine 'remotename()' in file parseaddr.c. We now encounter what appears
to be a bug in sendmail. sendmail will figure out that "c@C" is really
just "c" relative to host "C". 'remotename()' will be passed the name
"c" for further manipulating. 'remotename()' checks if the sender
domain name is non empty (it will be empty if the sender is on machine
B). If the sender domain is non empty and the receiver is of form
"c" rather than "c@C" or "c@D", then 'remotename()' rewrites "c" to
"c@sender domain name". Sender domain name is "A" here so we end up
with "c@A".
To sum up: if the C flag is turned on then host B will tell host C that
the receiver address is "c@A". If the C flag is turned off then host B
will tell host C that the receiver address is "c".
All in all it seems like a good idea not to specify the C flag for the
ether mailer. But our site (and a lot of other machines around here) had
the C flag turned on 8-(. This was because sendmail is a complicated beast
and the example sendmail.cf files on the original tape had the C flag
turned on.
Here is the specification of the ether mailer in /usr/lib/sendmail.cf
as it is delivered from Berkeley:
Mether, P=[IPC], F=mDFMueCX, S=11, R=21, A=IPC $h
Here is the specification of the ether mailer in
/usr/src/usr.lib/sendmail/cf.hosttable/etherm.m4
Mether, P=[IPC], F=mDFMueCX, S=11, R=21, A=IPC $h
Here is our current specification:
Mether, P=[IPC], F=DFMPXmsu, S=11, R=21, A=IPC $h
I'm still not sure if the C flag is useful in ANY mailer or if the flag
is totally obsolete. What does C stand for? Me thinks it stands for
"too Clever".
Here is a way to watch sendmail misbehave: You are on host B and you can
send mail directly to host C via SMTP. Cut the SMTP connection to host C
temporarily. This can be done by killing the sendmail demon on host C,
by disabling the network connection to host C or by telling sendmail
that the mailer connection to host C is expensive. The purpose of all this
is to get your hands on an entry in /usr/spool/mqueue. Send a letter
from host B to host C. The letter will end up in B:/usr/spool/mqueue.
Edit the qf file in /usr/spool/mqueue. Forge the sender address to be
say a@A.
Enable the SMTP connection to host C. On host B invoke sendmail with
/usr/lib/sendmail -q -v
--
Johan Widen
Swedish Institute of Computer Science
PO Box 1263, S-163 13 SPANGA, SWEDEN
UUCP: {seismo,mcvax,munnari,cernvax,diku,inria,prlb2,penet,ukc,unido}!enea!sics!jw