Great Circle Associates Majordomo-Users
(April 1995)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Confirmations on read messages...
From: Marko Toivanen <mtoivane @ cc . joensuu . fi>
Date: Thu, 6 Apr 1995 18:23:22 +0300 (EET DST)
To: Marko Hotti <mhotti @ paju . oulu . fi>
Cc: majordomo-users @ greatcircle . com, Marko Toivanen <mtoivane @ cc . joensuu . fi>
In-reply-to: <>
Reply-to: majordomo-users @ greatcircle . com, Marko Hotti <mhotti @ paju . oulu . fi>, Marko Toivanen <mtoivane @ cc . joensuu . fi>

On Wed, 29 Mar 1995 18:50:05 +0300 (EDT), Marko Hotti
<> wrote to 

> I'm sure this topic has been discussed on this forum several times, but I 
> have to get some help for this problem: Some mail agents (Pegasus Mail 
> e.g) create headers that require a return receipt for a read message. 
> These receits keep getting to my mailing list VOCALIST.
> How do I edit resend so that these headers are stripped off.

Thank David Harris, the author of Pegasus Mail. He has programmed this
nice automatic confirmation feature to Pegasus that takes the address to
send the automatic confirmations of reading from the "Reply-To: " 
*instead* of "From: " or some specific header - thus if any Pegasus rider
sends mail to a discussion list which has the "Reply-To: " set to the
list's address and requests confirmation of reading, the list will get
automatic confirmations of *all* Pegasus riders on it, including the
original sender. How ingenious!

Imagine (for those who have been lucky enough to avoid these experiences):
The unfortunate list gets flooded by strange looking RCPT/Receipt messages
annoying and confusing the subscribers (including the original requestor
and those whose programs flood the list); subscribers start sending
complaints about the messages to the *list* (of course), ranging from
reasonably polite to extremely unpolite (depending on the amount of the
automatic confirmations and the personality of the subscribers) - thinking
that they are either complaining to the lazy list manager or the evil
"sender" of the automatic confirmations, supposing that either of them has
had to deliberately send the messages. After a few heated exchanges and
repeated attempts to explain the situation, the list goes silent for a
long time. Then, some day, the list re-actives itself and sooner or later
someone sends a note to the list with Pegasus requesting confirmations of
reading, and the cycle starts from the beginning again... 

Luckily someone told me that has edited his
resend to throw away the "X-Pmrqc: 1" headers that incite Pegasuses to flood
discussion lists. Our former technical support person made the change within
minutes or less, so it should be easy - this is what he kindly sent me: 

* From: Jukka Oraj{rvi <>
* Subject: Re: Majordomossasi k{ytt{m{si muutos Pegasuksen varalta
* To: (Marko Toivanen)
* Date: Sat, 18 Feb 1995 18:12:08 +0200 (EET)
* No resendin koodista tod. n{k l|ytyy p{tk{, jossa hiidereit{
* poistellaan. Esmes mulla lohko n{ytt{{ nyt t{llaiselta:

Translation: "Now, there'll prob. be a part in resend where headers are
removed. E.g. my block now looks like this:"

*             } elsif (/^from /i          # skip all these headers
*                 || /^sender:/i
*                 || /^return-receipt-to:/i
*                 || /^errors-to:/i
*                 || /^x-pmrqc:/i
*                 || /^x400-/i
*                 || /^return-path:/i
*                 || (/^reply-to:/i && defined($opt_r))   # skip only if "-r" set
*                 || (/^precedence:/i && defined($opt_p)) # skip only if "-p" set
*                 || (/^received:/i && defined($opt_R))   # skip only if "-R" set
*                 || (/^\s/ && ! $kept_last)              # skip if skipped last
*             ) {

Considering the ease of the change, and the fact that many majordomo list
managers, owners, subscribers, etc. will suffer a great deal from Pegasuses
if they have to make the change one by one as they get in trouble with it,
I think that this change should be *incorporated* to future versions of
Majordomo. (It looks like the PMDF Mailserv has similar troubles with

* * * * * * * * *                         * * * * * * * * * * * * * * * *
Marko Toivanen * * * * * *         * * * *  co-moderator in FEYERABEND of  * * * * * * * finger for info

Indexed By Date Previous: Re: Keeping people out
From: Tom Ryan <>
Next: Re: majordomo on PC's
From: (Frostie Sprout)
Indexed By Thread Previous: Apollo DomainOS report re: error 139 problem
From: "Vincent D. Skahan" <>
Next: Host is unreachable
From: Chua Koon Teck <>

Search Internet Search