-----Original Message-----
From: procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
[mailto:procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE] On Behalf Of
Professional Software Engineering
Sent: Saturday, July 05, 2003 10:15 AM
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Subject: RE: Question on restricting incoming mail from Mail Lists
At 23:51 2003-07-04 -0700, Noarmun E. Mailer did say:
...no, I'm not using a wildcard and then trying to kludge
procmail into sorting it all out.
I didn't say you were. What I suggested was that a great
many people who have gobs of addresses are simply wildcarding their
<snip>
Understood.
If you're actually configuring your MTA with _each_individual_ alias,
then that's great - your MTA will reject mail directed to addresses
which weren't specifically configured.
I have a mixture of aliases per inbox. All the redhat lists go to one
physical inbox, for example, this list and the sendmail list go to a
different inbox. In haphazard fashion I have created a dozen more. Now
I want to clean things up a bit.
<snip>
Someone who gets the subscription email address can then
spam into my list inboxes. I simply want to block mail that doesn't
come from the list.
As David has already pointed out, you'll ditch legitimate
offlist replies if you take that route.
My idea was to restrict incoming email (to the addresses used for email
lists) to just list mail as one component of control. Yes, that would
mean list members could not privately send to me at that address but
that's not a big problem, I can offer a regular address in my .sig.
Mostly, I didn't want to have a mixture of messages in my inboxes. For
one reason or another, I've just gotten procmail and spamassassin
working this week so I'm playing with them.
So maybe I should just go back to moving incoming messages by filtering
the incoming header (if its SPAM, move to the spam folder otherwise
match on From: address to folders with a default of regular inbox.)
What I'm trying to point out though is that if you're going
to limit mail according to SENDER, you really shouldn't need to limit
it according to recipient. Certainly, there can be times when that
is appropriate, but is really isn't for what you're trying to do -
when a _spammer_ spams you (or, as David said, when someone
legitimately mails you offlist), the Sender: won't identify the list
-- and if it did, your Sender + To: logic would have been matched,
and you'd have accepted the message anyway. Thus, To: is
unnecessary. Further, spammers are HIGHLY unlikely to send you spam
at OTHER addresses of yours, using Sender: from different lists
you're subscribed to - IF they were so bright as to forge Sender:
addresses to be from lists, surely they'd be forging them To:
addresses which they harvested FROM those same lists?
No, you're right about this. I was looking for a method to first
identify which list (defined by the signup address I used) and then
which list sent it so as to refuse mail to one of my addresses unless
the message comes from the subscribed list. But I screwed up the logic
right off the bat.
And if the spam program works as advertised I can just trust it and
filter messages that get through into folders by source.
You're really much better off employing standard spam
avoidance techniques, using some good RBLs at the MTA level, and a
good LDA-time filter (either a series of procmail filters, or use
procmail to invoke SpamAssassin or the like).
Just got spamd running with a spamc recipe. I'll have to see how it
goes with some test messages. I'm not using an RBL at this point since
the mail volume is just me.
I still use several role-based addresses, it's not for spam
purposes. However, my _generic_ mailing list account is
intentionally separate from my standard contact address, and that IS
intentional, and spam-related - I can more freely resubscribe to
lists with another address and ditch my generic list address if it
becomes a liability to me - but good spam filtering has made that
unnecessary thus far.
Yes. Use addresses that can be dumped if they become too attractive.
I'd use free ones but I don't like the advertising.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer:
<http://www.professional.org/procmail/disclaim> er.html>
Please DO NOT carbon me on list replies. I'll
get my copy from the list.
Dana Bourgeois
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail