Bolwerk wrote:
> Hi, I'm using FreeBSD 6.2 with postfix/postfix admin/courier imap+pop3.
> Accounts are stored in a MySQL database, and I use maildirs stored in
> /var/vmail/
>
> We're in the process of migrating our mail accounts over from Windows
> Server 2003 running IMail. As of now, we have a few hundred accounts,
> but expect significantly more in the future.
>
> What I'd like to do is set up a decent anti-spam solution now, while
> we're small --- we already get a lot of it.
>
> I'm open to other ideas, but what I have in mind right now is to set up
> something along the line of a spam filter that dumps junk mail in a
> folder called "spam" or "junk" for the users to check if they want to. I
> would prefer this to outright deleting spam, just in case something
> legit comes through. I presume that it wouldn't be heard to clean out
> such a folder; if the software doesn't already do it, I imagine a single
> crond script could be written to traverse the directories and delete
> messages older than 15 days during off-peak hours.

Maybe not really what you are looking but anyway:

I am fighting spam for more than 7 years, mimedefang or amavis +
spamassassin and the like. Work great but not totally effective.

6 months ago I try spamd (from openbsd - /usr/ports/mail/spamd), it is
absolutely great.

My spam drop to ... say ... 0.1%!!!

give it a spin...

Henri
>
> Given my configuration, what might be the easiest way to do this? I've
> actually been a little overwhelmed by my options, and am admittedly a
> little new to administering mail with postfix.
>
> Thank you!

On Nov 10, 1:14 pm, Bolwerk wrote:
> Hi, I'm using FreeBSD 6.2 with postfix/postfix admin/courier imap+pop3.
> Accounts are stored in a MySQL database, and I use maildirs stored in
> /var/vmail/
>
> We're in the process of migrating our mail accounts over from Windows
> Server 2003 running IMail. As of now, we have a few hundred accounts,
> but expect significantly more in the future.
>
> What I'd like to do is set up a decent anti-spam solution now, while
> we're small --- we already get a lot of it.
>
> I'm open to other ideas, but what I have in mind right now is to set up
> something along the line of a spam filter that dumps junk mail in a
> folder called "spam" or "junk" for the users to check if they want to.
> I would prefer this to outright deleting spam, just in case something
> legit comes through. I presume that it wouldn't be heard to clean out
> such a folder; if the software doesn't already do it, I imagine a single
> crond script could be written to traverse the directories and delete
> messages older than 15 days during off-peak hours.
>
> Given my configuration, what might be the easiest way to do this? I've
> actually been a little overwhelmed by my options, and am admittedly a
> little new to administering mail with postfix.
>
> Thank you!

http://www.mailscanner.info/
http://mailwatch.sourceforge.net/doku.php

On Sat, 10 Nov 2007 14:14:18 -0500, Bolwerk wrote:

>Hi, I'm using FreeBSD 6.2 with postfix/postfix admin/courier imap+pop3.

But, but...above it says you are using gmail.com

> Accounts are stored in a MySQL database, and I use maildirs stored in
>/var/vmail/
>
>We're in the process of migrating our mail accounts over from Windows
>Server 2003 running IMail. As of now, we have a few hundred accounts,
>but expect significantly more in the future.
>
>What I'd like to do is set up a decent anti-spam solution now, while
>we're small --- we already get a lot of it.
>
>I'm open to other ideas,

I'm just curious...why not monkey see, monkey do...since you are using
Gmail, why not Gmail for everyone else in your organization? Did you
know that Gmail also offers a corporate version of their service that
allows you to use your own domain name and manage your user accounts?

>but what I have in mind right now is to set up
>something along the line of a spam filter that dumps junk mail in a
>folder called "spam" or "junk" for the users to check

a) You might be underestimating the size of the problem.
See: http://www.acme.com/mail_filtering/
He is talking about receiving 1 million plus spams PER DAY at just one
e-mail address that saturates his T1 line and...you have how many
e-mail addresses?

b) You might want to consider farming the problem out to an e-mail
filtering service like: http://www.postini.com/
In addition to them being very good at what they do (personal
experience as a satisfied customer), when you crunch all the numbers,
you might also find them to be very cost effective when compared to
the costs involved in supporting an in-house anti-spam infrastructure
as an alternative.


>if they want to.
>I would prefer this to outright deleting spam, just in case something
>legit comes through. I presume that it wouldn't be heard to clean out
>such a folder; if the software doesn't already do it, I imagine a single
>crond script could be written to traverse the directories and delete
>messages older than 15 days during off-peak hours.
>
>Given my configuration, what might be the easiest way to do this? I've
>actually been a little overwhelmed by my options, and am admittedly a
>little new to administering mail with postfix.
>
>Thank you!

Some tools you might want to look at:

http://postgrey.schweikert.ch/
- greylisting

http://crm114.sourceforge.net/
- filtering

http://www.openspf.org/
- Sender Policy Framework (to deal with botnets)

Begin <13jem0d3msl5a20@corp.supernews.com>
On Sun, 11 Nov 2007 14:29:02 -0500, Bolwerk wrote:
> jpd wrote:
>> For profit religion? I can think of only one, and a litigous one at that.
>> If I'm wrong please do tell.
>
> Quite wrong. The religion is not for-profit, and is fairly mainstream.
> The organization I work for, however, is a private company that sells
> a service of interest to members of that particular religious faith,
> without litigation and threats of cosmic reboot (to others).

Alright. :-)


[snippety]
> So, as it stands now: abuse@ and postmaster@ exist, but we don't post
> them on our site as mailto: links either. We also don't prevent anybody
> from sending to them, and they're in the headers of messages. Is that
> really a terrible thing?

abuse@ and postmaster@ don't need to be announced, as they're required
to have. It is probably a good idea to announce that you have general
contact email addresses (other than abuse@ or postmaster@) that are read
next to your contact form instead of just that form. What email address
you use for that or how you announce it is up to you.


>>> I'm not entirely comfortable with all out blacklisting, so I haven't
>>> enabled that firewall feature.
>>
>> You have to be very careful indeed to do that. [...]

I have to clarify something here. I ment blacklisting of entire blocks
on the router or dropping connections or the like. Blacklisting by dnsbl
is much more palatable, depending on what blocklist you use, and what
you do with the information. It still requires careful consideration, of
course.


[snip]
> Does greylisting carry any chance of preventing legit mail, or should I
> look at it as a question of, "Well, if they aren't configured right, I
> probably don't want them anyway?"

Greylisting gives a temporary error (``we're busy, try again in a bit'')
on the theory that spammers will interpret that as ``not worth the
trouble'' whereas legit mail is assumed to come over an MTA that will do
as the RFCs specify: queue the mail for a bit then offer it again. As
always, theory and practice might not agree. In this case, I personally
would fault the sending MTA for losing legit mail this way. Within
reason, of course: It *does* place some extra burden on the sender.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Bolwerk wrote:
+---------------
| Hi, I'm using FreeBSD 6.2 with postfix/postfix admin/courier imap+pop3.
+---------------

Other have given you some good advice, but since you're using Postfix
I thought I'd reiterate that a good "main.cf" will stop a lot of
questionable messages *before* the SMTP DATA phase, and thus save
you from having to receive the whole message [and thus lessen your
total bandwidth]. Here's what I use [see the Postfix mailing lists
for other suggestions]:

# Don't permit harvesting of addresses via the VRFY command.
disable_vrfy_command = yes

# Delay rejections to recipient phase for better logging.
smtpd_delay_reject = yes

# Duh.
smtpd_helo_required = yes

# This is vital, given the spam patterns seen these days.
unknown_local_recipient_reject_code = 550

# Put most domain checks (which reject with 4xx) *after*
# the "reject_unauth_destination" (which rejects with 5xx)
# to avoid endless retransmissions. Still be fairly strict
# about such domain requirement, though.
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
reject_invalid_helo_hostname
reject_unknown_reverse_client_hostname
reject_unknown_client_hostname
reject_unknown_sender_domain
check_policy_service unix:/var/run/mail/greylist.sock

The "check_policy_service" is optional, but I strongly suggest
running some kind of greylister. The other checks above will cut
the spam way down, but a greylister will cut it *way* down!!
Since you're using Postfix, Postgrey
is a good place to start. There are also several other greylisters
that are said to work well with Postfix [including a rather
simple proof-of-concept in the Postfix distribution itself,
though Postgrey or others are probably better than that one].
Also see and
.


-Rob

-----
Rob Warnock
627 26th Avenue
San Mateo, CA 94403 (650)572-2607

In article
rpw3@rpw3.org (Rob Warnock) writes:
>
> # This is vital, given the spam patterns seen these days.
> unknown_local_recipient_reject_code = 550

That comment seemed so strange to me that (not being a Postfix user) I
had to look up the directive in the Postfix docs - and as I expected,
that setting is the default, so it's probably not all that vital to have
it in your config.:-) (I guess it's possible that Postfix ships with a
"default config" that overrides the "builtin" default for this, but I
find that hard to believe.)

--Per Hedeland
per@hedeland.org