Bug 59285 - pine adds Sender headers
pine adds Sender headers
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: pine (Show other bugs)
7.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-04 13:31 EST by Chris Ricker
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-06 00:43:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Ricker 2002-02-04 13:31:15 EST
Pine has support for user-configuration of From: addresses (header).  When the
header address differs from the envelope address, Pine adds a Sender header to
the mail.

This Sender header breaks with many brain-dead sites on the 'net which check
both Sender and From.  For example, Ximian.com's mailing lists check that Sender
and From are the same if a Sender header is present.

Because Sender breaks so many configurations, even sendmail doesn't
automatically add it any more....

Red Hat should patch pine to either (a) not add the Sender header at all or (b)
to add it as X-Sender: instead.

The necessary modifications are in send.c; patches available, depending upon
preferred solution.
Comment 1 Mike A. Harris 2002-02-05 00:41:25 EST
So basically what you're saying is.... that PINE doesn't actually have
a bug, but a bunch of other software out there is buggy, so Red Hat
should modify PINE to make up for some other buggy software breaking
RFC behaviour?

If PINE isn't breaking RFC behaviour, I don't see any bug.  The solution
is to fix the software that is broken.
Comment 2 Chris Ricker 2002-02-05 09:54:38 EST
Your "reasoning" is complete bullshit!  *All* networking software is full of
work-arounds for other networking software which decides to interpret the RFCs
in creative ways--if everyone else at Red Hat adopted your attitude that nothing
which does not literally violate an RFC is a bug, RH Linux wouldn't connect to a
single non-RH box on the 'net!  The RFCs mandate that one "should be
conservative in what one sends, and liberal in what one accepts," a principle
that Pine is violating.

Furthermore, the Sender header as used by Pine is *not* RFC-compliant.  Sender
is required if and only if a multi-origin From header is used, something that
RFCs mandate MUAs allow but which almost no modern MUA actually supports. 
Sender is optional at all other times.  As such, the RFC-compliant behavior is
to add it as X-Sender, not as Sender (since it's optional, interpretation of it
can and does vary, so it should be labelled experimental).

I don't know of a single other MUA which adds the Sender header in the fashion
Pine does, both because it's not particularly RFC-compliant and because it
breaks in interoperation with too much other software -- remote software over
which the MUA user has precisely no control.  Furthermore, it's not something
the MUA should be adding, period.  It's a header which should be added by the
MTA.  No modern MTA gratuitously adds the Sender header, either, for the same
reasons -- it breaks in interoperation with too much other software and it's not
necessary according to the RFCs.  Many MTAs don't even add Sender the one time
the RFCs mandate that they do so, simply because the Sender header causes so
many problems....
Comment 3 Mike A. Harris 2002-02-05 16:54:21 EST
Well, I personally disagree, however, I wont stoop to uttering
vulgarities at you over it.  I will get input on this from various
others including the PINE team (who really should be the ones
getting these types of reports in the first place).

I'll update the report with details of the feedback I receive.
Comment 4 Mike A. Harris 2002-02-05 17:09:51 EST
In the mean time, you might want to attach the patches you've got,
so the changes can be looked at.
Comment 5 Chris Ricker 2002-02-06 00:43:18 EST
Sorry if I offended.  I don't see how you can possibly claim that a Pine feature
which is not mandated by RFC and which causes interoperation problems with
remote legacy software over which I as a Pine user have absolutely zero control
is not a Pine bug, but whatever.

Here's the patch I use with Pine:

[kaboom@slartibartfast SOURCES]$ more pine-x-sender-borked.diff 
--- pine4.44/pine/send.c.orig   Wed Jan  9 22:09:55 2002
+++ pine4.44/pine/send.c        Wed Jan  9 22:11:27 2002
@@ -2254,7 +2254,7 @@
        if(i == N_SENDER && F_ON(F_USE_SENDER_NOT_X, ps_global))
          /* slide string over so it is Sender instead of X-X-Sender */
          for(p=pf->name; *(p+1); p++)
-           *p = *(p+4);
+           *p = *(p+2);
 
         pf->type        = pf_template[i].type;
        pf->canedit     = pf_template[i].canedit;
@@ -3160,7 +3160,7 @@
        if(index == N_SENDER && F_ON(F_USE_SENDER_NOT_X, ps_global))
          /* slide string over so it is Sender instead of X-X-Sender */
          for(p=pf->name; *(p+1); p++)
-           *p = *(p+4);
+           *p = *(p+2);
 
        pf->type        = pf_template[index].type;
        pf->canedit     = pf_template[index].canedit;
@@ -8465,7 +8465,7 @@
                     isdigit((unsigned char) last_char) ? "]" : "");
             label = "X-X-Sender";              /* Jeez. */
             if(F_ON(F_USE_SENDER_NOT_X,ps_global))
-              label += 4;
+              label += 2;
         }
         else{
             strcpy(sstring,"UNAuthenticated Sender");
[kaboom@slartibartfast SOURCES]$ 


The basic idea:  pine generates a X-X-Sender header internally, and then drops
the first 4 chars before writing it to the message (as Sender).  This patch
simply changes that to drop the first 2 chars, so that it writes the header as
X-Sender.  This greatly improves interoperability of Pine with remote clients
w/o causing any detrimental effects.
Comment 6 Mike A. Harris 2002-02-09 19:45:56 EST
After consulting the relevant RFC's myself to refresh myself, I've
discussed this issue with Mark Crispin of the UW PINE team, who is
also part of the body who define such standards as the IMAP protocol.

Here is the basic end of the story deal on this issue:

You seem to have an abuse/misunderstanding of "be conservative of what you send,
be liberal in what you accept concept.

You falsely claim that Pine violates that principle
You falsely claim that Pine's Sender: header is not RFC-compliant
You falsely claim that Sender: is required if multi-origin From: is used
(Sender: is indeed required if a multi-original From: is used, but that is
 not the only case in which it is required)
You falsely claim that Sender: is optional in all other cases (see previous)
You falsely claim that "RFC-compliant behavior is to add it as X-Sender,
not as Sender"
You falsely claim that no other MUA adds the Sender: header in the fashion
that Pine does
You also falsely claim that it "breaks in interoperation with most other software"
Also claiming that "it's not something the MUA should be adding"

None of these claims bear any weight whatsoever.  this is not a bug in
PINE.  It is indeed a bug in the software which mishandles long time
standard internet protocols.  I for one am not going to make Red Hat's
PINE violate RFC standards and differ from every other vendor, including
breaking from the upstream PINE sources merely because some broken
applications out there cough.  PINE already contains various configureable
options to work around some of the brokenness of other software.

Remember, PINE is distributed in source code form, and you're free to
modify it for yourself if you wish.  One of the merits of using an open
source operating system.
Comment 7 Chris Ricker 2002-02-09 21:12:53 EST
Mike,

let me preface this by saying that I'm sorry if my bug reports are offensive to
you.  I guess our personal styles just clash -- you seem particularly quick to
invoke "Not in My Backyard" on bug reports, which can be frustrating to end
users such as myself who wind up feeling ignored.  I, in turn, am probably too
vehement in email (certainly more than I am in person ;-).  I'm sorry.  I
honestly have not been trying to offend, or to file frivolous reports.

That said, I'm willing to drop this pine issue and just maintain it as a patch
that I add to my own builds.  I consider it a bug when my users complain to me
that they can't be on ximian.com mailing lists (to use one prominent Linux
software example) as a result of this feature of pine, but it won't be the first
time or the last time that my vision and RH's vision have differed, and I don't
have a problem with that....  After all, as you say, the fact that I can do that
is why I use RH in the first place.

However, I would like a little more information regarding one of your responses.
 You state that:

<I>You falsely claim that Sender: is required if multi-origin From: is used
(Sender: is indeed required if a multi-original From: is used, but that is
 not the only case in which it is required)</I>

In which other cases is it required?  I'm only aware of that one (and yes, I'm
familiar with at least the 82x / 282x RFCs; it's the only case I know of in
those), and I'm wondering what the others are so I know if I'm effectively
biting myself in the butt by removing the Sender header.

The rest of your response I'll ignore, since it's either based on distortions of
what I said, or else hinges entirely on the above issue....

Note You need to log in before you can comment on or make changes to this bug.