Re: sending with perl instead of MTA?
At 9:27 AM +1000 2002/08/12, Cameron Simpson wrote: The problem is that the home machine will either stamp unqualified addresses (cameron) with a bogus domain (eg localhost.localdomain on unmodified redhat boxes) or with the ISP's domain (if you've so configured it), which is a LIE, because most accounts on your machine either don't exist in the ISP or collide with other users. See my previous messages. This is not a problem, if you have configured the box correctly and, more importantly, you have configured mutt correctly. the crucial point most people seem to miss here, aside from the whole lack-of-domain thing, is that if you're going to use you local machines mail system, _all_ email clients must be able to use it (without special config hacks like my_hdr), and all local accounts must be able to use it. Again, that's not necessarily true. Even if it is true, with proper configuration, you can support this. That's the whole point! A single user single client setup might as well speak directly to a legitimate SMTP service from one's ISP. That would be the preferred method, yes. However, it is not the only option. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: sending with perl instead of MTA?
At 9:22 AM +1000 2002/08/12, Cameron Simpson wrote: No. The outgoing headers include enough reply information for misdelivery to cause bounces to go into the ether, or to my ISP (_postmaster_ or suchlike at my ISP, not _me_) that this is the wrong approach. Not if you set your envelope sender correctly. You have complete control over this value, and if set properly, you can guarantee that all bounces go back to this address. That is, unless the MTA at the other end is seriously screwed-up, but then you can also control the other headers that might potentially be used for those bounces, to also ensure that they will go to the correct place. It is necessary that the first _mail_system_ that handle things be a valid standalone domain for this reason. Again, this is a fallacy. Unless you have been running Internet mail systems for many years and you really understand all the issues involved, you should not be arguing points like this with people who have been doing this sort of thing for a decade or more. So either one needs one's own domain and a full setup on the home box, or one needs to deliver directly to the ISP's SMTP service. That would be the preferred method, yes. However, there are alternatives that do not involve the creation of entirely new pieces of code being written by people who don't really know what they're doing. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: sending with perl instead of MTA?
for sendmail, so far it has only been able to asymptotically approach this goal, in part because sendmail has been adding new features in the meanwhile. While it is still a very good program overall (including the simplest and easiest-to-understand configuration file that I have ever seen in my life), there are a number of ways in which postfix is markedly inferior to sendmail. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Deleting mails older than 20 days after shutting muttdown
At 12:57 PM +0200 2002/08/12, Oliver Fuchs wrote: I want to delete all messages in a mailbox older than 20 days automaitcally after I close/shutdown mutt. Can this only be done via a macro or is there another functionality? If mutt isn't running, then I don't think there's any way to configure mutt to do this. Why not try a regular cron job instead? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Updating folders on a server, both remotely andoff-line?
At 2:26 PM +0200 2002/08/09, Ulrich Keil wrote: One way to to this is to use the coda file system www.coda.cs.cmu.edu which is a replacement for nfs and allows disconnected operations on your folders. Sorry. I've had really bad experiences with AFS and similar alternatives to NFS. NFS is pretty much ubiquitous, and supported on almost all OSes I know of. I don't think that you can say the same for Coda. Moreover, you have to change both the client and the server to support it, and you don't have any commercial-grade rock-solid implementations, as you do with NFS servers from Network Appliance, Auspex, EMC, etc I'm sure that Coda is fine in academic environments, where you get paid almost nothing and therefore since your time is virtually free there are effectively no administration overhead costs, and where no one really cares if an entire system is toast and all those students lost all their work, because they don't get paid anything at all and therefore their time has absolutely no cost at all. It's probably also okay in commercial shoe-string budget situations, where you can afford to spend lots of extra time babysitting it, because you have no alternative. However, I certainly wouldn't recommend that anyone use it. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Updating folders on a server, both remotely andoff-line?
At 11:50 AM +0100 2002/08/09, Bruno Postle wrote: Consider putting your mail on an imap server (courier-imap and cyrus are good) and using that for remote access. You can then use a tool like isync (there are others) to synchronise your laptop mailfolders with your imap mailfolders. Cyrus has its own one-file-per-message mailbox format, which uses file locking (and therefore makes it unsuitable for use on NFS). The folks at MessagingDirect took that code and pulled the file locking into an NFS-friendly database, so that you avoid all the extra synchronous meta-data operations that are performed with Maildir, and also avoid trying to use file locking on NFS. Unfortunately, they don't sell this product directly -- instead, you have to buy it from one of their OEM partners. It turns out that Sendmail is one of the best known OEM partners, and they include the Messaging Direct technology in their Sendmail Advanced Message Server. However, if you are unable or unwilling to use a commercial message-store, then your the only IMAP server I know of that supports Maildir is Courier-IMAP. IMO, I prefer UW-IMAP for simplicity and backwards compatibility or Cyrus for maximum performance, but if you're doing IMAP using Maildir on NFS (and you can't/won't use commercial products), then Courier-IMAP is really your only choice. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Can mutt set envelope at message-compose-time?
At 11:50 AM +0200 2002/08/03, Sven Guckes wrote: you can only set or unset the envelope_from variable - but not set what goes into the header. this is MTA stuff. The MTA doesn't touch the headers (with the exception of adding suitable Received: headers). So far as the MTA is concerned, headers are part of the message body. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Can mutt set envelope at message-compose-time?
At 6:45 PM -0400 2002/08/03, Melvin Q Watchpocket wrote: But if you use the MTA (sendmail in this case, and in many cases) to create an envelope header that's gonna be different from a message's From: header, (by doing 'sendmail -f'), then it (the MTA) has to at least touch the envelope header. There is no such thing as an envelope header. There is the envelope sender (the address specified in the MAIL FROM: portion of the SMTP dialog), the envelope recipients (the address or addresses specified in the RCPT TO: portion), and all header data comes after the sending MTA says DATA. Note that the envelope sender and recipients may have absolutely nothing in common with the From: header or any of the recipient headers. Which still makes setting what goes into that header essentially MTA stuff, I'd think, even though in most other respects (the received headers excepted) it's correct to say that headers are indeed part of the message body so far as the MTA is concerned. No. Absolutely not. If you knew anything at all about MTAs, you would not be making this claim. Once again -- the envelope information and the header information are totally separate. As far as the MTA is concerned, the header information should be sacrosanct, and not touched in any way (with the sole exception of adding the appropriate Received: header). Now, if you want to claim that mutt should allow you to modify the envelope information at the same time it allows you to modify the message headers, that is a different matter -- but don't confuse the issue by thinking that these two necessarily have anything at all to do with each other. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Weird characters - from OE?
At 10:22 PM +0200 2002/08/02, Sven Guckes wrote: you found a Korean garbage to text converter! congratulations!! finally - some use for OE! :-) I think it started out life as a Korean text to garbage converter. So it makes sense that only OE would be able to convert the gibberish back to text. Hmm. Maybe it's actually a Korean text encryption device? Or maybe a Korean text steganography device? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Solaris 7 x86 mutt package?
On Thu, Aug 01, 2002 at 11:11:34AM -0400, Ken Weingold wrote: Does anyone know if there's a mutt package for Solaris 7 x86? I don't see it on the list at http://www.sunfreeware.com/sol7rightintel7.html. Are there any other sources of Solaris packages of this sort? -- \[EMAIL PROTECTED] Brad Knowles [EMAIL PROTECTED] \ ASM Lithography, BV | Senior Consultant \ \ITMS Unix Competence Center | Snow, BV \ / Room 02.D.2085 | http://www.snow.nl |\ \/ /De Run 1110 | Koeweistraat 12 | \ / 5503 LA Veldhoven | 4181 CD Waardenburg | | The Netherlands | The Netherlands | | | Tel: +31 418 653 333 \ | /| Fax: +31 418 653 666 \ |/
Re: mutt + procmail + nfs...
On Wed, Jul 31, 2002 at 06:46:55PM +0200, Ralf Hildebrandt wrote: however, this is the dreaded mailbox on nfs issue. do procmail and mutt play nice on nfs? If you use Maildir, yes. Maildir has the problem of trading NFS locks for excess synchronous meta-data operations, and synchronous meta-data operations are something not dealt with well by most NFS servers (at least, anything short of Auspex, EMC, or NetApp). There are alternative solutions. For POP3-based systems, Nick Christenson led the way in his Earthlink paper, _A Highly Scalable Electronic Mail Service Using Open Systems_, which you can find at http://www.jetcafe.org/~npc/doc/mail_arch.html. IIRC, they used file creation tricks (just like Maildir does), but instead of breaking out each message into a separate file, they used the v7 mbox file format. You still have some synchronous meta-data issues to deal with, but not nearly on the scale of Maildir, and even those can be at least partially addressed (start with http://www.shub-internet.org/brad/papers/dihses/lisa2000/sld065.htm of my invited talk _The Design and Implementation of Highly Scalable E-mail Systems_, which I presented at LISA 2000). For IMAP-based systems, you would need to use the message store engine from MessagingDirect (they hacked Cyrus so as to pull the locking out of the filesystem and into an NFS-friendly database). Alternatively, you would need to hack Cyrus to pull the file locking out into an NFS-friendly database. You may also be interested to read the book _Sendmail Performance Tuning_ by Nick Christenson -- to be published on September 20, I believe. While the title of the book is about sendmail, I believe that it covers more than just this one program. Disclosure: I was a technical reviewer of this book and Nick was my co-author for the talk I gave at LISA 2000, so I may be a bit biased. ;-) -- Brad Knowles [EMAIL PROTECTED] Senior Consultant for Snow bv ASM Lithography bv + ITMS Unix Competence Center + Room 02.D.2085 De Run 1110 + 5503 LA Veldhoven, NL + GSM +31 654 344 596
Re: Packaging mutt script, was: muttprofile (new)
At 2:27 PM +0200 2002/07/31, Marco Fioretti wrote: Both personally, and as leader of the RULE project (see below) I would really appreciate something like this, i.e. one package, to be eventually delivered as .rpm, .deb, .tgz, whatever, that collects *all* these things. You're welcome to take on that task for whatever OSes projects you see fit, but I don't think that it's fair to ask the mutt maintainers to do this for every OS under the sun. No, the original mutt tarball should stick to only code that is specific to mutt, and if it requires or can make use of anything else, that should be made clear in the documentation and in the configure script. Myself, I volunteer to test/maintain the RPM version for RULE! That's wonderful! Thank you. Anyone else? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Multiple accounts with mutt?
Folks, I've gone through the FAQ and searched for answers to this question, but still haven't been able to find anything that was able to help. What I'd like to do is use mutt at one place to allow me to access my mail for various accounts (at the moment, one personal account via POP3, one work account via IMAP-over-SSL, and one local customer account). It's not hard to figure out how to get mutt to handle any one of these accounts, but how can I get it to handle all three? Any help or advice you can provide would be appreciated. -- Brad Knowles [EMAIL PROTECTED] Senior Consultant for Snow B.V.http://www.snow.nl/
