SMTP vs. dots

[guy at gorodish.UUCP]

>So what's going on?  Is this a bug in the protocol?

No, it's a feature of the protocol.  See RFC 821, "Simple Mail Transfer
Protocol".

>Has this been solved?  Shouldn't these things be escaped like
>"From" lines?

Yes.  See RFC 821, Page 41 (page 47 in the "Internet Mail Protocols"
document):

	4.5.2 TRANSPARENCY

	   Without some provision for data transparency the character
	   sequence "<CRLF>.<CRLF>" ends the mail text and cannot be
	   sent by the user.  In general, users are not aware of such
	   "forbidden" sequences.  To allow all user compsed text to
	   be transmitted transparently the following procedures are
	   used.

	      1.  Before sending a line of mail text the sender-SMTP
	      checks the first character of the line.  If it is a
	      period, one additional period is inserted at the
	      beginning of the line.

	      2.  When a line of mail text is received by the
	      receiver-SMTP it checks the line.  If the line is
	      composed of a single period it is the end of mail.  If
	      the first character is a period and there are other
	      characters on the line, the first character is deleted.

The feature described in 1. is enabled on a per-mailer basis in
"sendmail" by turning on the "X" flag for the mailer.  The feature
described in 2. is enabled for all mailers running in "SMTP mode";
i.e., all mailers started off by somebody connecting to the "sendmail"
daemon's SMTP port.

When "sendmail" is receiving its message from some source other than
an SMTP connection - e.g., reading the message being handed to it on
its standard input by "Mail" - it will treat "." on a line by itself
as the end of the message body.  If you turn on the "ignore dots in
messages" flag (by passing the "-Oi" flag as an argument to
"sendmail") it will not treat periods specially in any way.

"/bin/mail", prior to the advent of "delivermail", accepted either a
"." on a line by itself or an EOF as the end of a message.  The
version of "/bin/mail" that worked with "delivermail" and works with
"sendmail" just turns around and fairly quickly calls "delivermail"
or "sendmail" and lets it collect the body of the message.  As such,
it doesn't want to use the "-i" flag to "delivermail" or the "-Oi"
flag to "sendmail".

"/usr/ucb/mail" permits you to override this, but it collects the
mail itself and sends it off to "delivermail" or "sendmail" when it's
done.  As such, it passes the "-i" flag to *both* of them ("-i" is an
undocumented synonym for "-Oi" in "sendmail", left around for
compatibility with "delivermail").

I assume MH also does the right thing; i.e., it collects the message
itself and passes "-i" or "-Oi" to "sendmail".  The fact that the
message gets correctly delivered on some occasions supports this
conclusion, unless MH does something different with "!" and "@"
addresses (in which case it should consider leaving that up to
"sendmail", considering that's its job).

When you do these tests, does a recipient address *ever* resolve to a
non-IPC mailer?   If so, make sure that if that mailer ever runs
"sendmail" it runs it with "-i" or "-Oi".  I presume you have added
stuff to map UUCP addresses to local addresses, so that "fritz!zemon"
gets delivered using SMTP eventually.  Make sure this isn't somehow
causing the problem; does mail from "kelly" to "fritz!zemon" *ever*
pass through the hands of UUCP?  If so, make sure it doesn't do so.
Also, if you've changed *any* of the configuration files, make sure
you don't run *any* IPC mailer without having the "X" flag set for
the mailer.