Fully-qualifying Email addresses in outgoing mail

Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

(I realize this is not specifically a Gnus question, but I figure the
people on this list are the most likely to know.)

We use qmail, whose SMTP daemon does not do any kind of header
munging.

We have users running Emacs on Windows, who therefore must use
smtpmail.

Consequently, their Email tends to have bare addresses (e.g., "foo"
instead of "foo@bar.com") in the headers.  This causes all sorts of
subtle and annoying problems.

My question is, does anyone have ideas for how I should deal with this
problem?  I guess what I want is for smtpmail to do a bunch of checks
on the headers before sending the message.  But since message-mode
already does the checks itself, perhaps one could be added which
fully-qualifies outgoing Email addresses?

Thanks in advance for any suggestions.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Per Abrahamsen]

patl@cag.lcs.mit.edu (Patrick J. LoPresti) writes:

> But since message-mode
> already does the checks itself, perhaps one could be added which
> fully-qualifies outgoing Email addresses?

(setq mail-host-address "cag.lcs.mit.edu")

Or did I misunderstood the problem?

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> (setq mail-host-address "cag.lcs.mit.edu")
> 
> Or did I misunderstood the problem?

This takes care of the problem for "From" line generation, but it does
not affect what appears in the "To" and "CC" headers.

When a user provides "To: patl" in the header, message-mode does no
manipulation of that at all (as far as I can tell).  It simply passes
it off as-is to the message-send-mail-function.

When that function is 'message-send-mail-with-qmail, all is well
because qmail-inject performs all sorts of canonicalization on the
message: It inserts Date and Message-ID headers (if needed); it fully
qualifies all Email addresses; and so on.

But when you use 'smtpmail-send-it, the message goes straight to the
smtp daemon which performs no canonicalizations of any kind.  For
headers like Date and Message-ID, this is OK, because message-mode has
already fixed those up as required.  But for "To" and "CC", this is
problematic for two reasons: 1) The unqualified addresses are
processed by the smtp *host*, which is not the right thing at all; and
2) the unqualified addresses appear in the recipient's copy of the
message, which is also broken.

I am pretty sure what I need is for message-mode to be able to
canonicalize the To and CC fields, in the same way it performs other
checks on the message.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Kai Großjohann]

patl@cag.lcs.mit.edu (Patrick J. LoPresti) writes:

> But when you use 'smtpmail-send-it, the message goes straight to the
> smtp daemon which performs no canonicalizations of any kind.

Why doesn't the smtp daemon do canonicalizations?  IMHO any smtp
daemon which does not convert local addresses to qualified addresses
when sending a message to another host is not configured correctly.

Suppose a user does this?

    $ telnet localhost smtp
    HELO myname
    MAIL FROM: <kai>
    RCPT TO: <peter>
    RCPT TO: <karl@cs.uni-helgoland.de>
    DATA
    To: peter, karl@cs.uni-helgoland.de
    From: kai
    Subject: Good Morning

    Good morning, Peter and Karl!
    Kai
    .

Shouldn't the smtp daemon on localhost convert `peter' into
`peter@myname.mydomain.de' before sending the message to
karl@cs.uni-helgoland.de? 

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: Fully-qualifying Email addresses in outgoing mail

[Kai Großjohann]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Why doesn't the smtp daemon do canonicalizations?  IMHO any smtp
> daemon which does not convert local addresses to qualified addresses
> when sending a message to another host is not configured correctly.

Argh.  Silly me :-(  RFC 822 explicitly specifies that all addresses
must be of the form `user@host', and `user' is not allowed.

Sorry for the line noise.

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Argh.  Silly me :-(  RFC 822 explicitly specifies that all addresses
> must be of the form `user@host', and `user' is not allowed.

Right, because the SMTP server may be in a domain which is unrelated
to the client's.  The qmail author is pretty anal about wanting the
"right" tool to do each job in Email delivery...  So again, I suggest
that it would be nice if message-mode had an option to canonicalize
addresses in outgoing mail.

Comments?

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999
| Comments?

If I understand what you want, I think what you want is broken.  It is
critically important to remember two things:

First, an RFC 822 mailbox has absolutely no relationship whatsoever with
the machine on which the message is composed or from what machine it is
submitted to the MTA.

Second, a local mailbox is completely bound to the local machine.

If I have `To: ratinox', the message should be delivered locally because
that is what I have told my local MTA to do.  If it is rewritten for
canonicity with a complete domain part, then the message would be sent out
to my MX host where I would have to grab it via POP.  That is, assuming
that the guess is in fact correct, which given "thing First" is impossible
to do with 100% accuracy.

This is not something unique to qmail, by the way.  To and Cc should never
be rewritten.  If qmail-inject is rewriting To and Cc mailboxes, it is
doing something wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UTbJgl+vIlSVSNkRAh3kAKDpdghd3gERGn8KOO1Hyrha3603TgCferHs
GNthW64AJ1Bx35pntGXIxAc=
=YJGy
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not use Happy Fun Ball on concrete.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> If I understand what you want, I think what you want is broken.  It is
> critically important to remember two things:
> 
> First, an RFC 822 mailbox has absolutely no relationship whatsoever with
> the machine on which the message is composed or from what machine it is
> submitted to the MTA.

Yes.

> Second, a local mailbox is completely bound to the local machine.

No.

> If I have `To: ratinox', the message should be delivered locally because
> that is what I have told my local MTA to do.

So a user composing mail on a Windows laptop, which has no message
queue, must type in a fully-qualified name every time?  Of course not.
If you type a name which is not fully-qualified, it is the system's
job to figure out what you mean.  That may or may not mean a mailbox
on the local system.  People working at FooCorp expect that "bozo"
will be converted into "bozo@foo.com".  And the RFCs say such a
conversion must happen before anything is sent via SMTP.

(The reason for this is obvious: Recipients in foreign domains need to
see fully-qualified addresses or they can't follow-up.)

> If it is rewritten for canonicity with a complete domain part, then
> the message would be sent out to my MX host where I would have to
> grab it via POP.

Which would be superior behavior for almost all users.  And I am
suggesting this as an option, not a requirement.

> This is not something unique to qmail, by the way.  To and Cc should never
> be rewritten.  If qmail-inject is rewriting To and Cc mailboxes, it is
> doing something wrong.

Do you agree that bare addresses must not appear in a SMTP message, as
the RFC specifies?  So it is a *bug* that message-mode/smtpmail (blame
whichever you like) generates SMTP messages with such addresses in
them.  I am requesting a way to avoid this buggy behavior.  One option
would be for smtpmail to refuse to send such messages; I am suggesting
something more useful.

Note that sendmail rewrites the addresses whether you invoke it from
the command line or talk to it via smtp.  The latter is the only
reason smtpmail.el works at all.

Qmail (correctly) only rewrites addresses when you invoke it on the
command-line.  This behavior is configurable, of course.

I think it is quite unlikely that both sendmail and qmail-inject are
"doing something wrong" in their default configurations.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

I wrote:

> So a user composing mail on a Windows laptop, which has no message
> queue, must type in a fully-qualified name every time?

Er, I meant "...which has no local mailboxes...".  Sorry.

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999
| > Second, a local mailbox is completely bound to the local machine.
| No.

Yes.  An Internet mailbox has a fully qualified domain part.  If the
mailbox has no fully qualified domain part, it cannot be an Internet mail
message.  It must be a local message because there is nothing else it could
be (I'm leaving things like X.400 out of it).

| So a user composing mail on a Windows laptop, which has no message
| queue, must type in a fully-qualified name every time?  Of course not.

That's what address books are for.

| If you type a name which is not fully-qualified, it is the system's job
| to figure out what you mean.  That may or may not mean a mailbox on the
| local system.  People working at FooCorp expect that "bozo" will be
| converted into "bozo@foo.com".  And the RFCs say such a conversion must
| happen before anything is sent via SMTP.

How do you intend to make this work reliably?  I have a machine that can
receive local mail just fine, but not network mail because it does not have
a full-time network connection.  For that I have a couple of MX records so
that network mail gets delivered to machines that have full-time network
connections.  `ratinox' and `ratinox@peorth.gweep.net' do *NOT* resolve to
the same mailbox.  By forcibly qualifying `ratinox' with a domain part, you 
ensure that the message gets delivered to the wrong mailbox.

| (The reason for this is obvious: Recipients in foreign domains need to
| see fully-qualified addresses or they can't follow-up.)

You have just switched gears.  To and Cc should never be rewritten for
canonicity, but because the user is sending to a foreign domain a fully
qualified domain part must exist in the To or Cc headers, so rewriting is
not necessary.

From, on the other hand, should always be rewritten for canonicity if it is
required.  But that is not what you were asking about before.

| > If it is rewritten for canonicity with a complete domain part, then
| > the message would be sent out to my MX host where I would have to
| > grab it via POP.

| Which would be superior behavior for almost all users.  And I am
| suggesting this as an option, not a requirement.

But it would still be wrong because I specified that the message be
delivered locally.

And by the way, the BBDB has mailbox completion.

[...]
| Do you agree that bare addresses must not appear in a SMTP message, as
| the RFC specifies?

Just to keep the terminology straight, it is an RFC 822 message.  SMTP is
RFC 821 (et al) and defines *how* a message gets from one machine to
another, not the format of the message.  RFC 822 defines the format of an
Internet mail message.  It says nothing about other mail message formats.

And yes, unqualified mailboxes are invalid in an RFC 822 message.  But a
message to be delivered to `patl' is *not* an RFC 822 (Internet mail)
message, as I pointed out before.

[...]
| Note that sendmail rewrites the addresses whether you invoke it from
| the command line or talk to it via smtp.  The latter is the only
| reason smtpmail.el works at all.

sendmail does not rewrite To or Cc.

| Qmail (correctly) only rewrites addresses when you invoke it on the
| command-line.  This behavior is configurable, of course.

Then qmail does the wrong thing by turning a local message into an Internet
message.  Adding qmail's brokenness to message will break message-mode.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UU+qgl+vIlSVSNkRAu9GAKDUNZ5ggzTQEbj2ei5uZ24EadPTtwCdFCHl
K33RJooDKSQzCkSnKND+Nvs=
=ZMWc
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Do not taunt Happy Fun Ball.
Minion of Nathan - Nathan says Hi! \ 
PGP Key: at a key server near you!  \ 

Re: Fully-qualifying Email addresses in outgoing mail

[Kai Großjohann]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> If I have `To: ratinox', the message should be delivered locally because
> that is what I have told my local MTA to do.  If it is rewritten for
> canonicity with a complete domain part, then the message would be sent out
> to my MX host where I would have to grab it via POP.  That is, assuming
> that the guess is in fact correct, which given "thing First" is impossible
> to do with 100% accuracy.

Do you think this should only happen when calling a program like
/bin/mail (or mailx, or sendmail), or should it also happen when you
issue `RCPT TO: <ratinox>' to an SMTP server?

kai
-- 
A preposition is not a good thing to end a sentence with.

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Yes.  An Internet mailbox has a fully qualified domain part.  If the
> mailbox has no fully qualified domain part, it cannot be an Internet mail
> message.  It must be a local message because there is nothing else it could
> be (I'm leaving things like X.400 out of it).

Right, and approximately zero people ever send an Email message which
they do not intend as an Internet mail message.

> | So a user composing mail on a Windows laptop, which has no message
> | queue, must type in a fully-qualified name every time?  Of course not.
> 
> That's what address books are for.

Great.  So a new entry must be added to every address book for every
new account?  Absurd.

Almost all people compose Email as members of an organization, not as
users of a particular machine.  They expect Email to "bob" to mean
"bob in my organization", not "bob on this computer".  A laptop MUA
which interprets it in the former way is *not* broken; quite the
contrary.

> How do you intend to make this work reliably?  I have a machine that
> can

[snip]

The same way "From" lines work reliably.  An unadorned name means
"in my default domain".

> | (The reason for this is obvious: Recipients in foreign domains need to
> | see fully-qualified addresses or they can't follow-up.)
> 
> You have just switched gears.  To and Cc should never be rewritten for
> canonicity, but because the user is sending to a foreign domain a fully
> qualified domain part must exist in the To or Cc headers, so rewriting is
> not necessary.

No!!!  This is the crux of the entire problem; you are forgetting
about multiple recipients.  Suppose I work at FooCorp.  If I address a
message to both "myboss" and "bigshot@bar.com", Mr. Bigshot cannot
follow-up properly unless somebody somewhere canonicalizes "myboss"
into "myboss@foo.com".  The obvious place for this to happen is in the
MUA; how the hell are the SMTP daemons supposed to know whether and
how to do this job?

> | Which would be superior behavior for almost all users.  And I am
> | suggesting this as an option, not a requirement.
> 
> But it would still be wrong because I specified that the message be
> delivered locally.

No, you did not specify anything at all, and you are insisting
(erroneously) that this must mean "deliver locally".  Approximately
nobody means that when they use unqualified addresses.

> And by the way, the BBDB has mailbox completion.

Only useful if I can have it complete on ALL names, not just the ones
in bbdb.

> | Do you agree that bare addresses must not appear in a SMTP message, as
> | the RFC specifies?
> 
> Just to keep the terminology straight, it is an RFC 822 message.  SMTP is
> RFC 821 (et al) and defines *how* a message gets from one machine to
> another, not the format of the message.  RFC 822 defines the format of an
> Internet mail message.  It says nothing about other mail message formats.
> 
> And yes, unqualified mailboxes are invalid in an RFC 822 message.  But a
> message to be delivered to `patl' is *not* an RFC 822 (Internet mail)
> message, as I pointed out before.

So it must *not* be delivered with SMTP.  Again, message-mode/smtpmail
are buggy if they ever try to deliver such a message.

> [...]
> | Note that sendmail rewrites the addresses whether you invoke it from
> | the command line or talk to it via smtp.  The latter is the only
> | reason smtpmail.el works at all.
> 
> sendmail does not rewrite To or Cc.

Wrong.  Of course sendmail rewrites recipient addresses, because
otherwise everyone would have the same problems with multiple
recipients that we are having (see above).

> | Qmail (correctly) only rewrites addresses when you invoke it on the
> | command-line.  This behavior is configurable, of course.
>
> Then qmail does the wrong thing by turning a local message into an
> Internet message.  Adding qmail's brokenness to message will break
> message-mode.

Providing the most useful functionality to users is never "broken".
Can you quote any standards document at all which says unqualified
addresses are the same as specifying the local machine?  A different
interpretation is vastly more useful to everyone except for you.  And
I am merely suggesting that the other interpretation should be offered
as an option.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

I guess I get to answer my own question.

>From the qmail FAQ, in response to the question "How do I fix up
messages from dumb clients?", there is a procedure for configuring
qmail-smtpd to do the same broken header-rewriting that sendmail does:
  
  http://cr.yp.to/qmail/faq/servers.html#network-rewriting

So I guess message-mode/smtpmail can stay just as broken as other SMTP
clients.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Then qmail does the wrong thing by turning a local message into an
> Internet message.  Adding qmail's brokenness to message will break
> message-mode.

Sorry for following up again, but you are wrong for so many reasons
that I forgot to mention one.

Qmail is an *Internet* mail delivery agent; it is an error to use
qmail-inject to process any other kind of message.  As the entry point
to Internet mail delivery, qmail-inject ensures that the messages it
outputs are compliant with RFC 822.  It also takes some non-standard
messages (e.g., those lacking a Message-ID) and fixes them up to be
compliant.  This is hardly "broken"; it is a natural (and obvious, and
useful) consequence of injecting your message for Internet mail
delivery.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann)  on Fri, 10 Dec 1999
| Do you think this should only happen when calling a program like
| /bin/mail (or mailx, or sendmail), or should it also happen when you
| issue `RCPT TO: <ratinox>' to an SMTP server?

Here is a hopefully not very contrived example.  I am the admin of just one
machine within a larger domain.  The domain has a wildcard MX record, so
all network mail is delivered to a central mail hub, a machine I do not
have root access on.  So of course I want root's mail to be delivered
locally on my machine.  But if `root' is expanded with a fully-qualified
domain part, it will fall to the MX lookup for delivery, which will cause
my errors to be delivered to the site's mail hub.  Bad.

It gets really hairy if you happen to have an "illegally owned" domain
behind a firewall (there are a lot of them out there).  If you expand the
To mailbox to include the domain, it becomes impossible to tell whether to
deliver the message to the internal mail hub or the real domain's hub.

So to finally answer the question, local mailboxes should not be expanded.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UWlzgl+vIlSVSNkRArbZAKDY37ZqjVGmQ4tHcOQVERmgrX8okQCfVVrg
dcGUGL9wvc9Q+Qv1++Y/K2w=
=ynZP
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Here is a hopefully not very contrived example.  I am the admin of just one
> machine within a larger domain.  The domain has a wildcard MX record, so
> all network mail is delivered to a central mail hub, a machine I do not
> have root access on.

Sure, having no control of your system's MX record *and* wanting to
receive mail there is the NORM!  No other configuration should even be
supported.  What was I thinking?

> So to finally answer the question, local mailboxes should not be expanded.

It would be useful to 99.9% of all users, but not to you, so it should
not be offered as an option.  Very sensible.  Thanks for your help.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999
| Qmail is an *Internet* mail delivery agent;

No, it is a mail transport agent (MTA) that speaks simple mail transfer
protocol (SMTP).

| it is an error to use qmail-inject to process any other kind of message.
| As the entry point to Internet mail delivery, qmail-inject ensures that
| the messages it outputs are compliant with RFC 822.

Rewriting headers of an RFC 822 message for canonicity is a good thing.
But if a message is not an RFC 822 message, qmail-inject has absolutely no
grounds for turning it into an RFC 822 message.  And even then, rewriting
To and Cc is a Really Bad Idea because it can and eventually will cause
mail not to be delivered properly (see my response to Kai's message for
some details).

Now, if qmail cannot cope with non-RFC 822 messages, you need to have
another MTA around to deal with those messages.

Still and all, if rewriting To and Cc is really what you want to do, then I 
think that writing a qmail-inject program in Emacs-Lisp and hooking it into 
smtpmail (or replacing it outright) is a better solution than breaking
message-mode for everyone who does not use qmail, yes?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UXidgl+vIlSVSNkRAn03AJ9lVbdJf1bOw5A8FZH8GgHYjzaY+QCg3N8J
IezJIFoI9Jum7/wohBuoQn4=
=vj/6
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 

Re: Fully-qualifying Email addresses in outgoing mail

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> No, it is a mail transport agent (MTA) that speaks simple mail transfer
> protocol (SMTP).

qmail-inject is not an MTA and it does not speak SMTP.

> Rewriting headers of an RFC 822 message for canonicity is a good thing.
> But if a message is not an RFC 822 message, qmail-inject has absolutely
> no grounds for turning it into an RFC 822 message.

If you pass a message to qmail-inject, you're telling it that you want it
to turn it into an RFC 822 message and then inject it into qmail's queue.

> And even then, rewriting To and Cc is a Really Bad Idea because it can
> and eventually will cause mail not to be delivered properly (see my
> response to Kai's message for some details).

qmail-inject is a piece of an MUA, specifically the bit that takes
potentially unqualified and incomplete local mail and turns it into RFC
822 mail.  If you don't want your message to be canonicalized according to
the rules that it applies, don't pass it to qmail-inject.  qmail only does
message rewriting if you explicitly use the interface that is documented
to rewrite messages, namely qmail-inject.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Fully-qualifying Email addresses in outgoing mail

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999

> | Note that sendmail rewrites the addresses whether you invoke it from
> | the command line or talk to it via smtp.  The latter is the only
> | reason smtpmail.el works at all.

> sendmail does not rewrite To or Cc.

Um...  sendmail even rewrites To and Cc headers it gets via SMTP.
sendmail is horribly broken in this regard.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999
| Sure, having no control of your system's MX record *and* wanting to
| receive mail there is the NORM!  No other configuration should even be
| supported.  What was I thinking?

It is common practice to give contractors very limited system access, only
as much as they require to do their jobs, no more.  When I had a ClearCase
contractor in a couple of months ago, I gave him root on the ClearCase view
server because he needed it, and that is where people could send him mail
while he was working for us.  I sure as Hell did not give him access to my
name servers or mail hubs.

| It would be useful to 99.9% of all users, but not to you, so it should
| not be offered as an option.  Very sensible.  Thanks for your help.

I would like to know where you get your numbers.  Where I work we have 300
employees, about 1/3 of which use local mail on our development systems.  I
do not really consider my slice of the world to be statistically useful,
but 100 people is more than the "zero" you previously stated use local
mail.  So I think I have good reason not to go breaking local mail delivery
simply because you think *all* mail must be Internet mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UXvggl+vIlSVSNkRAuxnAJ9tYYmSeAdOCPCUjVipgyw/jjNGkwCgn/lr
JOIFyROJH0lFFGWVbza/H/4=
=6+F5
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Russ Allbery <rra@stanford.edu>  on Fri, 10 Dec 1999
| qmail-inject is not an MTA and it does not speak SMTP.

Patrick wrote that qmail, not qmail-inject, is a mail delivery agent, which 
it is not.  qmail is exactly what I described it being.

[...]
| If you pass a message to qmail-inject, you're telling it that you want it
| to turn it into an RFC 822 message and then inject it into qmail's queue.

If qmail or qmail-inject cannot handle anything but Internet mail messages,
you need another MTA to deal with local mail, and possibly a third or more
to deal with other network mail you might have, such as UUCP or X.400.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UX2kgl+vIlSVSNkRAox0AJ42diEKlHH2soBtGMq7OdaeeRBIFwCeLEid
KWrK7Kn9H0fc9rKOewERKKQ=
=UFEb
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Caution: Happy Fun Ball may suddenly
Minion of Nathan - Nathan says Hi! \ accelerate to dangerous speeds.
PGP Key: at a key server near you!  \ 

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Russ Allbery <rra@stanford.edu>  on Fri, 10 Dec 1999
| Um...  sendmail even rewrites To and Cc headers it gets via SMTP.
| sendmail is horribly broken in this regard.

Hmmm... I'll be damned, and you are right on both counts.  Well, v8 sendmail
does, anyway.  I do not have immediate access to a v5 sendmail to compare.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UX8Dgl+vIlSVSNkRAiVSAJ4s7rJjc7OJRDiRqB7De9PQsJzhEgCeNBIA
rf/ATh7PpdyDzMWVyccCJXw=
=pGv4
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.

Re: Fully-qualifying Email addresses in outgoing mail

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Patrick wrote that qmail, not qmail-inject, is a mail delivery agent,
> which it is not.  qmail is exactly what I described it being.

Yes and no; that was part of the point that I was trying to make.  qmail
is a large suite of programs.  Some of them implement an SMTP MTA; other
programs in that suite do other things.  When it comes to things like
message rewriting, saying that "qmail" does something is very inspecific
and can be somewhat misleading.

> If qmail or qmail-inject cannot handle anything but Internet mail
> messages, you need another MTA to deal with local mail, and possibly a
> third or more to deal with other network mail you might have, such as
> UUCP or X.400.

Yup, we're agreed there.  qmail by design deals only with Internet mail.
You can make various local mail conventions work, but qmail was not
designed for them and will generally make them look very SMTP-like.
Similarly for UUCP.

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> It is common practice to give contractors very limited system
> access, only as much as they require to do their jobs, no more.

Yes, I think you have made it clear that the functionality I suggest
would not be useful to you.

> | It would be useful to 99.9% of all users, but not to you, so it should
> | not be offered as an option.  Very sensible.  Thanks for your help.
> 
> I would like to know where you get your numbers.

Think about it for 2 seconds, and you will find it obvious that *the
vast majority of systems do not have local mail delivery at all*.
Every box running Windows 9x, for example.  Almost every box running
NT.  Remember that wildcard MX record you mentioned earlier?  Gee, I
wonder why it was set up that way.

In a well-administered network, almost none of the Unix boxes do mail
delivery, either.  Email to "root" goes to the administrator of the
*network*.  See?

> Where I work we have 300 employees, about 1/3 of which use local
> mail on our development systems.

That sounds like a poorly-administered disaster.

> I do not really consider my slice of the world to be statistically
> useful, but 100 people is more than the "zero" you previously stated
> use local mail.

Compared to the world of Windows users, it's zero.  (And yes, the
whole point of this exercise from my point of view are the people
running Emacs on win32.  The Unix users just invoke qmail-inject.)

> So I think I have good reason not to go breaking local mail delivery
> simply because you think *all* mail must be Internet mail.

Yes, you do, because you are one of those unusual users for whom there
exists local mail delivery to break.

Did I forget to mention that I am suggesting an *option*?  That means
it would be optional.  That means you could opt out.  That means you
would not have to use it.

I agree that smtpmail itself might be a better place to fix this,
since it does not presently send valid SMTP mail.  But since
message-mode can already perform a variety of RFC822 canonicalizations
(like adding From, Message-ID, and Date), it is not much of a stretch
to throw another into the mix.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999
> | Qmail is an *Internet* mail delivery agent;
> 
> No, it is a mail transport agent (MTA) that speaks simple mail transfer
> protocol (SMTP).

Blah blah blah.  Fine.  I should have said, "Qmail is an Internet mail
system."  It is a collection of programs for handling Internet mail.
qmail-inject is one of those programs; no, it does not speak SMTP,
because that is a different program's job.

All of which affects the point not at all.  The operative term was
"Internet"; sorry I didn't emphasize it.  Oh, wait, I did.

> Rewriting headers of an RFC 822 message for canonicity is a good thing.
> But if a message is not an RFC 822 message, qmail-inject has absolutely no
> grounds for turning it into an RFC 822 message.  And even then, rewriting
> To and Cc is a Really Bad Idea because it can and eventually will cause
> mail not to be delivered properly (see my response to Kai's message for
> some details).

sendmail does so EVEN FOR SMTP MESSAGES, which is broken blah blah
blah oh I give up.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Patrick J. LoPresti]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Russ Allbery <rra@stanford.edu>  on Fri, 10 Dec 1999
> | Um...  sendmail even rewrites To and Cc headers it gets via SMTP.
> | sendmail is horribly broken in this regard.

> Hmmm... I'll be damned, and you are right on both counts.  Well, v8
> sendmail does, anyway.  I do not have immediate access to a v5
> sendmail to compare.

Of course he's right, because he restated what I have said from the
beginning.

sendmail has always been broken like this.  And now that Outlook and
Netscape and Eudora and MH and every other piece-of-sh** MUA are
broken in a complementary way, every MTA ever written until the end of
time will need to be similarly broken.

I was thinking maybe Emacs+message-mode+smtpmail could provide a
non-broken MUA, but what would be the point, really, I guess.

 - Pat

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* patl@cag.lcs.mit.edu (Patrick J. LoPresti)  on Fri, 10 Dec 1999
| sendmail has always been broken like this.

I just tested the two sendmail hubs where I work.  One is v8 (8.9.1b+Sun),
the other is an ancient and much patched 5.56.  Neither expand local
mailboxes.  So no, sendmail has not always been broken like this, and my
original statement was correct (or at least not entirely wrong :).

[dig-dig-dig]

always_add_domain is a feature that some vendors, like Red Hat, include
with their sendmail distribution, which is what I used to test Russ's
claim.  nocanonify is an opposing feature that some other vendors, like
Sun, include with their sendmail distribution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4UcBzgl+vIlSVSNkRAnXqAKC1gtj3af/odmpqjAowDzA4FJmwywCdG5aI
S1g7EOKZNEj83jj3Iw9SC3s=
=9ppB
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ Warning: pregnant women, the elderly, and
Minion of Nathan - Nathan says Hi! \ children under 10 should avoid prolonged
PGP Key: at a key server near you!  \ exposure to Happy Fun Ball.

Re: Fully-qualifying Email addresses in outgoing mail

[Russ Allbery]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> always_add_domain is a feature that some vendors, like Red Hat, include
> with their sendmail distribution, which is what I used to test Russ's
> claim.  nocanonify is an opposing feature that some other vendors, like
> Sun, include with their sendmail distribution.

Pass it a fully-qualified address on the To: header whose RHS is a CNAME
and see what you get out the other side.  Does nocanonify prevent that
pointless munging too?

-- 
Russ Allbery (rra@stanford.edu)         <URL:http://www.eyrie.org/~eagle/>

Re: Fully-qualifying Email addresses in outgoing mail

[Per Abrahamsen]

patl@cag.lcs.mit.edu (Patrick J. LoPresti) writes:

> I agree that smtpmail itself might be a better place to fix this,
> since it does not presently send valid SMTP mail.  But since
> message-mode can already perform a variety of RFC822 canonicalizations
> (like adding From, Message-ID, and Date), it is not much of a stretch
> to throw another into the mix.

However, smtpmail is also used by the other Emacs mailers, so adding
it there would fix them all.  Also, smtpmail can be viewed as a Emacs
Lisp equivalent to qmail-inject, so it is also the logical place for
the functionality. 

I believe the required header parsing routines are already separated
out in a library which smtpmail can use.

Re: Fully-qualifying Email addresses in outgoing mail

[Amos Gouaux]

>>>>> On 11 Dec 1999 12:44:16 +0100,
>>>>> Per Abrahamsen <abraham@dina.kvl.dk> (pa) writes:

pa> However, smtpmail is also used by the other Emacs mailers, so adding
pa> it there would fix them all.  Also, smtpmail can be viewed as a Emacs
pa> Lisp equivalent to qmail-inject, so it is also the logical place for
pa> the functionality. 

pa> I believe the required header parsing routines are already separated
pa> out in a library which smtpmail can use.

My, what a thread.  What if there's an option to add a domain part
to unqualified addresses?  I've seen this in many MUAs.  In fact on
our campus we build the Mulberry installer to do this, for the very
reasons that Pat describes.  At least for us, this has worked out
very well.  The main MX host then knows what inbox server that
individual is using.

Amos

Re: Fully-qualifying Email addresses in outgoing mail

[Stainless Steel Rat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Russ Allbery <rra@stanford.edu>  on Fri, 10 Dec 1999
| Pass it a fully-qualified address on the To: header whose RHS is a CNAME
| and see what you get out the other side.

I only tested with unqualified addresses to see if they would be expanded
with fully-qualified domain parts.  They were not.

| Does nocanonify prevent that pointless munging too?

I believe that it does, yes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0g (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4U8Vbgl+vIlSVSNkRAj6zAKD9TEM62a7gu9TUNAkcBgrlVo+40gCg6LLn
WV3CYEmcCQ6vkUAoalcCZ60=
=+BK5
-----END PGP SIGNATURE-----

-- 
Rat <ratinox@peorth.gweep.net>    \ When not in use, Happy Fun Ball should be
Minion of Nathan - Nathan says Hi! \ returned to its special container and
PGP Key: at a key server near you!  \ kept under refrigeration.