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 reason, then use maildrop or seive. They are all relativly the same. > > Now here's the tricky part, that's not in rfc2505: [Snip out a whole big ugly, here!!!] > Yes, I have some thoughts. What you're describing is a sysadmin's > worst nightmare, and I for one want no part of it. It's a great > example of overengineering a reletively simple problem. The best > solution for dealing with spam always was and always will be to press > the delete key. Anything else runs the risk of losing legitimate > mail if it's not configured meticulously, and if you ask me what you > describe introduces enough aditional complexity to make it very much > not worthwhile. Beyond the complexity issue, which is bad enough, this proposal introduces several new points of failure, as well as several points of risk, that, IMNSHO, just aren't worth it. Besides, it's time consuming, wasteful, risky, and probably ineffectual. If a sysadmin has to spend their entire day replying to e-mails just to say that they will accept the e-mail, you have just invented the first DDoS attack against a human being!! Well, second, actually. The first being stupid questions from the marketing department ;-) It just seems like a lot of work, a lot of risk, and a lot of time spent for very little return. All they have to do is spoof their mail and/or IP address (Oh, like *THAT's* hard). Well, I suppose this counts as an opinion. C-Ya, Kenny --------------------------------------------------------- "There's nothing you shouldn't speak of if you've got something to say, and there's no one to be scared of, just get them out of your way." -- The Alarm ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
