Who sets Sender:?

Who sets Sender:?

[Norman Walsh]

When I send mail, the Sender: goes out as "ndw@mercury", but
(message-make-sender) returns "ndw@nwalsh.com". Why isn't
sender set to message-make-sender?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Some people do their laundry in emacs,
http://nwalsh.com/            | but I find typing ^C-^X-^W-q-L-TT to
                              | add the fabric softener to be a bit
                              | cumbersome.--rlr@panix.com

Re: Who sets Sender:?

[Stainless Steel Rat]

* Norman Walsh <ndw@nwalsh.com>  on Mon, 20 May 2002
| When I send mail, the Sender: goes out as "ndw@mercury", but
| (message-make-sender) returns "ndw@nwalsh.com". Why isn't
| sender set to message-make-sender?

Because then a Sender header would be unnecessary.  From and Sender should
never have the same mailbox.

Sender contains the mailbox of the agent responsible for submitting the
message to the network (MTA).  The idea is that while the originator
mailbox may be ndw@nwalsh.com, the Sender is the local user on the local
machine.

Anything more than that is likely to spark a religious war. :)

-- 
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.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Matt Armstrong]

Norman Walsh <ndw@nwalsh.com> writes:

> When I send mail, the Sender: goes out as "ndw@mercury", but
> (message-make-sender) returns "ndw@nwalsh.com". Why isn't sender set
> to message-make-sender?

The point of the Sender: header is mostly lost on me.  The examples in
the mail RFCs include cases where a secretary is sending mail on
behalf of his/her boss -- the From: header is the boss and the Sender:
is the secretary.  Or cases where the From: header is a list of
multiple addresses (a "group") and the Sender: is the one person who
actually sent the mail.  For Usenet, there may be other reasons to set
the Sender: header, but I'm not aware of them.  The general idea I
think is that Sender:, if present, is the "real" originator of the
message, and implies that From: is not.

By default, Gnus inserts the Sender: header when From: doesn't match
what it would have inserted for the From: header by default.  This has
screwed me over multiple times, since I'm usually setting my From: for
a good reason and I don't want folks using what Gnus thinks is my
"real" address.  E.g. various mailing list or auto responder software
seems to think Sender: is "better" than the From: header if present.
I have sometimes received replies to the Sender: address despite this
behavior not being in any RFC I've ever read.

Anyway, long ago I just disabled sender entirely, and have never
looked back.  Add this to .gnus to do the same:

;;; Defeat Gnus' use of the Sender: header.  I know what I am doing
;;; with my From: header.
(add-to-list 'message-syntax-checks '(sender . disabled))


-- 
Don't send mail to Gale.Hamilton@hole.lickey.com
The address is there for spammers to harvest.

Re: Who sets Sender:?

[Stainless Steel Rat]

* Matt Armstrong <matt@lickey.com>  on Mon, 20 May 2002
| The point of the Sender: header is mostly lost on me.

Maybe it will help clear things up if you consider the idea that an
individual has many identities in a networked environment.  For example, I
am ratinox@peorth.gweep.net.  I am also ratinox@rei.nerv.gweep.net,
ratinox@sidehack.gweep.net, ratinox@ccs.neu.edu, samurairat@spamcop.net and
a few others.  Because ccs.neu.edu is made up of many nodes itself I am
ratinox@foo.ccs.neu.edu where "foo" is about 50 different machines.

Consider the situation where I assume the identity samurairat@spamcop.net,
and I am sending mail from my shell on adhara in the NUCCS cluster.  By
strict reading of RFC 2822, the originator (me) is samurairat@spamcop.net,
but the sender (also me) is ratinox@adhara.ccs.neu.edu.  A less drastic
example is ratinox@ccs.neu.edu as originator and ratinox@adhara.ccs.neu.edu
as the sender.  They are both me, they are in the same cluster, and mail
sent to either will end up on the one mail server, but they are not the
same identity.

What Gnus is attempting to do is adhere to RFC 2822 which states that,
paraphrased, a Sender header must be generated when the identity of the
originator of the message differs from the identity of the agent
responsible for submitting it to the network.  Gnus will makes its best
attempt at generating this required header if the user fails to do so.

Also, be aware that the Sender header must never be used for anything but
human consumption.  Yes, every mail agent from Microsoft breaks this.  Not
my fault.  Not Gnus' fault, either.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Norman Walsh]

/ Stainless Steel Rat <ratinox@peorth.gweep.net> was heard to say:
| * Norman Walsh <ndw@nwalsh.com>  on Mon, 20 May 2002
| | When I send mail, the Sender: goes out as "ndw@mercury", but
| | (message-make-sender) returns "ndw@nwalsh.com". Why isn't
| | sender set to message-make-sender?
|
| Because then a Sender header would be unnecessary.  From and Sender should
| never have the same mailbox.
|
| Sender contains the mailbox of the agent responsible for submitting the
| message to the network (MTA).  The idea is that while the originator
| mailbox may be ndw@nwalsh.com, the Sender is the local user on the local
| machine.

Ok, fair enough. So this presents an interesting conundrum. In my
case, the "local machine" has no name. I'm on a laptop behind a
firewall attached to a cable provider that generates a "random" IP
address via DHCP.

So, on my local subnet (192.168.1.*), "mercury" is this laptop. But
there's no global name for it.

I can't claim that it's 'mercury.nwalsh.com' because no such machine
exists in DNS.

I can't claim that it's n206.cableprovider.net (or whatever the name
for the DHCP provided address is) because that's on the other side of
the firewall (and anything sent to it gets dropped on the floor
anyway).

So my messages go out with

  Sender: ndw@mercury

Fine. I could care less, really. But it turns out that some random
router inside the corporate firewall sometimes "adjusts" this for me,
so that recipients see, for example:

  Sender: ndw@mercury.ireland.mycorp.com

Which strikes me as really wrong.

I could:

1. Ignore it.

2. Report this as an error to the IT folks at mycorp, if in fact
   they're wrong to fux with my Sender: header. (Yeah, that's going to
   be really productive :-)

3. Suppress Sender: as Matt suggested.

4. ...?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | This mortal life is a little thing,
http://nwalsh.com/            | lived in a little corner of the earth;
                              | and little, too, is the longest fame to
                              | come--dependent as it is on a
                              | succession of fast-perishing little men
                              | who have no knowledge even of their own
                              | selves, much less of one dead and
                              | gone.--Marcus Aurelius

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> * Matt Armstrong <matt@lickey.com>  on Mon, 20 May 2002
> | The point of the Sender: header is mostly lost on me.
>
> Maybe it will help clear things up if you consider the idea that an
> individual has many identities in a networked environment.

It might also help if you quoted the part of RFC 2822 that makes you
think this is relevant.

> Consider the situation where I assume the identity samurairat@spamcop.net,
> and I am sending mail from my shell on adhara in the NUCCS cluster.

Ok:
3.6.2. Originator fields
   If the originator of the message can be indicated by a single
   mailbox and the author and transmitter are identical, the "Sender:"
   field SHOULD NOT be used.

That fact that you can be indicated by two distinct mailboxes doesn't
change the fact that you can also be indicated by a single mailbox.

> They are both me, they are in the same cluster, and mail sent to
> either will end up on the one mail server, but they are not the same
> identity.

I can't find anything in RFC 2822 to support that idea.  They are not
the same mailbox, obviously, but how did you conclude that they are
not the same identity?  Especially since RFC 2822 says things like
"mailboxes indicate originators/authors/transmitters" instead of
"mailboxes are originators/authors/transmitters", I don't understand
where your interpretation comes from.

> What Gnus is attempting to do is adhere to RFC 2822

I think, rather, that Gnus is attempting to adhere to RFC 1036, which
specifies different semantics for Sender.  Gnus sloppily uses the same
behavior for mail because it's easier than using different behavior
for mail and news, and because Sender is unimportant for mail.

> Also, be aware that the Sender header must never be used for anything but
> human consumption.

What does this mean, exactly?  If I want to reply to a message and
send the response to the Sender address, should my MUA stop me?  Or
just not provide any easy way to do this?  Or just not make it the
default reply address?


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* Norman Walsh <ndw@nwalsh.com>  on Tue, 21 May 2002
| Ok, fair enough. So this presents an interesting conundrum. In my
| case, the "local machine" has no name. I'm on a laptop behind a
| firewall attached to a cable provider that generates a "random" IP
| address via DHCP.

Now you are geting into religious territory :).

In short, the problem is that you have misconfigured your home LAN when
Gnus presumes you have set it up correctly.

What IP address you have is irrelevant.  Your local machine must have a
fully qualified name, valid within the context of your firewalled network,
or it cannot speak SMTP.  Your firewall or mail gateway must masqerade the
originator headers so that they resolve to valid mailboxes.  It is possible
for the local machine to also act as a mail gateway if it has an MTA
running on it.

Regardless, the Right Thing(tm) to do is to generate Sender headers
yourself, so that the correct information is there.  Gnus will not
overwrite an existing Sender header.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> Your local machine must have a fully qualified name, valid within
> the context of your firewalled network, or it cannot speak SMTP.

That's assuming that the receiving SMTP server cares what name you
give it in HELO/EHLO.  If it doesn't, then you can get away with not
having any name.

> Regardless, the Right Thing(tm) to do is to generate Sender headers
> yourself, so that the correct information is there.

Or suppress them completely, since no person or program cares whether
they're there at all.


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
| It might also help if you quoted the part of RFC 2822 that makes you
| think this is relevant.

Because a mailbox is not necessarilly used by the person who uses the
account.  It could be the vacation program invoked by the user's .forward
file.

Because a mailbox is not necessarilly a single person.  A mailbox may be
shared by several people.

Because a mailbox may not be a person at all.  It could be a program like
Mailman sending out its monthly reminders to list subscribers.

If RFC 2822 is interpreted such that a single user has a single identity
with many mailboxes, then you need to start making exceptions for special
cases and conditionalizing others.  On the other hand, if RFC 2822 is
interpreted such that a single user has many identities, each associated
with different mailboxes, then you do not need to make exceptions for
special cases, because that way all cases become one of the two cases
specifically defined by RFC 2822.

[...]
| That fact that you can be indicated by two distinct mailboxes doesn't
| change the fact that you can also be indicated by a single mailbox.

If that statement were true, then by strictest reading of RFC 2822, mail
that I send as samurairat@spamcop.net from ratinox@ccs.neu.edu should never
have a Sender header.  This is wrong.

[...]
| I think, rather, that Gnus is attempting to adhere to RFC 1036, which
| specifies different semantics for Sender.  Gnus sloppily uses the same
| behavior for mail because it's easier than using different behavior
| for mail and news, and because Sender is unimportant for mail.

This is true, on both counts.  Sender -is- unimportant for mail.  My
opinion is that Sender should never be generated automatically for mail.

| > Also, be aware that the Sender header must never be used for anything but
| > human consumption.

| What does this mean, exactly?  If I want to reply to a message and
| send the response to the Sender address, should my MUA stop me?  Or
| just not provide any easy way to do this?  Or just not make it the
| default reply address?

It means exactly that.  It exists solely for the purpose of letting the
recipient of a message know that the agent who sent it is somehow different
from the one who wrote it.  It serves no technical function.

The default reply address is the From field.  The default reply address can
be changed by the originator by setting a Reply-To header.  Your MUA is
very broken if it uses the Sender address over From or Reply-To.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> * prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
> | It might also help if you quoted the part of RFC 2822 that makes you
> | think this is relevant.
>
> Because a mailbox is not necessarilly used by the person who uses the
> account.  It could be the vacation program invoked by the user's .forward
> file.
>
> Because a mailbox is not necessarilly a single person.  A mailbox may be
> shared by several people.
>
> Because a mailbox may not be a person at all.  It could be a program like
> Mailman sending out its monthly reminders to list subscribers.

I don't see how any of this is relevant.  I also don't see any quotes
from RFC 2822.  Do you think there are any specific parts of RFC 2822
that support your position?

> If RFC 2822 is interpreted such that a single user has a single identity
> with many mailboxes, then you need to start making exceptions for special
> cases and conditionalizing others.

Such as?

> | That fact that you can be indicated by two distinct mailboxes doesn't
> | change the fact that you can also be indicated by a single mailbox.
>
> If that statement were true, then by strictest reading of RFC 2822, mail
> that I send as samurairat@spamcop.net from ratinox@ccs.neu.edu should never
> have a Sender header.

Right.

> This is wrong.

I don't see why.  Anyone who's interested in the route the message was
sent by can look at the Received fields.

> Sender -is- unimportant for mail.  My opinion is that Sender should
> never be generated automatically for mail.

Agreed.

> | > Also, be aware that the Sender header must never be used for anything but
> | > human consumption.
>
> | What does this mean, exactly?  If I want to reply to a message and
> | send the response to the Sender address, should my MUA stop me?  Or
> | just not provide any easy way to do this?  Or just not make it the
> | default reply address?
>
> It means exactly that.

Exactly *which*?  Those are mutually exclusive, or were meant to be.
Should my MUA stop me from sending a response to the Sender address?
If it does not stop me, should it provide no easy way to do this?  If
it provides an easy way to do this, should it merely not use Sender by
default?

> The default reply address is the From field.  The default reply address can
> be changed by the originator by setting a Reply-To header.  Your MUA is
> very broken if it uses the Sender address over From or Reply-To.

I don't think any of that is in dispute.


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
| Such as?

Such as the vacation program.  If ratinox@peorth.gweep.net is me and the
vacation program is not me, then how should the headers be set up?

Such as if for some whacked reason you let me borrow prj@po.cwru.edu.
Which of us is that mailbox, really?

What it ammounts to is this: if an individual has many identities then all
mail is treated identically, but if an individual has one identity then
many messages need to be treated differently depending on circumstances.
Apply Occam's Razor.

[...]
| I don't see why.  Anyone who's interested in the route the message was
| sent by can look at the Received fields.

Sender is not about message routing.  It is about who did what.  Sender is
a social construct, similar to a secretary's mark at the end of typed
message noting who did the typing.

| > Sender -is- unimportant for mail.  My opinion is that Sender should
| > never be generated automatically for mail.
| Agreed.

Well, at least we agree on something, here :).

[...]
| Exactly *which*?  Those are mutually exclusive, or were meant to be.
| Should my MUA stop me from sending a response to the Sender address?

No.  The MUA should never stop you from doing something manually unless
what you are doing will not work.  Typing the Sender address into the To
field of a new message is human consumption.  The MUA should never
automatically supply the Sender address for anything.

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> If ratinox@peorth.gweep.net is me and the vacation program is not
> me, then how should the headers be set up?

The vacation program is you, in the sense that you are ultimately
responsible for the messages it sends, and that *it does not make
sense to send a message specifically to the vacation program, as
distinct from you*.  IOW, you are the only identity involved, because
the vacation program has no identity of its own.  I wouldn't bother
with a Sender in this case.  I also wouldn't object to its presence if
you set up your vacation program to supply a Sender, but I do object
to the idea that this is required by RFC 2822.  Are you making that
claim?

> Such as if for some whacked reason you let me borrow prj@po.cwru.edu.
> Which of us is that mailbox, really?

Too vague to say.  I think it would depend on the technical details of
the reason or of the borrowing.

> What it ammounts to is this: if an individual has many identities then all
> mail is treated identically, but if an individual has one identity then
> many messages need to be treated differently depending on circumstances.

You provide an easy answer for "what constitutes an identity?"; I do
not, because I do not see any basis for that answer in RFC 2822.  I'm
not arguing whether your approach is simple, only whether it is
supported by RFC 2822.

> Sender is not about message routing.  It is about who did what.  Sender is
> a social construct, similar to a secretary's mark at the end of typed
> message noting who did the typing.

But in your example of specifying one of your addresses in From and
another in Sender depending on where you happen to be sending from,
Sender provides no information not already available in Received - it
indicates not who did what, but where you did it from.  So why bother?


paul

Re: Who sets Sender:?

[Matt Armstrong]

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

> Also, be aware that the Sender header must never be used for
> anything but human consumption.  Yes, every mail agent from
> Microsoft breaks this.  Not my fault.  Not Gnus' fault, either.

Agreed.  The RFC never talks about using the Sender: header for
replies, etc.

But even the venerable "formail -r" will use Sender: when determining
an address to reply to.

Spamcop itself trusted the Sender: header more than the From: header
at one time, which my original impetus for defeating it in Gnus
(i.e. it would whitelist the Sender: header in favor of the From:
header if it were present, so if I sent mail with a From: with my work
address, spamcop would whitelist my home address).

It is precisely because the Sender: header is so erratically treated
that I think it is justifiable to simply disable it completely.  Most
of the time it will live on in your message's headers unnoticed and
harmless, but occasionally it'll bite you in the ass when, for
example, some auto-responder decides to use it instead of what you put
in From:.


> * Matt Armstrong <matt@lickey.com>  on Mon, 20 May 2002
> | The point of the Sender: header is mostly lost on me.

[...]

I'll rephrase that to say:

Why *Gnus* inserts a Sender: header when I change my From: header in
email is lost on me.

I think we all agree on this!

The rest of this mail is a pedantic analysis of why I think Stainless
Steel Rat's analysis of RFC 2822's Sender: header is wrong.  If you
have a life, any kind of life, you'll skip reading it.


> Consider the situation where I assume the identity
> samurairat@spamcop.net, and I am sending mail from my shell on
> adhara in the NUCCS cluster.  By strict reading of RFC 2822, the
> originator (me) is samurairat@spamcop.net, but the sender (also me)
> is ratinox@adhara.ccs.neu.edu.

[...]

As I'm sure you know, RFC 2822 does not define or use the term
"identity" at all.  Instead, when talking about From: -vs- Sender: it
uses the terms "agent" and "transmitter", and the task at hand is to
figure out what the RFC means by those terms.

You're definition of "identity" equates it with a mailbox -- namely,
you assume a given identity by using a different mailbox, and each
mailbox has a different identity.

In the paragraph above you claim that the RFC requires (or at least
suggests with a SHOULD) that you to use a Sender: header if the
mailbox you use in From: does not refer to the same account as the one
you're sending the mail from.

As a side note, this is immediately a suspect claim.  The RFC never
talks about user accounts or specific computers or networks or any
other aspect of the mechanics of mail delivery at all.  The RFC merely
associates mailboxes with people and systems.  The RFC never makes
claims about when one mailbox is more or less appropriate when naming
a given person or system (where system means "computer program").  In
particular, the *computer* or *account* the mail originates from is
never mentioned in any criteria for what to use in the From: or
Sender: header.  So any criteria that depend on the computer or
account a mail is sent from in order to interpret RFC 2822 are
suspect.

Anyway, to arrive at your conclusion, you have to plug your definition
of "identity" into what the RFC calls "agent" and "transmitter" --
otherwise there is no way to relate your definition of "identity" with
what the RFC is saying.

Below I'll show why doing this is arguably an incorrect interpretation
of the RFC.  But first I'll respond to how you responded to Paul's
request for a quote from the RFC that justified your position:


> prj@po.cwru.edu (Paul Jarc) writes:
> | It might also help if you quoted the part of RFC 2822 that makes you
> | think this is relevant.
>
> Because a mailbox is not necessarilly used by the person who uses
> the account.  It could be the vacation program invoked by the user's
> .forward file.
> 
> Because a mailbox is not necessarilly a single person.  A mailbox
> may be shared by several people.
> 
> Because a mailbox may not be a person at all.  It could be a program
> like Mailman sending out its monthly reminders to list subscribers.

All of these cases are adequately handled in the RFC by stating that
the author of a message may be "person(s) or system(s)" and that they
should all be listed in the From: header.  I can't find a place where
problems with RFC 2822 arise when considering a mailbox that names a
vacation program, a group of people, or a mailing list manager.


> If RFC 2822 is interpreted such that a single user has a single
> identity with many mailboxes, then you need to start making
> exceptions for special cases and conditionalizing others.  On the
> other hand, if RFC 2822 is interpreted such that a single user has
> many identities, each associated with different mailboxes, then you
> do not need to make exceptions for special cases, because that way
> all cases become one of the two cases specifically defined by RFC
> 2822.

I'm willing to be wrong, but without an example of where the RFC falls
short and requires the exceptions and special cases, I have to assume
this claim is groundless since I can't find any examples myself.


> What Gnus is attempting to do is adhere to RFC 2822 which states
> that, paraphrased, a Sender header must be generated when the
> identity of the originator of the message differs from the identity
> of the agent responsible for submitting it to the network.  Gnus
> will makes its best attempt at generating this required header if
> the user fails to do so.

This is the part of RFC 2822 that talks about the semantic meaning of
Sender (section 3.6.2):

   The "Sender:" field specifies the mailbox of the agent responsible
   for the actual transmission of the message.  For example, if a
   secretary were to send a message for another person, the mailbox of
   the secretary would appear in the "Sender:" field and the mailbox
   of the actual author would appear in the "From:" field.  If the
   originator of the message can be indicated by a single mailbox and
   the author and transmitter are identical, the "Sender:" field
   SHOULD NOT be used.  Otherwise, both fields SHOULD appear.

Of course, "agent" and "transmitter" are not explicitly defined here
or anywhere else in the document.  However it is pretty clear to me
that they refer to people or systems that send mail, not individual
mailboxes.

    1) The paragraph uses the wording "mailbox of the agent" --
       i.e. an "agent" has a "mailbox" but they are not the same thing
       nor do they necessarily have a 1 to 1 relationship.

    2) Earlier in 3.6.2:  "The "From:" field specifies the author(s)
       of the message, that is the mailbox(es) of the person(s) or
       system(s) responsible for writing the message."  So a system
       or person can have a mailbox.

    3) "if a secretary were to send a message for another person" --
       the only concrete example they use is of one person sending
       mail on behalf of another.

    4) "the author and transmitter are identical" -- equates an author
       with a transmitter; so a transmitter is a "person or system"
       just as an author is.

    5) "originator of the message can be indicated by a single
       mailbox" -- "originator of the message" is the author, since
       there has to be a single sender of a message, while there can
       be multiple authors.

So the RFC is pretty clearly drawing a line between "person or system"
and a mailbox.  Here is the same paragraph annotated with what terms
talk about "person or system" and what terms talk about mailboxes.  I
actually don't have to annotate mailboxes, since the RFC consistently
uses "mailbox" when it is talking about mailboxes.

   The "Sender:" field specifies the mailbox of the agent [person or
   system] for the actual transmission of the message.  For example,
   if a secretary were to send a message for another person, the
   mailbox of the secretary would appear in the "Sender:" field and
   the mailbox of the actual author [person or system] would appear in
   the "From:" field.  If the originator of the message [person or
   system] can be indicated by a single mailbox and the author [person
   or system] and transmitter [person or system] are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear.

It is pretty clear to me that the RFC 2822 is talking about comparing
"persons or systems" when deciding if a Sender: header is used, not
what you call identities (e.g. abstract entities that come into being
with each new email address, where one "person or system" can have
many).

So to take your "should mail with header From: samurairat@spamcop.net
have a sender header of "Sender: ratinox@adhara.ccs.neu.edu" example,
I'll plug it into into RFC 2822 with the following definitions arrived
at above:

    - author: a person or system, or group thereof, that composes a
      message.  Same as "originator of the message."
    - transmitter: a person or system that transmits a message.

To quote section 3.6.2 again, annotated with my interpretation:

    If the originator of the message [The person called "Stainless
    Steel Rat"] can be indicated by a single mailbox [yes, we're
    talking about a single address in the From: header] and the author
    and transmitter are identical [yes, the author and transmitter are
    both a "person or system", namely "Stainless Steel Rat"], the
    "Sender:" field should not be used.

So the "Sender:" field should not be used when the From: header is a
valid mailbox that names the person or system that actually sends the
mail.

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
| But in your example of specifying one of your addresses in From and
| another in Sender depending on where you happen to be sending from,
| Sender provides no information not already available in Received - it
| indicates not who did what, but where you did it from.  So why bother?

Because it was a contrived example, and not a good one.

Here are the issues:

1. Sender is largely useless for mail except in limited circumstances.

2. RFC 2822 requires a Sender header be generated when the identities of
   the originator and sender differ.

3. RFC 2822 does not clearly define the identities of the various agents
   involved in mail handling.

I choose to use a definition of "identity" that meets the criteria given by
both RFC 2822 and RFC 1039(?, I always forget the Usenet RFC number), and
place the onus on the system and network for proper configuration and
masqerading when necessary.  This has the manifold benefit of making every
news and mail user agent work out of the box.

-- 
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.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Stainless Steel Rat]

As I said, this is a religious debate, one that will not be resolved here
and now, possibly never.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> 1. Sender is largely useless for mail except in limited circumstances.

Right.  In particular, nothing ever breaks when Sender is absent,
AFAIK.  OTOH, some programs do use Sender improperly when it is
present.  So it should be omitted whenever we can get away with it.

> 2. RFC 2822 requires a Sender header be generated when the identities of
>    the originator and sender differ.

By "generated", do you mean automatically?  I would disagree with
that.  Even if not, this is only a matter of SHOULD, not MUST, so I
wouldn't say "required".

> 3. RFC 2822 does not clearly define the identities of the various agents
>    involved in mail handling.

It's clear enough to me, and to Matt.  It seems to require severe
twisting of the language to arrive at your interpretation.

> I choose to use a definition of "identity" that meets the criteria given by
> both RFC 2822 and

Which criteria are those, specifically?

> RFC 1039(?, I always forget the Usenet RFC number),

1036.

> This has the manifold benefit of making every news and mail user
> agent work out of the box.

You give me the impression that that goal is worth more to you than
using a reasonable reading of RFC 2822.  If you care about that goal,
that's fine, but I don't see anything in RFC 2822 to back you; you can
promote that sort of configuration without claiming that RFC 2822
demands it.


paul

Re: Who sets Sender:?

[Matt Armstrong]

prj@po.cwru.edu (Paul Jarc) writes:

> By "generated", do you mean automatically?  I would disagree with
> that.  Even if not, this is only a matter of SHOULD, not MUST, so I
> wouldn't say "required".

There is one case where it MUST be generated -- when the From: header
has multiple mailboxes.

I've never seen such a mail though.  Perhaps it was a more common
practice "in the old days."


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

> As I said, this is a religious debate, one that will not be resolved
> here and now, possibly never.

I will say that it frustrates me that RFC 2822 isn't more obvious
about the intended interpretation.

The books like the Bible should elicit religious debate, not RFCs.

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
| > 2. RFC 2822 requires a Sender header be generated when the identities of
| >    the originator and sender differ.

| By "generated", do you mean automatically?  I would disagree with
| that.  Even if not, this is only a matter of SHOULD, not MUST, so I
| wouldn't say "required".

In some circumstances the Sender MUST appear, such as when the From field
contains more than one mailbox.  In others it says that the header SHOULD
appear.  It does not say who MUST or SHOULD generate the header.  It is
presumed that the MUA will do so if the user does not, just as the MUA
fills in the From header as necessary.

| > I choose to use a definition of "identity" that meets the criteria given by
| > both RFC 2822 and

| Which criteria are those, specifically?

That it identify the agent who hits the button that initiates the process
of connecting to the the MTA or news server and handing off the message,
and that an attempt has been made at getting the address correct if the
user has not done so himself.

[...]
| You give me the impression that that goal is worth more to you than
| using a reasonable reading of RFC 2822.  If you care about that goal,
| that's fine, but I don't see anything in RFC 2822 to back you; you can
| promote that sort of configuration without claiming that RFC 2822
| demands it.

Correct me if I am mistaken, but it seems to me that you read RFC 2822 as a
Gnus user.  You see a small problem with Gnus and you fix it.  There is
nothing wrong with that, but...

I read RFC 2822 as a systems administrator, and I have to make RFC 2822 --
the format of a mail message -- work with all of the other protocols
necesssary to get your message delivered.  Where you see a small problem, I
see a symptom of a greater problem, one that affects all users on a
network.  Your solution is to configure the client.  That is not a good
solution for systems administrators who may have to deal with hundreds or
thousands of users.  We want to fix the problem once and be done with it.
My solution is to configure the network and mail gateway to function
correctly for everyone who uses them.  What you see as my goal is the
solution to your problem.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> It is presumed that the MUA will do so if the user does not, just as
> the MUA fills in the From header as necessary.

Is the MUA supposed to be able to determine when Sender is needed?

> | > I choose to use a definition of "identity" that meets the criteria given by
> | > both RFC 2822 and
>
> | Which criteria are those, specifically?
>
> That it identify the agent who hits the button that initiates the process
> of connecting to the the MTA or news server and handing off the message,

That criterion is satisfied equally well by either of our definitions.

> and that an attempt has been made at getting the address correct if the
> user has not done so himself.

I can't find that criterion in RFC 2822.  Can you point it out?

Even assuming this criterion, the MUA is extremely limited in its
ability to construct a correct address.  user@hostname is often not a
working address - I'd say it's wrong more often than right.  It seems
to me that even for an MUA that wants to satisfy your position, it
cannot do any better, on average, than leaving From and Sender
entirely to the user.

> Where you see a small problem, I see a symptom of a greater problem,
> one that affects all users on a network.  Your solution is to
> configure the client.

That's the only way I have to fix my instance of the problem.  I would
like to see MUAs changed to never add Sender automatically, but that's
outside my scope.

> My solution is to configure the network and mail gateway to function
> correctly for everyone who uses them.

Yes, but you also (seem to) take the extra step of claiming that RFC
2822 demands this of you.  I'm not saying that you shouldn't configure
your network that way, or that RFC 2822 claims that you shouldn't.
I'm saying that RFC 2822 *doesn't* say that you *should*; it is silent
on this issue.


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
| Is the MUA supposed to be able to determine when Sender is needed?

If the user fails to create a Sender header when it is required then the
MUA needs to be able to do so.  In many (most?) cases the MUA must guess
because it cannot read the minds of the originator or sender.

| That criterion is satisfied equally well by either of our definitions.

Thus does not invalidate either of them.

| > and that an attempt has been made at getting the address correct if the
| > user has not done so himself.
| I can't find that criterion in RFC 2822.  Can you point it out?

Definition of addr-spec plus requirements of RFC 2821 and the other
protocols involved in mail handling.

| Even assuming this criterion, the MUA is extremely limited in its
| ability to construct a correct address.

This is true, however...

| user@hostname is often not a working address - I'd say it's wrong more
| often than right.

... if your site is configured properly, with a wildcard MX record for your
entire (sub)domain pointing to your site's mail server, and aliases or
mailer tables for mapping your users' login names to mailboxes, then
user@hostname will always be a working address.

| It seems to me that even for an MUA that wants to satisfy your position,
| it cannot do any better, on average, than leaving From and Sender
| entirely to the user.

The MUA cannot do it alone.  It needs help.  I have always stood by that
statement.  A properly configured site will have the resources in place so
that the MUA can guess correctly, or so that its guesses are always
correct.

[...]
| Yes, but you also (seem to) take the extra step of claiming that RFC
| 2822 demands this of you.  I'm not saying that you shouldn't configure
| your network that way, or that RFC 2822 claims that you shouldn't.
| I'm saying that RFC 2822 *doesn't* say that you *should*; it is silent
| on this issue.

Because site configuration is outside of the scope of RFC 2822.  So is Gnus
configuration.  What RFC 2822 demands is that mail messages be formatted
correctly.  Your solution, leaving the site broken and changing Gnus'
default behaviour, may cause Gnus to construct illegal headers.  My
solution, fixing the site and leaving Gnus alone, will never cause Gnus to
create illegal headers.  Your solution addresses a symptom of a problem and
may create another problem.  My solution addresses the problem and prevents
other problems.

-- 
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.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> * prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
> | Is the MUA supposed to be able to determine when Sender is needed?
>
> If the user fails to create a Sender header when it is required then the
> MUA needs to be able to do so.  In many (most?) cases the MUA must guess
> because it cannot read the minds of the originator or sender.

In what cases should the MUA guess that Sender is needed?

> | > and that an attempt has been made at getting the address correct if the
> | > user has not done so himself.
> | I can't find that criterion in RFC 2822.  Can you point it out?
>
> Definition of addr-spec plus requirements of RFC 2821 and the other
> protocols involved in mail handling.

Chapter and verse, please.

> | user@hostname is often not a working address - I'd say it's wrong more
> | often than right.
>
> ... if your site is configured properly, with a wildcard MX record for your
> entire (sub)domain pointing to your site's mail server, and aliases or
> mailer tables for mapping your users' login names to mailboxes, then
> user@hostname will always be a working address.

That requires a significant degree of cooperation among hosts at a
site; all usernames on all machines must be known to the mail server.
I don't think that's universally agreed-upon to be a "proper" policy,
and I don't think MUAs should assume this to be true any more than you
think networks should assume MUAs to be well-configured.

> Your solution, leaving the site broken and changing Gnus' default
> behaviour, may cause Gnus to construct illegal headers.

I never said the site should be left "broken"; we can have
well-configured networks *and* well-configured MUAs.  I've only said
that Gnus should not add Sender automatically.  In what circumstances
would that qualify as Gnus constructing illegal headers?

> Your solution addresses a symptom of a problem and may create
> another problem.  My solution addresses the problem and prevents
> other problems.  My solution, fixing the site and leaving Gnus
> alone, will never cause Gnus to create illegal headers.

You're trying to make every MUA work on your site.  I'm trying to make
Gnus work on every site - including the ones that aren't configured
the way you prefer.  This means catering in part to the cases where
user@hostname is not a working address, because Gnus is used in those
cases sometimes.

Since Sender is only for human consumption, and it is so difficult for
software to guess a correct value, and the sender might want to
conceal that information anyway, I think any attempt to add Sender
automatically is wasted effort.


paul

Re: Who sets Sender:?

[Paul Jarc]

Richard Kettlewell <richardk@chiark.greenend.org.uk> wrote:
> Matt Armstrong <matt@lickey.com> writes:
>> There is one case where it MUST be generated -- when the From: header
>> has multiple mailboxes.
...
> The most recent I received was in January 2002.
>
> It didn't have any Sender: field at all, as it happens.

Did anything break because of that?


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
| Chapter and verse, please.

There is a lot of material to cover.  O'Reiley & Associates has a couple of
good books on the subjects.  Start with DNS/BIND (cricket book) and SMTP
stuff (bat book).

[...]
| That requires a significant degree of cooperation among hosts at a
| site;

In fact, it can work with no cooperation at all.  It requires a single
wildcard MX record for the domain in the domain's zone file.  Cooperation
helps, of course.

| all usernames on all machines must be known to the mail server.
| I don't think that's universally agreed-upon to be a "proper" policy,

It has been everywhere I have worked and almost everywhere my sysadmin
friends have worked.  The only sites that do not wildcard MX their domains
and match mail and machine logins are those run by incompetent management.

| and I don't think MUAs should assume this to be true any more than you
| think networks should assume MUAs to be well-configured.

The beauty of it is that the MUA does not need to assume much of anything
other than that the host is properly configured, which we agree should be
the case anyway.  And the site assumes nothing other than each node within
it is configured correctly, which we agree should be the case anyway.

By the way, note the Received headers in this message and compare them to
those I sent earlier today.  My machine, peorth.gweep.net, is a notebook.
It travels.  Relying on Received headers for Sender information in my case
is useless.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Richard Kettlewell]

prj@po.cwru.edu (Paul Jarc) writes:
> Richard Kettlewell <richardk@chiark.greenend.org.uk> wrote:
>> Matt Armstrong <matt@lickey.com> writes:

>>> There is one case where it MUST be generated -- when the From:
>>> header has multiple mailboxes.
> ...
>> The most recent I received was in January 2002.
>>
>> It didn't have any Sender: field at all, as it happens.
>
> Did anything break because of that?

Not for me (using VM under XEmacs), and not for Exim, SAUCE (an
anti-spam SMTP proxy thingy) or InterMail (whatever that is) judging
by the Received: fields.  However the message was BCC'd to many other
recipients and I wouldn't know if it worked or not for them.

(Where I've sent such messages, they've had a proper Sender: field.)

ttfn/rjk

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> * prj@po.cwru.edu (Paul Jarc)  on Tue, 21 May 2002
>> In what cases should the MUA guess that Sender is needed?
...
>> I've only said that Gnus should not add Sender automatically.  In
>> what circumstances would that qualify as Gnus constructing illegal
>> headers?

You didn't answer these questions, nor many others from previous
messages.  The effect is that it's impossible for me to *examine* your
position.  You just restate it different ways without explaining it,
often seeming evasive about it.  I'm not going to continue this
discussion any longer.


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Wed, 22 May 2002
| >> In what cases should the MUA guess that Sender is needed?
| ...
| >> I've only said that Gnus should not add Sender automatically.  In
| >> what circumstances would that qualify as Gnus constructing illegal
| >> headers?

| You didn't answer these questions, nor many others from previous
| messages.

Because the answers are obvious to anyone who bothers to think about them
for more than half a second.  RFC 2822 defines when a Sender header is
needed and when it must not be used.  The MUA should attempt to deterine if
a Sender header is needed for every message sent.  Failure to generate a
Sender header when one is required results in a technically incorrect
message.  When is a Sender header required?  When RFC 2822 says it is.
When should Gnus guess?  Always.  When should Gnus not create a Sender
header?  When one already exists or RFC 2822 says no.

-- 
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!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> * prj@po.cwru.edu (Paul Jarc)  on Wed, 22 May 2002
> | >> In what cases should the MUA guess that Sender is needed?
...
> The MUA should attempt to deterine if a Sender header is needed for
> every message sent.

You're answering this question: "in what cases should the MUA guess
whether Sender is needed?"  That isn't the question I asked.

> | You didn't answer these questions, nor many others from previous
> | messages.
>
> Because the answers are obvious to anyone who bothers to think about them
> for more than half a second.

It isn't obvious to me what *your* answers are, or I wouldn't have
asked them.

> Failure to generate a Sender header when one is required results in
> a technically incorrect message.

Will that incorrectness ever cause problems?  A wrong guess in the
other direction can cause problems.  "Correct" isn't always the best
thing to be.

> When is a Sender header required?  When RFC 2822 says it is.
...
> When should Gnus not create a Sender header?  When one already
> exists or RFC 2822 says no.

Punting to RFC 2822 is pointless when the interpretation of RFC 2822
is itself in question.


paul

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Wed, 22 May 2002
| You're answering this question: "in what cases should the MUA guess
| whether Sender is needed?"  That isn't the question I asked.

I answered -that- question in one of my earliest posts: if the From field
is not user@host.domain.  That was right before I pointed out that this is
a religious debate.

[...]
| Will that incorrectness ever cause problems?

Potentially, yes.  Received headers will tell you the route a message has
taken, but it will not necessarilly tell you anything about the humans
involved.

| A wrong guess in the other direction can cause problems.  "Correct" isn't
| always the best thing to be.

A wrong guess in the other direction will not cause problems unless someone
violates RFC 2822 and misuses Sender.

-- 
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.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Paul Jarc]

Stainless Steel Rat <ratinox@peorth.gweep.net> wrote:
> [MUAs should add Sender] if the From field is not user@host.domain.

Even assuming that RFC 2822 specifies this, it's still not worthwhile,
because of abuse of Sender by other programs.  People can always
configure their MUAs to add Sender when they care about it.

> A wrong guess in the other direction will not cause problems unless someone
> violates RFC 2822 and misuses Sender.

Right.  But that happens, and all Gnus can do about it is omit
Sender.  Do you think the harm from an absent Sender is greater than
the harm from a wrong Sender?  Why?


paul

Re: Who sets Sender:?

[Bjørn Mork]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:
> * prj@po.cwru.edu (Paul Jarc)  on Wed, 22 May 2002
> | You're answering this question: "in what cases should the MUA guess
> | whether Sender is needed?"  That isn't the question I asked.
>
> I answered -that- question in one of my earliest posts: if the From field
> is not user@host.domain.  That was right before I pointed out that this is
> a religious debate.

And the reason for this being a religious debate is such strong
beliefs for no apparent reason. There is nothing other than a
religiously confused mind that can make "originator", "author" or
"transmitter" become "user@host.domain".

If I were to state my beliefs, I would say that the intented meaning
of this section is that a Sender never should be added as long as the
_person_ writing the message and the _person_ entering the message
into the mail transport are the same:

   If the originator of the message can be indicated
   by a single mailbox and the author and transmitter are identical, the
   "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
   appear. 

Which would make the current Gnus default a violation of RFC2822.

> [...]
> | Will that incorrectness ever cause problems?
>
> Potentially, yes.  Received headers will tell you the route a message has
> taken, but it will not necessarilly tell you anything about the humans
> involved.

Which is a problem for whom/what?

> | A wrong guess in the other direction can cause problems.  "Correct" isn't
> | always the best thing to be.
>
> A wrong guess in the other direction will not cause problems unless someone
> violates RFC 2822 and misuses Sender.

Which I hope everybody can agree is a real problem today. Buggy MUAs
use the Sender for replies, and buggy mailing list software refuse
messages unless the Sender is subscribed.

One can either be a religious fanatic, or try to adapt as much as
possible within the _actual_ RFC requirements.


Bjørn
-- 
I mean, most Nicaraguan people have computers .  

Re: Who sets Sender:?

[Stainless Steel Rat]

* prj@po.cwru.edu (Paul Jarc)  on Wed, 22 May 2002
| Even assuming that RFC 2822 specifies this, it's still not worthwhile,
| because of abuse of Sender by other programs.  People can always
| configure their MUAs to add Sender when they care about it.

I did not see where in RFC 2822 it specifies that a user can add a Sender
header when he feels like it, or omit it if he does not care about it.


| Right.  But that happens, and all Gnus can do about it is omit
| Sender.  Do you think the harm from an absent Sender is greater than
| the harm from a wrong Sender?  Why?

I have always maintained that following standards is superior to catering
to broken software, because catering to brokenness spawns more brokenness.
I have also always maintained that fixing broken software is superior to
working around the broken parts.

-- 
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.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Stainless Steel Rat]

* Bjørn Mork <bmork@dod.no>  on Wed, 22 May 2002
| If I were to state my beliefs, I would say that the intented meaning
| of this section is that a Sender never should be added as long as the
| _person_ writing the message and the _person_ entering the message
| into the mail transport are the same:

This requirement fails for programs, programs acting on behalf of users,
users acting on behalf of themselves for political reasons, and possibly
many other cases, none of which an MUA can possibly determine without help
from the user who presumably understands what he is doing.  Fact is, most
users do not know what they are doing.

[...]
| Which is a problem for whom/what?

We humans who may need information for political or technical reasons.

[...]
| One can either be a religious fanatic, or try to adapt as much as
| possible within the _actual_ RFC requirements.

I have stated nothing that violates the letter or the spirit of RFC 2822.
Quite the contrary, I have proposed a solution that meets all of the
requirements of all of the relevant RFCs, not just RFC 2822.

-- 
Rat <ratinox@peorth.gweep.net>    \ Ingredients of Happy Fun Ball include an
Minion of Nathan - Nathan says Hi! \ unknown glowing substance which fell to
PGP Key: at a key server near you!  \ Earth, presumably from outer space.
       That and five bucks will get you a small coffee at Starbucks.

Re: Who sets Sender:?

[Steinar Bang]

>>>>> Norman Walsh <ndw@nwalsh.com>:

> Ok, fair enough. So this presents an interesting conundrum. In my
> case, the "local machine" has no name. I'm on a laptop behind a
> firewall attached to a cable provider that generates a "random" IP
> address via DHCP.

Been there.

> So, on my local subnet (192.168.1.*), "mercury" is this laptop. But
> there's no global name for it.

Been there too, when my laptop was at home.

> I can't claim that it's 'mercury.nwalsh.com' because no such machine
> exists in DNS.

What I do is to make sure Gnus doesn't create a Sender: header by
having
	;; Avoid setting the sender header, and by this use the From: address
	;; as the envelope address
	(add-to-list 'message-syntax-checks '(sender . disabled))
in my ~/.gnus.el.

Then I make sure exim sets the From line of the envelope to be the same
as the From: field, by setting the return_path of outgoing SMTP
messages in /etc/exim/exim.conf:
	remote_smtp:
	  driver = smtp
	  return_path = ${local_part:$reply_address}@${domain:$reply_address}

(this is on debian testing).

Re: Who sets Sender:?

[Barry Fishman]

Norman Walsh <ndw@nwalsh.com> writes:

> / Stainless Steel Rat <ratinox@peorth.gweep.net> was heard to say:
> | Sender contains the mailbox of the agent responsible for submitting the
> | message to the network (MTA).  The idea is that while the originator
> | mailbox may be ndw@nwalsh.com, the Sender is the local user on the local
> | machine.
>
> Ok, fair enough. So this presents an interesting conundrum. In my
> case, the "local machine" has no name. I'm on a laptop behind a
> firewall attached to a cable provider that generates a "random" IP
> address via DHCP.

I suspect this situation is very common.  My home network name I keep
as just ".local" since at least conveys the impression that it will
not be found from DNS, and is not expected to be unique.  I was also
wondered about a message-id which was not anchored to a unique
address.

The approach I take is probably a bit convolved but begins by
giving my system a unique name which should be at least traceable
by humans:

(setq mail-host-address "barry_fishman.att.net")

Which is my ISP username grafted into its network domain.
I then convince the message package to use it, and not send any
sender field:

(setq gnus-local-domain "att.net")

;; I don't really have valid FQDN information so clean up header
(setq message-syntax-checks '((sender . disabled)))

;; Makes sure (message-make-fqdn) uses mail-host-address when we
;; are on the .local network.
(setq message-bogus-system-names "^localhost\\.\\|\\.local$")

Convincing smtp-mail the same is a bit harder:

;; Use smtpmail
(setq send-mail-function 'smtpmail-send-it)          ; for 'mail'
(setq message-send-mail-function 'smtpmail-send-it) ; for 'gnus'

;; Force smtpmail to use mail-host-address
(autoload 'smtpmail-fqdn "smtpmail" nil nil)
(defadvice smtpmail-fqdn (around change-smtpmail-fqdn activate)
  "Supply a domain which is meaningful but wrong"
  (setq ad-return-value mail-host-address))

I could have just let my ISP generate the message ID, but then
I couldn't:

;;;; Archive all messages you send out here
(setq gnus-message-archive-group "nnmh:list.sent")
(setq gnus-gcc-mark-as-read t) ; Doesn't seem to do much

and expect to get access to the message-id of the sent message.

Then again, with all the spam about, making your messages more
tracable is not necessarily a good idea.

-- 
Barry

Re: Who sets Sender:?

[Harry Putnam]

Barry Fishman <barry_fishman@att.net> writes:

> Norman Walsh <ndw@nwalsh.com> writes:
>
>> / Stainless Steel Rat <ratinox@peorth.gweep.net> was heard to say:
>> | Sender contains the mailbox of the agent responsible for submitting the
>> | message to the network (MTA).  The idea is that while the originator
>> | mailbox may be ndw@nwalsh.com, the Sender is the local user on the local
>> | machine.
>>
>> Ok, fair enough. So this presents an interesting conundrum. In my
>> case, the "local machine" has no name. I'm on a laptop behind a
>> firewall attached to a cable provider that generates a "random" IP
>> address via DHCP.
>
> I suspect this situation is very common.  My home network name I keep
> as just ".local" since at least conveys the impression that it will
> not be found from DNS, and is not expected to be unique.  I was also
> wondered about a message-id which was not anchored to a unique
> address.

Barry, I had a little trouble figuring out what the end result of our
customizations is.
>
> The approach I take is probably a bit convolved but begins by
> giving my system a unique name which should be at least traceable
> by humans:
>
> (setq mail-host-address "barry_fishman.att.net")

What does gnus do with this information?

> Which is my ISP username grafted into its network domain.
> I then convince the message package to use it, and not send any
> sender field:
>
> (setq gnus-local-domain "att.net")

Ditto here.  

> ;; I don't really have valid FQDN information so clean up header
> (setq message-syntax-checks '((sender . disabled)))

with this done, what fields are effected by your other settings?

> ;; Makes sure (message-make-fqdn) uses mail-host-address when we
> ;; are on the .local network.
> (setq message-bogus-system-names "^localhost\\.\\|\\.local$")

What is the advantage of this?

With sender disabled, is the only field being effected the rhs of
message id?

Does this accomplish the same things:

  (defun message-make-fqdn ()
    "My  hacked message-id."
    "reader.newsguy.com")

Re: Who sets Sender:?

[Barry Fishman]

Harry Putnam <reader@newsguy.com> writes:

> Barry Fishman <barry_fishman@att.net> writes:
>> The approach I take is probably a bit convolved but begins by
>> giving my system a unique name which should be at least traceable
>> by humans:
>>
>> (setq mail-host-address "barry_fishman.att.net")
>
> What does gnus do with this information?

First: When I post news or send mail through my ISP, my identity is
really linked to the ISP, and has nothing to do with the machine on
which I am actually running emacs.  My mailbox is really
barry_fishman@att.net, and that is the only unique ID I have.  Mail I
send out goes through AT&T's server.  Where I happen to be at the
moment (and for that matter my login name) is irrelevant, since (to
use software terminology) it exist in a separate private namespace.

What I wanted to do is to synthesize a virtual host name that was at
least more meaningful, and then convince emacs mail and gnus to use
that.  Ideally it would be unique, so I just applied the (probably
obsolete) technique of replacing the at (@) in my address with a dot
(.).

I set mail-host-address since that is the most primitive level mail
host name variable I could find, and that is were message-make-fqdn
get its address when it knows the system-name is bogus.

>
>> Which is my ISP username grafted into its network domain.
>> I then convince the message package to use it, and not send any
>> sender field:
>>
>> (setq gnus-local-domain "att.net")

My mail domain is "att.net".  If I had a real DNS address this would
still be true.


>> ;; I don't really have valid FQDN information so clean up header
>> (setq message-syntax-checks '((sender . disabled)))
>
> with this done, what fields are effected by your other settings?

It it used in message-generate-headers to generate the message-id.

>
>> ;; Makes sure (message-make-fqdn) uses mail-host-address when we
>> ;; are on the .local network.
>> (setq message-bogus-system-names "^localhost\\.\\|\\.local$")
>
> What is the advantage of this?

This is needed to keep message-make-fqdn from using my system-name

>
> With sender disabled, is the only field being effected the rhs of
> message id?
>
> Does this accomplish the same things:
>
>   (defun message-make-fqdn ()
>     "My  hacked message-id."
>     "reader.newsguy.com")

Yes, but in order to change a function in message I would have to
load it first, and the indirect approach seemed cleaner and more
in keeping with what seemed to be the author's intent.  Until
this indirect way was added to message, I used an advice, just as
I still do with smtp-mail.

Although you didn't ask, I changed smtpmail-fdqn, to fix a problem
created by my changes.  I suspect the cause was that ATT would see a
message-id that didn't match my HELO greeting and think I was
forwarding mail through them.

-- 
Barry