LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
James Ford <[log in to unmask]>
Thu, 28 Mar 1996 22:36:12 CST
text/plain (115 lines)
I forwarded a copy of the posting concerning X-confirmation-To to David
Harris, author of the program Pegasus Mail.  For those interested, here
is his reply.
 
-- jf
 
----------------------------Original message----------------------------
>> Well the culprit is Pegasus Mail.
>>
>> Apparently it is a Pegasus<->Pegasus thing, but what I now fear
>> is that these automated confirmations are going to start
>> confirming the confirmation (let's hope it's at least not that
>> idiotic!) since the confirmation will come from the mailing list.
>>
>> Well actually, there are two confirmations for the same message
>> from the same person so who knows...
>>
>> I guess it must be associated with a new release or posting of
>> how to activate the option because I've never seen this before.
>
> Actually what initiated it was a message from a Pegasus user
> which included the line:
>
> X-Confirm-Reading-To: <[log in to unmask]>
> X-pmrqc: 1
> Priority: normal
> X-mailer: Pegasus Mail for Windows (v2.23)
>
> And the RCPTS, as I said, have (so far) only come from other
> Pegasus users. Note that the Pegasus mailers didn't respect
> the field value, but only reacted to the presence of the field
> and actually replied to the sender, the mailing list.
> Naughty, naughty (lazy) Pegasus programmers.
 
Firstly, lets get some facts straight here. You have correctly identified
the lines in the message that cause Pegasus Mail to generate confirmation
of reading; you may notice that there are two of them -
X-Confirm-Reading-To, and X-pmrqc. The X-pmrqc header is an old variant
representing the way I originally handled confirmation of reading, while
the "X-confirm-reading-to" is the more modern version. More modern
versions of Pegasus Mail will ignore the "X-pmrqc" header and derive the
confirmation address from the "X-confirm-reading-to" header, which you
will notice is a directed header. Unfortunately, I have no control over
the upgrade process various sites use, so there are still a fairly large
number of sites still using older versions of Pegasus Mail that only
recognize the "x-pmrqc" header.
 
The general solution to this problem is to use your list server's header
stripping capability to remove the "X-pmrqc" line - this will prevent
older versions of Pegasus Mail from generating confirmations of reading
to the message.
 
Now let's get into the interesting stuff. I've been agitating with the
IETF for several years to solve one of the largest problems in Internet
mail, but thus far they have proven either obstinate or unmotivated. I
refer to the problem of identifying that a message originates from a
mailing list, and which field in the message contains the list's address.
 
Over the last three years I've done repeated surveys of the way various
list managers format their messages, and have found that there is no
reliable way of working out which field in a message refers to the
original sender and which field refers to the list. Some lists even break
the RFC1023 rules about the return-path field and put the list address in
that field. Aside from these aberrations, you will find some lists put
the list address in the "Reply-to" field, some put it in the "From"
field, some put it in the "Sender" field, some use a combination of
these, and some do not refer to the list in the headers at all.
 
Pegasus Mail's confirmations of reading are automatically generated
messages and as such, the original method I used for generating them
(i.e, using the "reply-to" address of the message, or the "from" field if
no reply-to field existed) was quite proper and correct according to
RFC822. Confirmations of reading do not represent "problems with
delivery", which is why I never used the return-path field (even though
that wouldn't have helped in some cases). The real problem here is not
with Pegasus Mail, but with the concept of list mail, which is shoddy and
unformalised. It's a great pity that nobody in the hierarchy of the IETF
or IESG has simply sat down and worked out some basic rules for the way
mailing lists should operate - that would be good for everyone.
 
As I have said, more modern versions of Pegasus Mail will use the
directed header when generating confirmations of reading. This is a
shame, because there was an elegance in the way it used to work - for
instance, a person who had a default reply-to address directed to a
different account from their actual account could expect to get
confirmations of reading there as well; the confirmations of reading
followed the same paths as the messages, which is as it should be. Still,
I had to change to using a directed header in an attempt to deal with a
problem that I believe is actually a general failing of list services,
and I have done so.
 
I'm quite amazed how reasonable I'm being here, given the completely
unprovoked, ill-thought-out and rude attack you made on me in public
without even giving me the opportunity to respond. It's only fortuitous
that a friend who subscribes to the same list saw your message and
passed it on to me. I provide Pegasus Mail for free as a general service
to the Internet, an ideal I believe in strongly. I work very hard and
very, very long hours to try to make the program as generally useful and
reliable as is possible, and I deeply resent your name-calling antics.
 
Since I presume that the forum where you posted your defamation is not
public, I hope you will at least have the courtesy to post this response
there so that other subscribers can see the both the actual problem and
the solution.
 
-- David Harris --
(Author, Pegasus Mail)
 
------------------ David Harris -+- Pegasus Mail --------------------------
  Box 5451, Dunedin, New Zealand | e-mail: [log in to unmask]
 +64 3 4536880/Fax +64 3 4536612 | CIS: >internet:[log in to unmask]
 
Thought for the day:
    Concerto (n): a fight between a piano and a pianist.

ATOM RSS1 RSS2