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]>
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! Which is how it should be. We did not end up where we are here by changing standards.
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
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
