[Gnus 5.2.14] message-make-sender

[Gnus 5.2.14] message-make-sender

[=?ISO-2022-JP?Q?=1B$B<morioka@jaist.ac.jp]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

  I think it is better if function `message-make-sender' check
(system-name) is FQDM. If (system-name) is not FQDM, message.el makes
invalid Sender field.

  IMHO, variable `mail-host-address' is better for mail address. For
example, in my site, we usually don't include machine names in our
mail-addresses.

  Thanks,


[-- Attachment #2: message.el.diff --]
[-- Type: application/octet-stream, Size: 598 bytes --]

--- message.el-orig	Mon Jun 10 12:46:41 1996
+++ message.el	Mon Jun 10 14:58:43 1996
@@ -1954,7 +1954,13 @@
   "Return the \"real\" user address.
 This function tries to ignore all user modifications, and 
 give as trustworthy answer as possible."
-  (concat (user-login-name) "@" (system-name)))
+  (let ((domain (system-name)))
+    (or (string-match "[^.]\\.[^.]" domain)
+	(if (and (boundp 'mail-host-address) mail-host-address)
+	    (setq domain mail-host-address)
+	  ))
+    (concat (user-login-name) "@" domain)
+    ))
 
 (defun message-make-address ()
   "Make the address of the user."

[-- Attachment #3: Type: text/plain, Size: 248 bytes --]

-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

Re: [Gnus 5.2.14] message-make-sender

[Per Abrahamsen]

>>>>> "MT" == Morioka Tomohiko <morioka@jaist.ac.jp> writes:

MT>   IMHO, variable `mail-host-address' is better for mail address. 

`Sender: ' is not a mail address, but rather the user@hostname
combination least likely to be customized/faked.  Thus, it is best to
avoid any of the usual customization variables.

Re: [Gnus 5.2.14] message-make-sender

[=?ISO-2022-JP?Q?=1B$B<morioka@jaist.ac.jp]

>>>>> In <rjbuisui07.fsf@kleene.dina.kvl.dk> 
>>>>>	Per Abrahamsen <abraham@dina.kvl.dk> wrote:

Per> >>>>> "MT" == Morioka Tomohiko <morioka@jaist.ac.jp> writes:

MT>   IMHO, variable `mail-host-address' is better for mail address. 

Per> `Sender: ' is not a mail address, but rather the user@hostname
Per> combination least likely to be customized/faked.  Thus, it is
Per> best to avoid any of the usual customization variables.

  Sender field must include a mail reachable real address. It is used
when mailbox of From field is not senders real address or it contains
multiple mailboxes.

  Even if user@hostname combination least likely to be
customized/faked, system-name is similar. You can set to variable
`system-name'.

  I think system-name and mail-host-address is different concept. In
some environment, (system-name) does not return reachable address, in
particular a machine is in closed network (in fire wall), dial up
environment or non-internet protocols.

  (system-name) and system-name returns machine address,
mail-host-address returns domain of mail address. In major case, they
may be same or (system-name) and system-name may be a mail
reachable. But I think we distinguish them. And Sender field must be
real mail address.

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

Re: [Gnus 5.2.14] message-make-sender

[Per Abrahamsen]

>>>>> "MT" == Morioka Tomohiko <morioka@jaist.ac.jp> writes:

MT>   Sender field must include a mail reachable real address. It is used
MT> when mailbox of From field is not senders real address or it contains
MT> multiple mailboxes.

You are describing the `Reply-To:' header.  The `Sender:' header
should never be used to generate replies.

Re: [Gnus 5.2.14] message-make-sender

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "aj" == =?ISO-2022-JP?Q?=1B$B<morioka@jaist ac jp
>>>>> <morioka@jaist.ac.jp> writes:

aj> Sender field must include a mail reachable real address.

Nope.  From RFC822:

     authentic   =   "From"       ":"   mailbox  ; Single author
                 / ( "Sender"     ":"   mailbox  ; Actual submittor
                     "From"       ":" 1#mailbox) ; Multiple authors
                                                 ;  or not sender
[...]
     4.4.2.  Sender / Resent-Sender
     
        This field contains the authenticated identity  of  the  agent
        (person,  system  or  process)  that sends the message.  It is
        intended for use when the sender is not the author of the mes-
        sage,  or  to  indicate  who among a group of authors actually
        sent the message.  If the contents of the "Sender" field would
        be  completely  redundant  with  the  "From"  field,  then the
        "Sender" field need not be present and its use is  discouraged
        (though  still legal).  In particular, the "Sender" field must
        be present if it is not the same as the "From" Field.

[For instance, a mailing list manager will set the Sender: field because
it is responsible for sending messages but it does not originate
messages. --Rat]

        The Sender mailbox  specification  includes  a  word  sequence
        which  must correspond to a specific agent (i.e., a human user
        or a computer program) rather than a standard  address.   This
        indicates  the  expectation  that  the field will identify the
        single agent (person,  system,  or  process)  responsible  for
        sending  the mail and not simply include the name of a mailbox
        from which the mail was sent.  For example in the  case  of  a
        shared login name, the name, by itself, would not be adequate.
        The local-part address unit, which refers to  this  agent,  is
        expected to be a computer system term, and not (for example) a
        generalized person reference which can  be  used  outside  the
        network text message context.

[In fact, not only does Sender: not need to contain a valid Internet
mail address, it generally should not contain one. --Rat]

        Since the critical function served by the  "Sender"  field  is
        identification  of  the agent responsible for sending mail and
        since computer programs cannot be held accountable  for  their
        behavior, it is strongly recommended that when a computer pro-
        gram generates a message, the human  who  is  responsible  for
        that program be referenced as part of the "Sender" field mail-
        box specification.

[Back to mailing lists, Majordomo sets Sender: to the list owner's
address. --Rat]

aj> It is used when mailbox of From field is not senders real address or
aj> it contains multiple mailboxes.

No, that is the Reply-To: header.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMbwtwJ6VRH7BJMxHAQErjgP/Uz0KqL5jqg0r5eTeoCGZiPtc3pQ+rqV+
Quo3Uxbh6HAEhY3eRHe2BWIXUR9Y2IQjLJh/KML9hctxfwofYyyEKXu4pI4SEEBI
kbp1crqzXgB9Nrxie8sjqovG+15PaFXmZSnCwT71y8DkxINqC2D8hzqvLozmDZyi
VA0bQMjNLyI=
=JpK1
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ When in doubt, cop an attitude. -A cat's
<ratinox@unilab.dfci.harvard.edu>   \ guide to life
http://www.dfci.harvard.edu/         \ 

Re: [Gnus 5.2.14] message-make-sender

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In <x7g283u4ow.fsf@unilab.dfci.harvard.edu> 
>>>>>	Richard Pieri <ratinox@unilab.dfci.harvard.edu> wrote:

Richard> >>>>> "aj" == =?ISO-2022-JP?Q?=1B$B<morioka@jaist ac jp
Richard> >>>>> <morioka@jaist.ac.jp> writes:

aj> Sender field must include a mail reachable real address.

Richard> Nope.  From RFC822:

(snip)

Richard> [For instance, a mailing list manager will set the Sender:
Richard> field because it is responsible for sending messages but it
Richard> does not originate messages. --Rat]

(snip)

Richard>         The Sender mailbox specification includes a word
Richard>         sequence which must correspond to a specific agent
Richard>         (i.e., a human user or a computer program) rather
Richard>         than a standard address.  This indicates the
Richard>         expectation that the field will identify the single
Richard>         agent (person, system, or process) responsible for
Richard>         sending the mail and not simply include the name of a
Richard>         mailbox from which the mail was sent.  For example in
Richard>         the case of a shared login name, the name, by itself,
Richard>         would not be adequate. The local-part address unit,
Richard>         which refers to this agent, is expected to be a
Richard>         computer system term, and not (for example) a
Richard>         generalized person reference which can be used
Richard>         outside the network text message context.

Richard> [In fact, not only does Sender: not need to contain a valid
Richard> Internet mail address, it generally should not contain
Richard> one. --Rat]

  Thanks for your kind answer. Please confirm again.

  In my Emacs, (system-name) returns "is28e1s91", so message.el adds

	Sender: morioka@is28e1s91

Of course, it is not valid mail address. I think Sender field is to
identify the agent responsible for sending message, and it seems not
enough to identify the agent.

  By the way, (system-name) should return FQDM?


Richard> No, that is the Reply-To: header.

  My from field is valid, so I does have such kind of problem.

  My question is

	Sender: morioka@is28e1s91

is valid or not.

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

Re: [Gnus 5.2.14] message-make-sender

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "MT" == =?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA
>>>>> Tomohiko <morioka@jaist.ac.jp> writes:

MT>   Thanks for your kind answer. Please confirm again.
MT>   In my Emacs, (system-name) returns "is28e1s91", so message.el adds
MT> 	Sender: morioka@is28e1s91
MT> Of course, it is not valid mail address.

Actually, it is a valid local mailbox, which is what matters, in this
instance.

MT> I think Sender field is to identify the agent responsible for
MT> sending message, and it seems not enough to identify the agent.

'morioka@is28e1s91' certainly does identify you well enough for anyone
on is28e1s91, which is what matters.

MT>   By the way, (system-name) should return FQDM?

That is FQDN, fully qualified domain name.  And no, system-name returns
the name of the machine you are running on.  Not all machines are
connected to the Internet, thus not all machines will have a fully
qualified domain name.  To force system-name to return a meaningless
value is... meaningless.

Richard> No, that is the Reply-To: header.
MT>   My from field is valid, so I does have such kind of problem.

But what you described is the Reply-To: header, which must be a valid
Internet address, and is used when replies are to be directed to someone
other than the originator (From:) of a message.

MT>   My question is
MT> 	Sender: morioka@is28e1s91
MT> is valid or not.

According to RFC822, which defines the use of the Sender: header, this
is a valid Sender: header.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMbxbDJ6VRH7BJMxHAQEeqwQAlzZpTkOdDLSwpsKaPv+uxx221CEgNP3/
J1U7xkJluD9dU+kEtnry4ZQIx1eSz9VY0zfUThKGUf1nDHoY04t8291/Mb6nvXDo
2OAxNNzFSgsafK4psM4NC0jXe5wnf4oy+mgHIBqHTyMPPY6ILh6JZ2WlWgxmGtYs
lqjymaoH3Ko=
=V5cv
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ Always give generously - a small bird or
<ratinox@unilab.dfci.harvard.edu>   \ rodent left on the bed tells them, "I
http://www.dfci.harvard.edu/         \ care". -A cat's guide to life

Re: [Gnus 5.2.14] message-make-sender

[守岡 知彦 / MORIOKA Tomohiko]

>>>>> In <x7wx1flgcg.fsf@unilab.dfci.harvard.edu> 
>>>>>	Richard Pieri <ratinox@unilab.dfci.harvard.edu> wrote:

Richard> >>>>> "MT" == MORIOKA Tomohiko <morioka@jaist.ac.jp> writes:

MT>   By the way, (system-name) should return FQDM?

Richard> That is FQDN, fully qualified domain name.  And no,
Richard> system-name returns the name of the machine you are running
Richard> on.  Not all machines are connected to the Internet, thus not
Richard> all machines will have a fully qualified domain name.  To
Richard> force system-name to return ameaningless value
Richard> is... meaningless.

  Sorry of my mistake. By the way, in message.el there is a function
`message-make-fqdm'. Is it a typo?

  To return to this subject, I quite agree.


Richard> No, that is the Reply-To: header.
MT>   My from field is valid, so I does have such kind of problem.

Richard> But what you described is the Reply-To: header, which must be
Richard> a valid Internet address, and is used when replies are to be
Richard> directed to someone other than the originator (From:) of a
Richard> message.

  This is my writing mistake. I wanted to write `My from field is
valid, so I don't have such kind of problem.'

  Thanks,
-- 
----------------------------------------------------------------------
Morioka Tomohiko <morioka@jaist.ac.jp>
(`Morioka' is my family name, `Tomohiko' is my personal name.)
---------------- I protest continuation of Chinese nuclear testing.---

Re: [Gnus 5.2.14] message-make-sender

[Lars Magne Ingebrigtsen]

morioka@jaist.ac.jp (=?ISO-2022-JP?B?GyRCPGkyLBsoQiAbJEJDTkknGyhC?= / MORIOKA Tomohiko) writes:

> By the way, in message.el there is a function
> `message-make-fqdm'. Is it a typo?

Whoops, yes.  Fix in 5.2.16.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: [Gnus 5.2.14] message-make-sender

[Sudish Joseph]

Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:
>      authentic   =   "From"       ":"   mailbox  ; Single author
>                  / ( "Sender"     ":"   mailbox  ; Actual submittor
>                      "From"       ":" 1#mailbox) ; Multiple authors
>                                                  ;  or not sender
> 
>         The Sender mailbox  specification  includes  a  word  sequence
>         which  must correspond to a specific agent (i.e., a human user
>         or a computer program) rather than a standard  address.   This

The "standard address" referred to here is one set by a user (for the
From: header, for instance); it does not mean just "valid RFC822
address" in this context--though all standard adresses must be valid
RFC822 addresses, of course. :)

>         expected to be a computer system term, and not (for example) a
>         generalized person reference which can  be  used  outside  the
>         network text message context.

A "generalized person reference" here is an intended-for-humans
address or name.  

> [In fact, not only does Sender: not need to contain a valid Internet
> mail address, it generally should not contain one. --Rat]

This is incorrect.  If you look at the ABNF above, you'll note that
both "from" and "sender" require the use of a "mailbox" (sure, sender
is optional, but if present it MUST have a "mailbox").  "mailbox" =>
"addr-spec" => "domain" (with other stuff, of course).

> aj> It is used when mailbox of From field is not senders real address or
> aj> it contains multiple mailboxes.

This is correct.  It tries to indicate the originator in ambiguous
situations like the above.

> No, that is the Reply-To: header.

No, the reply-to: address is a user-settable address, just as from: is
(both are "standard address"es in the context of the first quoted
paragraph).  Sender is there for one and only one reason: a lame,
half-hearted attempt at authentication; which -can- be very useful,
see below.

To further clarify the important distinction between from: and
sender:, it's worth noting that the DRUMS WG (currently updating /
clarifying 821 and 822 (*)) seriously considered strongly recommending
replacing the current use of reply-to with the from header.  This was
inspired by the complete chaos that prevails w.r.t. mailing lists that
hijack reply-to for their own uses (some do, some don't).

I.e., the intent was to abandon reply-to and make people use the from
header to indicate where replies should go (every mailer I've seen
does this properly: it selects from as the default place to send
replies).  This is in sharp contrast to using it to indicate where it
originated.  In such a context, sender: would be very useful.

-Sudish 

(*): They seemed to be in agreement about throwing the (useless)
definition of references: in mail and replacing it with a definition
closer to that of 1023.  The funny thing about that mailing list was
that I've -never- seen another list where so few messages had
references headers.  Even my procmail setup, where I munge one from
in-reply-to if possible, was mostly useless.  I guess when you've been
using mail as long as most of those people have been, it's difficult
to switch to a newer reader. :-)

Re: [Gnus 5.2.14] message-make-sender

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "SJ" == Sudish Joseph <sudish@ix.netcom.com> writes:

>> [In fact, not only does Sender: not need to contain a valid Internet
>> mail address, it generally should not contain one. --Rat]
SJ> This is incorrect.  If you look at the ABNF above, you'll note that
SJ> both "from" and "sender" require the use of a "mailbox" (sure, sender
SJ> is optional, but if present it MUST have a "mailbox").  "mailbox" =>
SJ> "addr-spec" => "domain" (with other stuff, of course).

Hrm... yup, you are correct:

	mailbox = addr-spec = local-part "@" domain

so Sender: in Internet (Arpanet) mail must include a valid Internet
mailbox when the header is included.

[...]

>> No, that is the Reply-To: header.
SJ> No, the reply-to: address is a user-settable address, just as from:
SJ> is

Perhaps I misunderstood the description, then.  It seemed that the
Reply-to: header was being described.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMb1+H56VRH7BJMxHAQHPGQQAnX/xSBQU8fx0J6oNX9xEE/Ds4TIJQ2iE
09C7V90/alOmwIYHzBRnETMiptIxk7axaZfz8+yAJtmZh125qSGjm9wu0szRk0Az
RvJ6S16jZbYhcx7HbLEL1lyj6R/9YEcoWi1ldF4m7iJSmm+jmoVNOGGnDPcP9OK6
yVvBlZRDRcQ=
=/bza
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ If you're not receiving enough attention,
<ratinox@unilab.dfci.harvard.edu>   \ try knocking over some very expensive
http://www.dfci.harvard.edu/         \ antique lamps. -A cat's guide to life

Re: [Gnus 5.2.14] message-make-sender

[Sudish Joseph]

Richard Pieri <ratinox@unilab.dfci.harvard.edu> writes:
> SJ> No, the reply-to: address is a user-settable address, just as from:
> SJ> is
> 
> Perhaps I misunderstood the description, then.  It seemed that the
> Reply-to: header was being described.

I should learn to write clearly. :-)

What I was trying to say was that the intent of sender: is to indicate
"physical" origin and as such shouldn't be a user-settable field.
Reply-to indicates reply address.  These are distinct conceptually,
though often the same in practice.  So, the original posters intent to
use sender was correct...

822 has many examples (whoever came up with the idea of a
secy. mailing on behalf of a bunch of manager types hit a gold mine,
example-wise :-) where it would be totally inappropriate to have
sender and reply-to point to the same person.

-Sudish 

Re: [Gnus 5.2.14] message-make-sender

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "aj" == =?ISO-2022-JP?Q?=1B$B<morioka@jaist ac jp
>>>>> <morioka@jaist.ac.jp> writes:

aj>  I think it is better if function `message-make-sender' check
aj> (system-name) is FQDM. If (system-name) is not FQDM, message.el makes
aj> invalid Sender field.

So what?  Sender: is not guaranteed to contain anything valid outside of
the host upon which the message originates.  It certainly is not to be
relied upon for anything other than human-level debugging.

Check RFC822 for more specific details.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMbwra56VRH7BJMxHAQGlnQP/ekbi4bQ5f90rb3HKcI1XfdJfuCY4Ikv1
o78Jo3tGjtCk4tzGtXw8S7PCIHMOsPilXw5ORGkt2p+RHKx509Cgsxu7LLSTJbEZ
5om7WEp6DtDYGtfa3r+lVi6q9vFzCdMEPtf2aHCW4AyUSiJprfg68/CDaRbKtZqn
TPeqqExbwzs=
=X05q
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ When you go out in the world, remember:
<ratinox@unilab.dfci.harvard.edu>   \ being placed on a pedestal is a right,
http://www.dfci.harvard.edu/         \ not a priviledge! -A cat's guide to life