At 04:03 PM 6/11/97 +0300, era eriksson wrote:
[snip - forwarding service is good mojo]
SMTP-level filtering doesn't take place at your reading host because the
message _comes from_ iki.fi, not the original spammer. I'm not positive,
but I imagine if the mail were queued up at an intermediate site (via a
secondary MX) - say your receiving domain were offline briefly or it's
link to the world went haywire - then when the messages finally get sent
via the intermediate mailer, the SMTP-level filtering performed by the
receiving host probably wouldn't do much. If anyone here can confirm, I'd
like to know this for sure.
flatly stated they'd refuse to filter their users' mail. Apparently,
Having some form of SMTP-level antispam would be in their best interests -
it would reduce the bogus traffic to their site and lessen the possibility
of being victimized by theft of services.
However, they would like it to work on an address-by-address basis,
where era(_at_)nospam(_dot_)iki(_dot_)fi would be subject to filtering, while
era(_at_)iki(_dot_)fi would not be filtered at all. It also seems that they
will
still not do SMTP blocking at any point.
If this is the case (no SMTP blocking at all), then the nospam address
would need to be associated with a hosted shell account for the procmail
script to be run in.
Given the sound of their reluctance to do spam filtering to begin with, I
doubt they want to permit each user to have their own shell account to do
personal filtering in, so I would imagine that they could use the sendmail
virtusertable feature (they have it available to them), and direct ALL
@nospam.iki.fi mail into a _single_ hosted account (which is what I often
do with virtual hosts - I can set up name.hostdomain.com domains and route
ALL the mail to that domain to a friends mailbox - locally or externally).
This single account would have a procmail script set up to filter out all
the known spam and mailbomb, bounce as appropriate, and forward whatever is
left along to the original envelope address, minus the "nospam." portion of
the domain.
If I was doing this, I'd have a file with usernames and flags denoting
which level of filtering any given user wants - at the top of the recipe,
it could extract the envelope information and look up the users preferences
in it's data file, and use that to determine if it should run through the
"spamdomain", "mailbomb", "chainletter", etc, recipes. How you'd allow
users to change what their prefs are (a secure web page perhaps?) is a
different exercise - manually generating the file should be sufficient.
I honestly don't know about the intricacies of using procmail as the local
delivery agent (in my case, it seems just to automatically pick up on the
.procmailrc file in the user directory without necessitating a .forward
file). Only started tinkering with an in-house SMTP server a few weeks ago
- there's much to learn. I don't know of any system-wide procmail script
ability - that's for the local pros to explain, as I hope they will.
The problem is that the whole service is run pretty much as a
volunteer effort, so one issue is also whether any proposed solution
Well, apparently mail is handled by a machine known as "jatko.iki.fi", and
they're running Sendmail 8.8.5 (which is good - this means they have a
number of built-in anti-spam measures at their disposal without requiring
writing anything any special rulesets - almost all they should need to do
is create the appropriate lists of rejected domains and enable some
features in the sendmail.cf)
While I'm generally knowledgeable about Procmail, the admin side of
things is not something I have any practical experience of. As far as
I can tell, you get to run Procmail only after alias expansions etc
have been performed. Is this correct?
Yes. To give you an idea of some of the things alias expansion allows for:
era.eriksson: era (would permit you to get mail at a fullname
addr)
eraremote: era(_at_)other(_dot_)domain (says mail to local
user really gets fwd')
erafriends: era, gustav, phil (mail sent to multiple users)
(there are a few other constructs as well)
In any event, the message headers still identify the original addressee (so
era.eriksson mail would still end up in your mailbox, and using Procmail
(or just looking at the addressing headers) you'd be able to determine that
it'd been sent to the alternate address.
I do occasionally run into situations where when I've been bcc'd (and this
includes listserv substances) the delivery address fails to appear in the
headers (even the received headers), which is rather problematic for me
(I'd _really_ like to know how to insert x-envelope_to/from headers using
sendmail, and its looking a lot like I have to achieve this via adding code
and recompiling, rather than via a rewrite rule). Without something to
identify it as having been sent to the spam 'filtered' address, you're
likely to have some problems fully identifing it as mail to trash.
*IF* they at least ran a second SMTP machine (which the MX for
nospam.iki.fi would point to), and it were to forward all mail to the other
machine (via their local ethernet - it wouldn't suck up their external
bandwidth), then you'd have the additional received-by headers showing it
came through the other machine. That would give you something consistent
to work with at your receiving end. Probably a lot more than they want to
implement for antispam. IMHO, if they're all that big (1400 users), they
should want a secondary MX machine anyway...
Personally, I'd love to see them adopt SMTP filtering, but this is
My (limited) understanding of the SMTP based filtering is that it blocks
SMTP connections coming from _certain_ sites - those matching some
criteria. This is mostly useful for keeping Cyberpromo out of your mailbox
(until they get a new address block or spam bandwidth partner that needs to
be added to the SMTP ban list), but won't do much of anything to keep the
"this is a one-time mailing" spam from your box (or the stuff mailed via a
user account on a large, otherwise reputable ISP). It also allows them to
put in rules for saying "if it is addressed TO or FROM a hosted user,
accept the mail, otherwise reject it (someone is attempting to use our
server+bandwidth to spew their spam to elsewhere)."
---
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395