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 based e-mail currently
stored on their desktop in a local folder of their choosing :)
>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!!
Well, I think that you're taking this database thing a little too
literally. He mentioned something like MySQL as an example only,
however, sendmail already has built in capability for database query
and already uses hash table databases, NIS, and LDAP. It would be a
trivial thing to extend sendmail to use any of these
db lookup mechanisms for 3 more tables, and it wouldn't impact
performance too much. Complex sites are already scanning every single
e-mail, incoming and outgoing for virii, why not add a table lookup?
If you're that concerned about performance, you can always split your
server architecture up into mutliple servers, which most complex sites
already do for exactly this reason.
And if that's too complicated for you, upgrade your mail server from
that crufty old 25Mhx/386 w/ 16MB and 200MB HD to something more
recent :)
> I spend hours a day responding to e-mail.
Well yeah, but that's because you're a trained sysadmin who's boss
thinks that that's actually what you're *supposed* to be doing. You
can't pull that crap with us, we're the ones who taught *you* that
trick ;)
>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...
Well, presumably you'd be able to create a list of auto-accept
addresses up front. Any subsequent additions would likely and
hopefully be infrequent. Though it might be a lot better to have
a accept-by-default policy unless the address appears in a deny db.
This makes things tremendously easier on everyone's part, and makes
it a little faster for the db table look-ups.
>I don't have time for that.
That's only because you don't have a desk close enough to the coffee
maker. Move one into your office, get them to give you an in-office water
tap (heck, have them build you an en-suite while they're at it ;) and
that'll save you hours a day!
>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.
What new points of failure? Everything he proposed is already built
into sendmail, it's just a matter of being able to take advantage of
them in a different manner than they currently are able to. As a
matter of fact, I bet it's not even that tough to do. The hardest
part is setting it up so that it's easy for the user to take
advantage of that's secure. But with a little ingenuity, even that's
not too difficult.
As far as risk, the worst thing I see is that a user might accidently
add an address to the deny table and they miss some legitimate e-mail.
OOPS! So, the user will blame the sysadmin, the sysadmin will point
out that said user is an idiot and shot themselves in the foot, the
user will get mad and hate the sysadmin, and life will continue on as
normal.
>Besides, it's time consuming, wasteful, risky, and probably ineffectual.
I don't see it as time consuming, wasteful, or risky. Whether or not
it's effevtive is completely in the eyes of the user.
>If a sysadmin has to spend their entire day replying to e-mails
It was a suggestion of how it *could* work. No one said it had to,
and no one ever said that you would be *required* to use these
features :)
>It just seems like a lot of work, a lot of risk, and a lot of time
>spent for very little return.
Man, you really like repeating yourself, don't you :)
>All they have to do is spoof their mail and/or IP address
>(Oh, like *THAT's* hard).
Yeah, but the first have to know to what they're going to change it.
If the return error code was innocous enough, they'd likely not
realize they're being blocked on a "From: address basis".
I think it would be a mistake to reply back to them saying something
like, "Hey, we deleted your message because the person you sent this
spam to has this From: address on their spam-filter list!"
The best policy would to not reply to them at all. That way they no
nothing. They assume you got their spam, but you've confirmed
nothing either way to them. If you reply with an error, the error
message might tell them something you don't want them to know.
I refer to this as the "black hole" theory of e-mail. Deny your
enemy all information, not just that which is harmful to you, since
knowing what's not harmful to you may just end up helping them figyre
out what is!
--
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.
*****************************************************************
