Wednesday, August 23, 2000
Exchange Blows, and here's why
I found out the problem Spring was experiencing with Exchange. Here's the email I sent her describing the problem:
It was thus said that the Great Spring Dew once stated:
Did the copy of the message that I forwarded you have the full headers on it? In case not, here it is. Maybe this will help.
Got it! I figured out what Exchange is doing that is causing this. Leave it to Microsoft to break SMTP this badly. Grab some popcorn and watch (lines with `>' are what I type, and lines with `<' are the computer's response):
> telnet tower.conman.org smtp < Trying 208.235.96.122... < Connected to tower.conman.org. < Escape character is '^]'. < 220 conman.org ESMTP Sendmail 8.8.7/8.8.7; Wed, 23 Aug 2000 15:05:58 -0400Okay, here I connected (manually) to my mailserver. After a quick
> helo linus.slab.conman.org < 250 conman.org Hello spc@linus.slab.conman.org [208.26.72.3], pleased to meet youTo initialize the connection, I then did:
> expn ------@conman.org < 250 <|/home/spring/bin/connected@conman.org>Then, I did the following:
> mail from:<------@conman.org> < 250 <------@conman.org>... Sender ok > rcpt to:<------@conman.org> < 250 <------@conman.org>... Recipient okOkay, this tells the mailserver who the mail is from, and where it's going to. Then the actual message itself:
> data < 354 Enter mail, end with "." on a line by itself > From: ------@conman.org > To: |/home/spring/bin/connectedNotice the To: line. I think what Exchange is doing is substituting the given address (——) with the expanded address (/home/spring/bin/connected), trying to be “helpful” but blowing the entire process up.
> Subject: This is a test > > This is a test. It won't go through. > . < 250 PAA03898 Message accepted for delivery > quit < 221 conman.org closing connection < Connection closed by foreign host.And the message is accepted, but during processing will be rejected and a message bounced back.
Nice, eh?
-spc (Bloody Exchange … )
Informing Mark about it, he thinks (much to his regret) that Exchange might be allowed to do that as part of the SMTP protocol. I'll have to check up on that and see.
Sendmail Blows, and here's why
My my my … it looks like sendmail might be the culprit here, not Exchange. As per RFC-821:
"User name" is a fuzzy term and used purposely. If a host
implements the VRFY or EXPN commands then at least local mailboxes
must be recognized as "user names". If a host chooses to
recognize other strings as "user names" that is allowed.
In some hosts the distinction between a mailing list and an alias
for a single mailbox is a bit fuzzy, since a common data structure
may hold both types of entries, and it is possible to have mailing
lists of one mailbox. If a request is made to verify a mailing
list a positive response can be given if on receipt of a message
so addressed it will be delivered to everyone on the list,
otherwise an error should be reported (e.g., "550 That is a
mailing list, not a user"). If a request is made to expand a user
name a positive response can be formed by returning a list
containing one name, or an error can be reported (e.g., "550 That
is a user name, not a mailing list").
RFC-821, § 3.3. VERIFYING AND EXPANDING
EXPAND (EXPN)
This command asks the receiver to confirm that the argument
identifies a mailing list, and if so, to return the
membership of that list. The full name of the users (if
known) and the fully specified mailboxes are returned in a
multiline reply.
This command has no effect on any of the reverse-path
buffer, the forward-path buffer, or the mail data buffer.
RFC-821, § 4.1.1. COMMAND SEMANTICS
From my reading, it seems that sendmail should not be sending back the program name, but rather, it should just return the email address passed in.
This is not good …
