Re: rfc2505
RFC's aside, wouldn't it be great if it were *illegal* to send spam w/o some sort of header(s): X-Unsolicited-Bulk-Mail: ... and they could only remove that header if you replied back somehow saying "yeah, it's ok to send me more of your crap". One could imagine even more structure in the required headers, e.g. AD category (Diet, XXX, ...) and even the sender's ID. I see some spam coming in these days where they at least say at the bottom that they are complying with Calif + other states Anti-spam laws where they provide you with way to unsubscribe... I say let's take it to the next level where being able to automatically filter (e.g. to separate folder or to /dev/null) is required by law. I dunno how practical this would play out... Anyone know of any discussion going on in this vein? * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: rfc2505
This is quite long. My apologies. After only two responses, I found I had a lot to clarify and more to add to the debate. I knew it would be controversial, but I think it's a direction we need to go. We need to at least have this capability. Every MTA in the world doesn't have to implement it, but I believe we need a solution (or multiple solutions to choose from) to implement if we so choose. DM: Derek Martin KL: Keneth Lussier [My intro about user controlled SMTP rejections snipped] DM> This is difficult, if not impossible, to acheive. At least, if I DM> understand you correctly. The SMTP gateway is a mail TRANSFER agent, DM> and knows nothing about what the client wants or doesn't want, BY DM> DESIGN. The exception is probably MS Exchange, which I don't know DM> much about, and wouldn't ever use/manage unless I were starving to DM> death. I think I'ld flip burgers before managing an Exchange environment :-). Anyhow, sendmail already provides ways of filtering based on To: or From: fields in the access database. All that's needed is to combine the two to provide the functionality I'm talking about. That and, of course, a way for recipients to securely control it without compromising the entire mail system. Impossible? I doubt it. Difficult, yes, but that's why I posted to this group -- to get some tips. Whether or not it was originally by design that the MTA knows nothing about the client (client referring to end user in this case) wants or doesn't want matters not. The mere existence of rfc2505 (particularly section 3.2) indicates that I'm not the only one that wants that to change. KL> There are ways of doing this, but they are not clean, nor are they secure. KL> Most major, and some minor, MTA's allow the use of "Black List" lookups. KL> Your MTA can consult things like the RBL to see if mail is from a black KL> listed domain, sender, etc. One of the problems with this is that your MTA KL> is now depending on someone else's judgement, and someone elses security. If KL> the RBL is ever cracked, it would wreak havoc with the mail systems that KL> use it. Even depending on my own judgement as a sysadmin is not so good. I want to give the choice to individuals. I have heard the RBL is actually becoming less and less popular. They've taken more questionable actions over recent years and it still doesn't give the end user the choice. It doesn't even give organizations the choice. It's all or nothing. Vipul's Razor is a great idea as it deals with specific messages, but it remains to be seen how effective it is. Still, it only deals with messages already delivered through SMTP -- not what I looking to do. I want it rejected before being sucked into my servers. [My criticism of mail filtering tools snipped] DM> This is not a shortcoming in procmail. It's a problem with your DM> corporate policy. If you're going to lay blame, please do so where it DM> belongs... DM> DM> A workaround for this problem is to run fetchmail to get your mail DM> from your IMAP server, and filter it with procmail locally. And DM> IMNSHO, it's a much cleaner way than what you're about to suggest... As Paul L. mentions in a later message, there's no problem with this as a corporate policy. There are many arguments for sealed servers, but I believe that it's beyond the scope of the points I'ld to make. (I'm happy to discuss it, but I just think it's a different, though related, discussion.) I'm not really 'blaming' procmail, anyhow. It does what it does well. Problem is, that it's not designed for filtering using only IMAP. I personally cringe at alternating my access of an INBOX between IMAP and procmail or any other non-IMAP access. Leaving Cyrus out the picture for the moment, let's take a look at UW-IMAP. Upon accessing a folder, it puts a dummy message in the front of the file with some folder information. It looks pretty innocuous and I doubt it would ever be a problem deleting it and letting UW-IMAP recreate it, but I just don't trust letting non-techie users do stuff to IMAP folders unless it's through IMAP only. It's comparable (though not as bad as) to modifying an rcs file by hand. I'm not looking for workarounds, I'm looking for real solutions. Sieve, IMO, is actually a much cleaner solution. It allows me to shut my desktop down (if I so choose) and still have stuff faithfully filtered as I've specified. And I can then access my folders from home through a VPN without having make sure my procmail filters are in sync between home and work (which *I might not want*, anyhow). KL> Filtering should always be done at the client side, IMO.It's the user KL> that chooses the client, and the user that wants the filters. There KL> is no reason to put extra strain on a mail server, especially if it KL> is a high traffic environment, by asking the MTA to think for you as KL> well. I respectfully disagree. I've wanted server-side filtering for a long time. I was pleased to
Re: rfc2505
In a message dated: Mon, 24 Dec 2001 09:25:42 EST "Kenneth E. Lussier" said: >> > It's also been my criticism of most mail filtering tools (including >> > procmail). Procmail filters it independent of MUA, but it doesn't >> > help much with sealed servers running IMAP -- you need permission to put >> > your procmail filters on a server you don't have access to. >> >> This is not a shortcoming in procmail. It's a problem with your >> corporate policy. If you're going to lay blame, please do so where it >> belongs... > >I have to disagree here. I don't think that the corporate policy is wrong, I t >hink that it is a matter of perception. Personally, I don't want my users to h >ave shell access to the mail server. It prevents them from doing things like r >unning Pine or Mutt on the server. Especially if they are on a windows box run >ning Exceed. Then they just click the "X" instead of actually logging out. >... > >> A workaround for this problem is to run fetchmail to get your mail >> from your IMAP server, and filter it with procmail locally. And >> IMNSHO, it's a much cleaner way than what you're about to suggest... Well, I can see calls for both scenarios. In a corporate environment, some users might want to run their mail client on the server rather than their desktop for several reasons. For example, I use exmh as a mail client which has no/poor support for IMAP/POP. I *could* run fetchmail on my desktop, but that's actually more of a pain because: a. the mail server is on a much better UPS than my desktop. If I'm dependent upon my desktop for e-mail, there's actually a greater chance of failure for me. b. If I'm running things through procmail, having to bring it to my desktop first is an extra step I don't want to deal with, and, if my desktop is down, then all mail sits in /var/spool/mail unfiltered. I may not want this. I encrypt some mail immediately upon receipt. If the mail doesn't go through procmail, it sits in /var/spool/mail unencrypted! Bad. c. If I need to depend upon vacation for something, I need to do this on the mail server itself (see a.). In this case, either my procmail filters need to be there so I can auto-respond to mail *after* it's been filtered. I don't want to vacation mailing lists, or even most internal aliases! So, I can either read mail on my desktop or on the server. The server is most convenient, since I can rely on that server being up a much higher percentage of the time than I can my desktop. However, for an ISP, I want no one on my mail server. I want only IMAP or POP3 access to e-mail. So, in that case, Paul I.'s idea about having server side filtering capability is a great idea IMO. I don't believe that it would require anything overly complex however. Something like webmin with a procmail-capable interface should be fine. This also obviates a requirement for any database that the MTA would be dependant upon. Procmail can use flat file lists easily enough. Additionally, since procmail has the ability to run external programs, you could easily set up a db query for your users if you wanted to. With a web interface and procmail all things are possible. Additionally, if you're concerned about security, you could have the webserver which configured the procmail scripts exist on an entirely different server than the MTA. Then you can just get the .procmailrc's over to the MTA server however you wanted to, ssh, rsync, etc. You could even have the 2 systems share a common file system where the MTA server could only mount read only, but the web server mounted it read-write. That makes things a little safer, and a lot quicker. You also don't have to rely upon things like cron, open ssh passphrases, etc. >> > Most other filtering mechanisms are client specific. I'ld like to >> > be able to switch clients freely and not have to port my filters to >> > each and every client. >> >> Procmail does not suffer from this problem. Agreed, I've used at least a half dozen different mail clients over the past 8 or so years, and the only filtering program I've ever used is procmail. >Cyrus, Qmail, and Courier all use Maildir as their default, but they also >support mbox format. If you use Maildir format, and you need to read your >mail in an emergency, use vi. Tossing in the Ob-Emacs vote here ;) Yeah, I have to agree with that statement. I mean isn't that one of the main advantages of something like Exchange/Outlook? Besides it's obvious superiority to all other e-mail client/server combinations, the one major feature I hear from ever single Exchange/Outlook user is that when that server crashes (and you know, that's quite a rare occurence!) end users are eternally grateful that they can just whip up NotePad and read that plain ascii-text bas
Re: 2.4.3 issues? (was Re: Adaptec 2940UW)
In a message dated: 23 Dec 2001 22:38:53 EST "Kenneth E. Lussier" said: >Does anyone know of any SCSI issues with 2.4.3? I dropped back to >2.2.20, recompled with SCSI, SCSI generic, scsi tape, etc., and the tape >drive works fine now. My kernel configs are identical. Don't know of any, but personally, I'd be using a > 2.4.15 kernel. Everthing < 2.4.14 I think was subject to VM-of-the-week problems, and 2.4.15 I think had a security issue (not sure, check the CHANGELOG). -- Seeya, Paul God Bless America! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: rpm question
I have found rpm2cpio useful. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: rfc2505
Quoting "Derek D. Martin" <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > This is difficult, if not impossible, to acheive. At least, if I > understand you correctly. The SMTP gateway is a mail TRANSFER agent, > and knows nothing about what the client wants or doesn't want, BY > DESIGN. The exception is probably MS Exchange, which I don't know > much about, and wouldn't ever use/manage unless I were starving to > death. There are ways of doing this, but they are not clean, nor are they secure. Most major, and some minor, MTA's allow the use of "Black List" lookups. Your MTA can consult things like the RBL to see if mail is from a black listed domain, sender, etc. One of the problems with this is that your MTA is now depending on someone else's judgement, and someone elses security. If the RBL is ever cracked, it would wreak havoc with the mail systems that use it. > > It's also been my criticism of most mail filtering tools (including > > procmail). Procmail filters it independent of MUA, but it doesn't > help > > much with sealed servers running IMAP -- you need permission to put > your > > procmail filters on a server you don't have access to. > > This is not a shortcoming in procmail. It's a problem with your > corporate policy. If you're going to lay blame, please do so where it > belongs... I have to disagree here. I don't think that the corporate policy is wrong, I think that it is a matter of perception. Personally, I don't want my users to have shell access to the mail server. It prevents them from doing things like running Pine or Mutt on the server. Especially if they are on a windows box running Exceed. Then they just click the "X" instead of actually logging out > A workaround for this problem is to run fetchmail to get your mail > from your IMAP server, and filter it with procmail locally. And > IMNSHO, it's a much cleaner way than what you're about to suggest... > > Most other filtering mechanisms are client specific. I'ld like to > > be able to switch clients freely and not have to port my filters to > > each and every client. > > Procmail does not suffer from this problem. Filtering should always be done at the client side, IMO.It's the user that chooses the client, and the user that wants the filters. There is no reason to put extra strain on a mail server, especially if it is a high traffic environment, by asking the MTA to think for you as well. > > This is where sieve comes in. I comes as part of cyrus-imapd and > > does all it's filtering before delivery -- i.e.: it gets delivered > > to a folder of the recipients chosing and doesn't require login > > access to the imap server. It has it's own protocol for transfering > > sieve scripts and can even notify a running IMAP client of new mail > > in any IMAP folder. I haven't tried any of this yet, but it looks > > promising. All we need now is for it to be adopted more widely, > > including any easy way to download, modify, and upload sieve scripts > > using your mail client of choice. > > Unless I'm mistaken (which is very possible), Cyrus mail tools require > the use of Maildir format mailboxes, which just aren't supported all > that well. True, a lot of major mail clients support it, but a lot of > popular clients don't. And if you need to read mail with mailx in an > emergency, forget it. Cyrus, Qmail, and Courier all use Maildir as their default, but they also support mbox format. If you use Maildir format, and you need to read your mail in an emergency, use vi. > > This seems to me to be making the process of delivering mail to a user > entirely too complex. The LAST thing I want, as a system > administrator, is dependence on a database program to make delivery of > mail work. When you do this, you've probably increased the complexity > of mail delivery by more than 100%, given how basically simple > sendmail is. That means headaches for me, and I don't like it. I 100% agree here. Making your MTA depend on a database backend just seems suicidal. Not to mention the performance hit you would take if you have a high traffic environment. If every single piece of e-mail requires a database query, you will slow the mail server down considerably. Especially if you have tables with thousands of entries, which you would have to have if there needs to be an entry for everyone that you *WILL* accept mail from. Besides the performance hit to the mail server, just imagine the performance hit the sysadmins would take!! I spend hours a day responding to e-mail. Now, imagine having to respong to an e-mail saying that you will accept mail from this person, then waiting for their e-mail, then responding to it... I don't have time for that. > You can even configure procmail to send the sender bounce messages, if > you really want to. YAY! You can configure procmail to do pretty much everything. If you just really don't like procmail for some odd reas
