On Fri, 2002-12-27 at 07:04, J. Grant wrote:
> Hello Jack,
> 
> Thank you for the infomative reply. Clearly you have considered this 
> more than me, but surely this is what the special headers are for?
> 
> List-Post: <mailto:[EMAIL PROTECTED]>

3.4. List-Post

The List-Post field describes the method for posting to the list. This
is typically the address of the list, but MAY be a moderator, or
potentially some other form of submission. For the special case of a
list that does not allow posting (e.g., an announcements list), the
List-Post field may contain the special value "NO".

   Examples:

     List-Post: <mailto:[EMAIL PROTECTED]>
     List-Post: <mailto:[EMAIL PROTECTED]> (Postings are Moderated)
     List-Post: <mailto:[EMAIL PROTECTED]?subject=list%20posting>
     List-Post: NO (posting not allowed on this list)


I don't think that can be read as "MUAs should override Reply-To with
the List-Post value," which is probably why they don't.

> 
> It is the users client that is broken if it does not support list 
> replies correctly in this case.
> 
> Because this reply-to is changed "reply all" does not work, and I have 
> to manually add addresses.  I agree that maybe mdk is making the best of 
> the current bad situation, but if mdk changed the list policy, this 
> would mean all the email clients got fixed to follow those darn RFC's! 

I'd say everything's in compliance with 2369 there. To me the big
question is why to use Reply-To? I'm of the impression that it was
originally intended to support sending mail from account A when you want
to receive mail at account B. When account B is easily reached via
webmail, ssh, &c, and account A can easily be configured to forward its
mail to account B, I can't see why anyone would still want to do it this
way. But then, I don't see why people do a lot of things, so oh well.

> Which is how it should be. We did not end up where we are here by 
> changing standards.

Err... whither RFC 822? Oh yeah, obsoleted by 2822. Standards are only
standard because a majority of people agree to treat them as such, which
will only happen while the standard meets most of the needs of those
people. Needs change, the people with clout to make decisions change,
and standards therefore change to.

> 
> Best regards
> 
> JG
> 
> Jack Coates wrote:
> > <rant>
> > This is a religion issue, really. I usually try to avoid those and live
> > quietly with my choices, but this one bugs me because it causes either
> > needlessly duplicated mail or replies to questions to be
> > unpublished/unarchived.
> > 
> > The RFCs for mailing lists and many MUA authors/contributors feel that
> > mailing lists should not munge REPLY-TO because the end-user and MUA set
> > it and no other authority should be able to override that desire.
> > 
> > The administrators of and frequent contributors to mailing lists love
> > reply-to munging because it prevents needless duplication of mail and
> > helps to keep discussion threads in the mailing list, where they can be
> > archived and publicly posted.
> > 
> > On the one hand: pedantically correct behavior; on the other:
> > rule-bending for the sake of practical usage. The pedantics will rightly
> > point out that workarounds exist. In order to avoid seeing the needless
> > duplication of email, simply have every user of the mailing list set up
> > their own Unix mail server where they can install procmail and configure
> > it to find and delete duplicated email. In order to make sure that
> > everything is archived simply instruct all list users to always use
> > reply-all, at which point another set of people is going to get upset
> > because they're getting duplicate messages, at which point everyone else
> > flames them for not have their own Unix mail server and procmail setup
> > :-)
> > 
> > The best solution? Removing reply-to functionality from MUAs is tempting
> > but impractical; even though it is almost an anachronism in today's
> > world of ubiquitous email services, those who rely on it do rely on it.
> > Removing reply-to munging from MLM software would represent a pretty
> > ugly choice for the reasons above. (Hmm, in light of the ongoing
> > discussion of Mandrake's money problems, would they be happy about a
> > two-fold increase in the amount of email traffic? I know I wouldn't be.)
> > Changing the standard so that MLMs are allowed to munge reply-to but
> > MTAs are still prohibited? Sounds reasonable to me, and no one has yet
> > given me a valid reason not to (which doesn't mean that it doesn't
> > exist).
> > 
> > So in my opinion, it is not mdk's config which is broken, but rather the
> > standard which they are rightly not adhering to; just as, in my original
> > example, anyone who fully adheres to the IP RFC's subnet mask guidelines
> > needs to have their head examined.
> > </rant>
> > 
> > 
> > Jack
> > 
> > On Thu, 2002-12-26 at 17:51, J. Grant wrote:
> > 
> >>is it really broken? The reply-to should not be changed/added by the
> >>list.  It is the mdk config problem I believe.
> >>
> >>JG
> >>
> >>Jack Coates wrote:
> >>
> >>>Argh, another broken reply-to... (yes, I know it's RFC-compliant to do
> >>>this... it's also RFC-compliant to have a non-contiguous IPv4 subnet
> >>>mask and you don't see people doing _that_ little bit of insanity do
> >>>you?)
> >>>
> >>>On Thu, 2002-12-26 at 01:55, Colin Jenkins wrote:
> >>>
> >>>
> >>>>Hi all ,
> >>>>I have asked this question on the newbie list, but have had no luck so
> >>>>far....
> >>>>The script below works ok from the command line but when I run it as a
> >>>>cron job, it starts ok, but stops after backing up a few directories.
> >>>>Any ideas what I'm doing wrong? is it a bug with cron?
> >>>>btw, I'm using mdk9 and the files being backed up are on an nt server,
> >>>>but have had the same problem backing up an xp box.
> >>>>I had the same problem with drakebackup, tar and cp
> >>>>
> >>>>#!/bin/sh
> >>>>smbtar -s elendil -t /dev/st0 -x "stuff1" -v -i  -X System\ Volume\ Information
> >>>>mt -f /dev/st0 offline  
> >>>>
> >>>
> >>>
> >>>usually this sort of error is due to differing environment or
> >>>permissions. If it's a user's crontab ($crontab -e) then you need to su
> >>>to that user and debug from there. If it's root's crontab (#vi
> >>>/etc/crontab) then make sure root can run it from command line.
> >>>
> >>>Another possibility is that the network is fine when you're debugging,
> >>>but congested by other traffic when your cron job runs. Try doing
> >>>something less sensitive to network issues, like rsync'ing to a temp
> >>>directory a couple of times, then tar'ing that temp directory to the
> >>>tape.
> >>>
> >>>
> >>>
> >>>>-- 
> >>>>regards,
> >>>>Colin        
> >>>>
> >>>>mailto:[EMAIL PROTECTED]
> >>>>
> >>>>   ________________________________________________________________________ 
> >>>>8:00pm up 8 days, 3:46, 2 users, load average: 0.00, 0.00, 0.00
> >>>>No matter who you are, some scholar can show you the great idea you had was had 
>by someone before you.
> >>>>..registered linux user #223862 ..
> >>>>  _________________________________________________________________________ 
> >>>>
> >>>>
> >>>>
> >>>>----
> >>>>
> >>>
> >>>
> >>>>Want to buy your Pack or Services from MandrakeSoft? 
> >>>>Go to http://www.mandrakestore.com
> >>>>
> >>>>
> >>>>------------------------------------------------------------------------
> >>>>
> >>>>Want to buy your Pack or Services from MandrakeSoft? 
> >>>>Go to http://www.mandrakestore.com
> >>
> >>
> >>
> >>----
> >>
> > 
> > 
> >>Want to buy your Pack or Services from MandrakeSoft? 
> >>Go to http://www.mandrakestore.com
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>Want to buy your Pack or Services from MandrakeSoft? 
> >>Go to http://www.mandrakestore.com
-- 
Jack Coates
Monkeynoodle: A Scientific Venture...


Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Reply via email to