On Thu, Dec 27, 2001 at 01:42:15PM -0500, Bob Bell wrote: > On Mon, Dec 24, 2001 at 07:45:22PM -0500, Paul Iadonisi <[EMAIL PROTECTED]> >wrote:
> What is your objection to an alternative interface to the procmail > rules? Here at work we have a web-based interface to edit procmail > rules. I can't find a URL for that interface, but I found a similar > project at http://www.uvm.edu/opensource/?Page=procbuilder.html. This > should allow you to edit your procmail rules without having shell access > to the server. It's clearer when considering cyrus-imapd as an example. There are index files for each folder directory. These, presumably (I could be wrong) wouldn't get updated if procmail were to dump files into the directory. Can procmail actually deal with the Cyrus mailbox format (similar to Maildir). The safest way to handle moving messages from folder to folder is by sticking to the IMAP protocol for all operations. I would think that procmail would need access to the user's password to do this? If I'm not mistaken, sieve actually gets wired into the local delivery process which in this case is cyrus-imapd, so the index files for each folder will get updated correctly. Of course, I could be blowing smoke, too. :-) From the reading I did on sieve, I thought it was similar to procmail. There was some comment not trying to do too many new things and basing the language on existing filtering languages such as procmail. In the end, I may find that procmail is, in fact, viable for the kind things I'ld like to do. What I would like to see, however, is a protocol for transferring procmail scripts back and forth between the MUA and mail server that can easily be worked into existing mail clients (possibly requiring source modifications). The sieve standard has defined a protocol which I think is already in use by the non-free Mulberry MUA. > Additionally, I have to question how effective your method of > filtering would really be. Initially, it sounded great, but then I had > the consider the likelihood that it would actually deny spam. I don't > know how many messages that I've received actually use the same return > address, but I would hazard a guess that very few do. Without some sort > of pattern to the return address (or "MAIL FROM:"), I would think that > my inbox would simply be cluttered with messages from the mail server > about rejecting/accepting a message/sender instead of the actual spam, > which would like actually consume *more* of my time to process. This is why I want to be sure to allow for a non-email form of notification, such as maybe a web interface or a protocol API that can be called by the MUA to give a list of pending message requests. Presumably, after a short period of time of expanding one's whitelist (including mailing list authorizations), most of the requests coming in should be spam. They should expire after a short period if the user is online (longer if not online) and should automatically be rejected if the user doesn't explicitly enable the mail to come through. This could give a permanent SMTP failure so that the mail *does* bounce, but not bother adding the sender's address to the user's black list since it's probably forged/false address anyhow. In other words, do these steps in this order: o Prime your white list with known okay senders. o Watch the mail requests from those not on your white list closely for the first week or two, enabling anyone you may have forgotten. o Once you're pretty sure that your whitelist is fairly complete, switch to checking the list once per day. o Just ignore anything that doesn't look familiar. If you're really not sure, just accept it *without* adding it to your whitelist. If it's spam, just resort the delete key, or launch your favorite DoS attack against the sender's domain (kidding). A couple things to keep in mind are: o A rejected mail from a valid sender *will* be bounced alerting the sender of the fact that you did not receive the mail. He'll either resend the mail, or call you (assuming, of course, he knows what a bounce is ;-)). o This is clearly not that good a solution for [EMAIL PROTECTED], but it might for [EMAIL PROTECTED] if it's primed with an appropriate whitelist. > > If an employee really want to reject all mail from the CEO, he can do > > that himself, later. > > Hmm, which makes me wonder about "I never got that email" excuses in > such a setup... :-) -- -Paul Iadonisi Senior Systems Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
