🚀 go-pugleaf

>   One of our users (ECH) got a message that said in the VMS MAIL "From:" line:

>         From:   IN%"hannon@ac.dal.ca" 16-DEC-1992 11:55:18.99

> and replied to that message.  When user "hannon" got the reply she was
> surprised, because she hadn't sent the original message.  She was worried that
> someone was forging mail.

Although it is trivial to forge mail, this does not look like a case of forged
mail.

>   We got ECH to send us the original message he replied to.  The headers,
> including VMS MAIL's, looked like this:

> From:   IN%"hannon@ac.dal.ca" 16-DEC-1992 11:55:18.99
> To:     IN%"ECH@ac.dal.ca"
> CC:
> Subj:   Beer compatible solder

> Return-path: <hannon@sparc3303.cacd.cr.rockwell.com>
> Received: from sparc3303.cacd.cr.rockwell.c (sparc3303.cacd.cr.rockwell.com) by
>  AC.DAL.CA (PMDF #2545 ) id <01GSDREERFN4001Z65@AC.DAL.CA>; Wed,
>  16 Dec 1992 11:28:35 -0400
> Received: from pc234sun2601.cacd.cr.rockwell.com ([131.198.60.234]) by
>  sparc3303.cacd.cr.rockwell.com (4.0/SMI-4.0) id AA15863; Wed,
>  16 Dec 92 09:27:56 CST
> Date: 16 Dec 1992 09:25:20 +0000
> From: hannon@ac.dal.ca (<hannon@sparc3303.cacd.cr.rockwell.com>)
> Subject: Beer compatible solder
> To: ECH@ac.dal.ca
> Message-id: <QB2F4A61@pc234sun2601>
> Content-transfer-encoding: 7BIT

>   My theory, based on the domain name "pc234sun2601.cacd.cr.rockwell.com" in
> one of the "Received:" lines, is that a badly written PC mail program wrote
> the original "From:" line like

>         From: hannon (<hannon@sparc3303.cacd.cr.rockwell.com>)

> and that PMDF rewrote "hannon" to "hannon@ac.dal.ca".  Is this possible?

Yes, this is precisely what happened.

> If so, is there any way to prevent PMDF from doing this?

Not really. When PMDF receives mail with headers containing local-parts and no
domain names it can do one of four things: it can reject the message because
the header is invalid, it can do nothing, it can add the name of the local host
to the address, or it can add the name of the host it received the mail from to
the address. None of these choices is appropriate for this particular message.

Rejecting messages like this would cause you to lose about 15% of your mail.
You have no idea (because PMDF insulates you from it) just how common the
no-host-name-in-address problem is, and how often PMDF is called upon to fix
broken headers. I don't think you or any other customer site would appreciate
bouncing a significant fraction of your mail. PMDF therefore doesn't even
implement this as an option. Delivering mail, bad address or no, is the top
priority.

Doing nothing is never appropriate either. It is imperative that PMDF do
something to make these headers legal, since there are plenty of mail systems
out there that will not accept messages with illegal headers. PMDF doesn't want
to be placed in a position where it cannot send the message forward or
backward. This option is therefore unworkable in practice.

Adding the local host name is often the appropriate thing to do, because SMTP
is often used by remote mail clients to submit messages. And often as not these
clients leave the host name out of the From: address, since they assume that
the SMTP server will tack on its own name. Failure to  do this breaks PMDF's
ability to support things like Eudora, Maelstrom, Popper, and many other PC/Mac
remote mail clients. PMDF therefore implements this option as a default since
it is far and away the most likely "correct" action to take.

PMDF also implements the "add the name of the sending system" option. This is
done because sendmail often leaves out its local host name on Cc: addresses. We
therefore provide this as a per-channel option called "remotehost". This can be
used in lieu of fixing broken sendmails at sites where this problem is
particularly acute. It is not a reasonable default action to take, however.

I suppose we could implement a fifth option, which would dredge the host out of
the oldest Received: header. However, I suspect that this action isn't
appropriate even in this case. Unless I miss my guess, the problem here is that
this message originated with a remote mail client and its SMTP relay didn't do
the right thing to fix up the message headers. The proper domain name to add is
therefore unknown; it could be pc234sun2601.cacd.cr.rockwell.com, it could be
sparc3303.cacd.cr.rockwell.com (but not sparc3303.cacd.cr.rockwell.c, which is
what the remotehost option would produce), or it could be something else that's
completely different. There's just no way to be sure.

> I can see it might be
> difficult, given that mapping my theoretical "From:" line to VMS MAIL might
> produce ``From: IN%"hannon"'' which is not much better than what was done in
> the first place.

Correct again. This is one of those cases where there's definitely a problem
but there's nothing that you can do about it. All the proposed cures are either
unworkable in practice or don't solve the problem.

My suggestion would be to contact the postmaster at this remote site and ask
them to fix their broken mailer that is emitting these bogons.

				Ned