Subject: Suppressing "@userdomain" in @-less To

From: Jeffrey Goldberg <[email-masked]>
Date: Wed, 15 Nov 1995 12:00:07 +0000

One solution to a problem I have (described below, but not really needed
to understand the question) would be to suppress Pine's insistance
on rewriting (in a to or cc field) "foo" as "foo@userdomain".

Alternatively, is there a way to get pine to use an different "userdomain"
for the To and Cc (and Bcc) fields then for the From field.

I would like a solution that can be done in pine.conf.  That is,
a solution that has each user modifying their own .pinerc is not
satisfactory.

Because we run on a variety of different platforms (many sharing the
same pine.conf) I would really not like to have to modify the pine
source and recompile (in particular, I don't want to recompile
either PC-Pine or VMS-Pine).  I am willing to entertain such a solution
if I can expect I will not have to do the same for future releases.

The Problem:

As I mentioned above, it is not really essential that you understand
the problem that I am trying to solve to help answer the question,
but maybe you see alternative solutions (there are alternative solutions
which I am also exploring)

For the examples, I will use my username (cc047) and nickname "J.Goldberg"
and my (usual) local host (xdm011.pegasus.cranfield.ac.uk), and our
smtp server (calisto.ccc.cranfield.ac.uk).

Our smtp server (running pp, not sendmail) will do a number of things
When it receives and smtp connection sending mail with a from line
like ([email-masked]) it will rewrite it as
[email-masked].  So in my case, if it is handed
  From: [email-masked]
it will rewrite that as 
  From: [email-masked]

However, if it receives something like
  From: [email-masked]

it will not attempt to rewrite it.

On the otherhand if it gets something to

  RCPT To: [email-masked]

(A non-existent user)

It will provide immediate feedback that the user is unknown.  It will
also do the same with

  RCPT To: G.Goldberg

This means that Pine can refuse to send the message.  However, if the smpt
server is handed

  RCPT To: [email-masked]

It will accept the message, and the error will only be reported as a bounce
later on.

Obviously the correct solution is to modify all of our pp tables
to somehow get the rewriting we need, but that requires understanding pp
which is somehow not as easy as understanding pine. 

-jeff

Jeffrey Goldberg                +44 (0)1234 750 111 x 2826
 Cranfield Computer Centre      FAX         751 814
 [email-masked]     http://WWW.Cranfield.ac.uk/public/cc/cc047/
      "An `alternative paradigm' is the first refuge of the incompetent" --LM

---

From: Andrej Borsenkow <[email-masked]>
Date: Wed, 15 Nov 1995 18:20:34 +0300 (EET)

> on rewriting (in a to or cc field) "foo" as "foo@userdomain".

I strongly support this and would like to put it on the wish list.

  It should be possible to suppress adding the local domain to every
  unqualified address (also in From: header).

  It should be run-time
  configurable (how am I supposed to recompile LWP Pine?)

It not only the problem mentioned in original message. We have internal 
mail system which doesn't use domains at all (in Internet sense). Every 
message gets my local host name tacked on. It is possible to modify 
sendmail to get around, but it requires additional lookups which slow 
down sendmail (as name space is somewhat large).
 
> for the To and Cc (and Bcc) fields then for the From field.

Is it really neccessary? Either user is local and don't need domain at
all, or user is remote and already have domain in any case. 

----------------------------------------------------
Andrej Borsenkow        E-Mail: [email-masked]
SNI ITS, Moscow         Phone:  +7 (095) 252 13 88
----------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 15 Nov 1995 20:26:09 -0800

The brief answer is:

	An email address without an "@domain" is in violation of
	RFC-821, RFC-822, and other email specifications.  Pine
	complies with these specifications.

-- Mark --

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.

---

From: Andrej Borsenkow <[email-masked]>
Date: Thu, 16 Nov 1995 14:12:58 +0300 (EET)

>From rfc822:

          Some message systems may  store  messages  in  formats  that
     differ  from the one specified in this standard.  This specifica-
     tion is intended strictly as a definition of what message content
     format is to be passed BETWEEN hosts.

     Note:  This standard is NOT intended to dictate the internal for-
            mats  used  by sites, the specific message system features
            that they are expected to support, or any of  the  charac-
            teristics  of  user interface programs that create or read
            messages.

rfc821 per definition specifies ONLY interaction BETWEEN hosts.

How mail is presented to local MTA is LOCAL matter, so far as message 
leaves the site properly formatted.

If you insist on always having domain, just tell it your sendmail :-)

---

From: [email-masked] (Frank Peters)
Date: 16 Nov 1995 11:35:34 -0600

> 	complies with these specifications.

But it is the responsibility of the MTA (sendmail or the like) to
enforce this, not the MUA.

At the very least you should include the option of leaving this up to
the MTA.
-- 
  Frank Peters - UNIX Systems Group Leader - Mississippi State University
          [email-masked] - 601-325-7030 - FAX: 601-325-8921
                  <URL:http://www2.msstate.edu/~fwp/>

---

From: Mark Crispin <[email-masked]>
Date: Thu, 16 Nov 1995 19:24:44 -0800

> enforce this, not the MUA.

Pine is also an SMTP client, and as such is an MTA.

> At the very least you should include the option of leaving this up to

It has been shown, many times over the years, that this does not work.
This idea is not new.  It was popular about 15 years ago.  It created many
ongoing problems.

Unqualified addresses that are generated by other mailers cause more bug
reports due to these problems -- which are out of our control -- that we
get about the generation of fully qualifed addresses.

An MTA which is smart enough to rewrite addresses to suit local site
policy can also be made smart enough to accept fully-qualified addresses
as input.

Ask yourself if you would rather fix your smart MTA to be a little bit
smarter so it can rewrite fully-qualified addresses, or if you would
prefer to get more messages from outside with unqualified addresses that
your smart MTA rewrites with its best (but often wrong) guess of the right
thing.

-- Mark --

---

From: Rahul Dhesi <[email-masked]>
Date: 17 Nov 1995 08:22:47 GMT

In <loo-oo-ong-message-id> Mark Crispin <[email-masked]> writes:

>smarter...or if you would
>prefer to get more messages from outside with unqualified addresses...

An interesting dichotomy, as presented above.

I am intrigued by the idea that making one's local MTA smarter
suddenly causes everybody else to stop generating bad addresses.
-- 
Rahul Dhesi <[email-masked]>
"please ignore Dhesi" -- Mark Crispin <[email-masked]>

---

From: Rahul Dhesi <[email-masked]>
Date: 17 Nov 1995 08:18:05 GMT

>	complies with these specifications.

RFC-822 is clearly intended to apply to messages that go across a
network.  It does not apply to the message that pine feeds to an MTA on
the current host.

There is no requirement that pine be RFC-821-conforming.  Since all
known MTAs will accept mail via SMTP for delivery to a local mailbox
without requiring domain format, we conclude that:

   Pine behaves the way it does because that's how its authors want it
   to behave.  This has nothing to do with RFCs.

---

From: [email-masked] (Jerry Lynch)
Date: 18 Nov 1995 12:45:03 -0500

On Thu, 16 Nov 1995, Mark Crispin wrote:

> [snip]

Well, I guess my response to this would be either a compile-time option, 
or a configuration option to suppress "@userdomain".  If the default is 
to include "@userdomain", then theoretically, only those administrators who 
know that their MTA (such as sendmail) will take care of adding 
"@userdomain" would configure pine to omit it.

Although it would be nice if all MTAs would handle this situation, the 
facts are that most don't (based on my limited experience).  The other 
unfortunate reality, is that getting the makers of an MTA to make a 
change to handle a quirk about one MUA (ie. pine) is not always the 
easiest thing to do.

But despite this "drawback" of pine, I still think it's the best MUA out 
there.  (And I do know how to get sendmail's USERDB to work with pine if 
anyone is interested.)

Jerry <[email-masked]>

---

From: Mark Crispin <[email-masked]>
Date: Sat, 18 Nov 1995 11:47:09 -0800

> "@userdomain" would configure pine to omit it.

It's rather more complicated than that.  Besides the user interface
question (how is J. Random User supposed to know the "right" setting?)
there would be a significant amount of code that needs to be changed.  The
concept of "not having a host name in an email address" simply does not
exist in the code.  That concept would have to be created, probably by
having a special host name that really isn't a host name.

There are further implications of this for POP and IMAP.  How is an absent
host name treated for data which resides on a different machine, given
that POP or IMAP servers are not necessarily in the same mailbox name
cluster as the client?

If you review the header-people archives from the late 1970s and early
1980s, this was a very controversial issue.  But the final concensus that
emerged was "death to unqualified addresses".  There were just too many
things that didn't work.

> facts are that most don't (based on my limited experience).

The interpretation of this is that Pine is asked to trust an MTA that is
demonstrably not smart enough to be smart enough, and that furthermore a
user (or site admin), most of whom would *not* understand the technical
issues involved, is asked to judge whether or not this configuration would
work properly.

In turn, we are asked to add a feature that, when misapplied, would make
Pine substantially less robust.  As matters stand now, Pine works.  It may
not exploit a feature of a minority of MTAs, but it isn't broken either.

> The other

Yet, the designers of these MTAs are making the assumption that all MUAs
are old software designed to a mid-1970s idea of how "local vs. ARPAnet
mail" work.  How can you say that "strict conformance to RFC 822" is a
"quirk about one MUA"?

My undertanding is that (at least in the case of sendmail) the MTA
designers just didn't consider the possibility of an MUA doing things
"right", or thought that those MUAs would not need USERDB.  In other
words, it's an oversight, not design.

Please understand that we're not saying you shouldn't use USERDB.  It's a
nice feature.  Given that you have sources for both the MUA and the MTA in
question, you can do it yourself without cooperation from the designers of
either.  But from an engineering standpoint, wouldn't it make more sense
to fix the MTA?  It shouldn't hurt the MTA in any way; but the MUA's
designers have (what they feel to be) excellent reasons to feel that it
would hurt the MUA.

As far as "easy to do", it's not easy to ask us to add a feature that we
know will be easily misued, and will cause improper performance and
generate bug reports when misused.  We get too many bug reports every day
as it is -- we'd like to reduce the incoming flow, thankyousir!!!

> there.  (And I do know how to get sendmail's USERDB to work with pine if

Thanks for the compliments, and it may be valuable to post your technique
to the net.  If that technique involves "how to change sendmail so that
USERDB works with Pine" as opposed to "how to change Pine to work with
unmodified sendmail USERDB", we may add your description of the technique
to our technical notes.  We'd also ask our friends the sendmail designers
to make that change standard in the next version of sendmail.  From what I
know about the sendmail designers, they would be sympathetic to our
position and happy to cooperate if it doesn't cause them problems.

-- Mark --