At 15:05 2006-12-13 -0500, Frank Bures wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I apologize if this query would be considered too much of an off topic.
Anyway, here it is:
I am running several rather large aliases on our servers that are used as
kind of listservs.
If using sendmail, you should consider using :INCLUDE:, which shifts these
aliases outside of the alias database.
There was no problems with them till about a year ago
when their addresses were harvested by spammers (probably from a laptop
compromised during one of our researchers' travels) and spam started to
arrive in large quantities.
As practically all addressees were local I used procmail to filter these
spams away setting up several recipes to allow only local users the privilege
to send mail to these aliases.
Is it the individual addresses or the list alias itself which is being
However, due to the pressure from the business administration, increasing
number of external recipients started to appear on these aliases. Of course,
procmail being a point-of-delivery filter ignores these addresses and all the
spam is happily delivered to external users.
Er, that's only if the spam is coming into the LIST alias itself, versus
each individual recipient. If the spam is addressed to the recipient and
they're remote, it doesn't come through your server in the first place, so
no amount of filtering at your end is going to change anything there.
I'd suggest that you lose the aliasing and install a listserve (such as
majordomo, mailman, whatever). This will provide you with the ability to
set things up so that only s*bscribers can post to the list, and you can
filter out attachments or large posts easily.
The same applies for local
users who setup forwarding to some outside addresses.
Hence my question: Is there a way how to disable posting to these aliases
from addresses (E-mail or preferably IP) that are not explicitly defined
A hairy proposition. If you insist on using MTA aliasing to manage a list,
I'd consider doing this:
1. move all the recipients to an include file (a flat file, one address per
2. Set up a SECOND alias which targets that list:
3. write a procmail recipe to compare the poster address against the
addresses in the include file. Non-match, bounce (poss. to admin, or
message to submitter saying they're not recognized as being on the
list). This procmail script can also check for HTML-only messages,
attachments, whatever, to cut down on cruft (and of course, you could
invoke a pre-made antispam filter from it too).
4. change the original list alias to pipe messages to the new procmail filter:
listname "|/usr/local/bin/procmail -m
The argument after the rcfile would provide the listname so that the rcfile
could be genericised for multiple lists - use it within the rcfile to
identify the listname-out alias to use, as well as the include file to
match submissions against).
in access, add:
To:listname-out@ ERROR:5.5.0:550 This is not a valid list
(and of course, properly rebuild access and aliases dbs).
This last tweak says that submissions from the localhost will be relayed,
while messages to listname-out will be rejected. The RELAY takes
precedence, so localhost doesn't end up not being able to relay, while any
other attempt to send a message to the OUT address alias will result in
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
procmail mailing list Procmail homepage: http://www.procmail.org/