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 184.108.40.206... < 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 -0400
Okay, here I connected (manually) to my mailserver. After a quick> helo linus.slab.conman.org < 250 conman.org Hello firstname.lastname@example.org [220.127.116.11], pleased to meet you
To initialize the connection, I then did:> expn ------@conman.org < 250 <|/email@example.com>
Then, I did the following:> mail from:<------@conman.org> < 250 <------@conman.org>... Sender ok > rcpt to:<------@conman.org> < 250 <------@conman.org>... Recipient ok
Okay, 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/connected
Notice 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.
-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 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 …