Subject: Re: Headers, domains and pine (and a solution)

From: [email-masked] (Jon Peatfield)
Date: 25 Nov 1994 04:56:28 GMT

Much as I hate following up my own postings, I just did a couple of
extra checks.  In fact the last version I built was 3.88 not 3.89 as I
stated.  Certainly setting the userdomain to "@" didn't work back in
3.88 it results in mail being sent to userA@@ which is clearly silly.

So the obvious question is when was this useful feature added (and why
wasn't it given more publicity), and can I rely on it being maintained
for the forseeable future?

  -- Jon

--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852     Mail: [email-masked]

     Monotype Fonts.  Get 'em while they're 'ot -- onna stick.

---

From: [email-masked] (Jon Peatfield)
Date: 25 Nov 1994 04:46:05 GMT

Last time I built pine (3.89) I read through all the docs and decided that I
couldn't have the From: and To: headers set the way that I want for local
users.  What I wanted was for pine to leave the totally alone and let our MTA
(sendmail/smail) rewrite them if they were leaving the site.  That is I
wanted pine to leave the headers just as I typed them in and to generate a
From: header with just the login name on it.  (After all this is what most
other MUAs do.)  I couldn't find a way to do this so I settled for setting
the userdomain to our site domain name.  This means that fro pien users even
internal mail is to userA@site and from userB@site rather to userA and from
userB.

Well I started looking at 3.91 recently (just after it came out in fact), and
it appeared that the same was true.

Can someone please explain to me why pine should get involved in setting the
domain part of addresses which can be correctly handled in the MTA?

Looking through the code I find that the addresses are passed round as
ADDRESS structures which get converted to strings by the c-client routine
rfc822_write_address(), which in turn calls rfc822_address().  In here I find
that setting the domain (via userdomain or whatever) to "@" has the desired
effect, though it is marked as:

>     if (*adr->host != '@') {	/* unless null host (HIGHLY discouraged!) */
>       strcat (dest,"@");	/* host delimiter */
>       strcat (dest,adr->host);	/* write host name */
>     }

This is the only mention of "@" as a domain that I'd seen anywhere in the
source or documentation, yet it is about the most useful default setting that
I can imagine in situations where you are talking through an MTA which will
perform the expansion if needed.

Can I suggest that the use of "@" as a userdomain to achieve this effect be
added to the documentation, or that someone point me at where it is
documented if I totally missed where it is mentioned.

Can I rely on this feature remaining in future versions of pine?

  -- Jon Peatfield  ([email-masked])

---

From: Mark Crispin <[email-masked]>
Date: Sun, 27 Nov 1994 16:27:18 -0800

On 25 Nov 1994, Jon Peatfield wrote:
> This means that fro pien users even

Correct.  And, if userA happens to have a filter that causes the message 
to be delivered outside of the local machine without going through your 
MTA's fix-up code, the right thing happens.  If userA's mailbox happens 
to be on an IMAP server, the right thing happens.

This is an old issue (17 years and counting).  Just about everybody who 
is anybody in the field of email software design has concluded that 
unqualified addresses are A Very Bad Thing.

> domain part of addresses which can be correctly handled in the MTA?

See above.  Only very old software depends upon MTA fixup.

Designers of modern MUAs do not write unqualified local addresses because 
they have been burnt entirely too many times.  Claims to the contrary 
notwithstanding, the problems of unqualified local addresses have NEVER 
been solved so that there is a guarantee that messages with such will not 
escape their zoos.  These problems have consumed a disproportionate 
amount of support time dealing with bug reports from (often very irate) 
users who've been screwed by this.

> documented if I totally missed where it is mentioned.

You have stumbled upon an internal communication mechanism between Pine
and c-client, used for an unrelated internal purpose.  It has magic
implications specifically for that purpose.  It is NOT(!!) designed or
intended to provide support for unqualified addresses in outgoing
messages. 

If it ``works'' with what you're doing, it is entirely by accident.  I
wouldn't be at all surprised if you have mysterious Pine crashes (and if
so we will definitely fix the bug that lets you do poke at it).  It 
*will* interfere with internal Pine operations, since that mechanism is 
there for a completely different purpose.

> Can I rely on this feature remaining in future versions of pine?

Absolutely not.  If you exploit a bug in Pine that lets you abuse an
internal mechanism, you are on your own.  We only support that which we 
document.