How to discard BCC:'d emails in general
Paul J. Campbell
my specific email addresses in the To: or CC: fields, but only in the
BCC: field (i.e. someone has sent an email to me only through the
BCC: field, not To: or CC: ).
Yes, websites like
home.comcast.net/~jyavner/TP600E/procmailrc
www.uwasa.fi/~ts/info/proctips.html#spam
show an example solution, but they hard-code their email addresses
in the procmail recipe.
Is there a way of doing it without such hard-coding?
I'm in a corporate environment, and I need to do it for
only a subset of the addresses in the /etc/aliases file, e.g.
for username1 and username2:
username1: "|/somescript"
username2: "|/somescript"
The 'somescript' program does this:
exec /usr/bin/procmail -m /etc/support.procmailrc $*
The example solutions in the above websites would require
me to hard-code the username1 and username2 addresses into
/etc/support.procmailrc . Is there a smarter way of
doing it, without hard-coding?
The problem with hardcoding is that my environment is actually much more
complex than I've written above. Also, the usernames in /etc/aliases
frequently change, and I don't want someone to have to maintain
the same usernames in /etc/support.procmailrc as well.
E.g. in /etc/aliases or procmailrc, is there any way to detect that
the email arrived through To: or CC: in general, without hard-coding
the actual email addresses?
Alan Connor
<436c7a05$0$26379$afc3...@news.optusnet.com.au>, "Paul
J. Campbell" wrote:
Hello Paul,
That's a very good way to kill a lot of spam/trollmail.
You could run procmail from a wrapper script that parses the
selected usernames out of /etc/aliases to a tempfile then calls
procmail which then references that list. Something like this:
:0
* ? formail -x"To:" -x"Cc:" \
| grep -E -v -i -s -f /tmp/aliases
/dev/null
Just make sure the selected usernames are all in a block in
/etc/aliases for easy parsing with sed. Or otherwise marked
with a commented out string...
/tmp/aliases would be overwritten each time procmail ran.
[Note: I don't read the posts of "Sam" or any of his
many aliases, nor any responses to them.]
AC
--
Homepage: http://home.earthlink.net/~alanconnor/
Fanclub: http://www.pearlgates.net/nanae/kooks/alanconnor.shtml
Per Hedeland
J. Campbell" <paulc8...@optusnet.com.au> writes:
>Is there any way to discard emails which are not addressed to
>my specific email addresses in the To: or CC: fields, but only in the
>BCC: field (i.e. someone has sent an email to me only through the
>BCC: field, not To: or CC: ).
Nitpick mode: The latter doesn't follow from the former - there is
absolutely no way you can detect that Bcc: was used, only that the
(final) recipient address isn't present in To:/Cc: - there are countless
ways to send email without the recipient ever being present in any
header. The obvious case is mailing lists (which will also be "hit" by
any rule like this) - they surely don't stuff a gazillion recipient
addresses into a Bcc: header.
>I'm in a corporate environment, and I need to do it for
>only a subset of the addresses in the /etc/aliases file, e.g.
>for username1 and username2:
> username1: "|/somescript"
> username2: "|/somescript"
>
>The 'somescript' program does this:
> exec /usr/bin/procmail -m /etc/support.procmailrc $*
>
>The example solutions in the above websites would require
>me to hard-code the username1 and username2 addresses into
>/etc/support.procmailrc . Is there a smarter way of
>doing it, without hard-coding?
Well, the obvious first question is: Don't you care *which* of the
recipient addresses the message was sent to *anyway*? I.e. mail to
username1 and username2 is processed exactly the same? If you *do*
differentiate between them, I would expect your procmailrc to parse the
recipient address out of the To:/Cc: headers, which is normally wrong,
but for this purpose would do just what you want: If none of the
expected recipient addresses are in there, you can take the "sent via
Bcc" action you desire.
>The problem with hardcoding is that my environment is actually much more
>complex than I've written above. Also, the usernames in /etc/aliases
>frequently change, and I don't want someone to have to maintain
>the same usernames in /etc/support.procmailrc as well.
>
>E.g. in /etc/aliases or procmailrc, is there any way to detect that
>the email arrived through To: or CC: in general, without hard-coding
>the actual email addresses?
In general, no. But of course the information is available at the point
where the alias entry is matched: You have a message with "username1" in
the recipient list, but that address is nowhere to be found in the
headers. It's just that when you invoke 'somescript' without arguments,
you drop the the "username1 is recipient" information.
With your setup above, any arguments to 'somescript' are actually passed
on to procmail, so all you need to do is pass the recipient info along
- e.g. if you make your aliases:
username1: "|/somescript recip=username1"
username2: "|/somescript recip=username2"
- procmail should receive the recip=<whatever> argument, and you should
then be able to use $recip in the procmailrc file instead of a hardcoded
string. (Of course you could alternatively have 'somescript' prepend the
'recip=' part, or use procmail's -a option.) See the procmail docs for
further info.
--Per Hedeland
p...@hedeland.org
J.O. Aho
> In article <436c7a05$0$26379$afc3...@news.optusnet.com.au> "Paul
> J. Campbell" <paulc8...@optusnet.com.au> writes:
>> Is there any way to discard emails which are not addressed to
>> my specific email addresses in the To: or CC: fields, but only in the
>> BCC: field (i.e. someone has sent an email to me only through the
>> BCC: field, not To: or CC: ).
>
> Nitpick mode: The latter doesn't follow from the former - there is
> absolutely no way you can detect that Bcc: was used, only that the
> (final) recipient address isn't present in To:/Cc: - there are countless
> ways to send email without the recipient ever being present in any
> header. The obvious case is mailing lists (which will also be "hit" by
> any rule like this) - they surely don't stuff a gazillion recipient
> addresses into a Bcc: header.
IMHO it was more common to send spam with Bcc than today, I do use procmail to
sort out mail that is sent as Bcc and sender aren't in a whitelist. I have and
since 14th of June 2005 I have got 44 spams this way.
Spam sent without Bcc during the same time was 641, this to an 10 year old
e-mail account and has quite many public references.
In the late 90s I used to have the opposite, that Bcc-spam was the majority
(maybe as much as 80% of all spam mail sent to the same account).
//Aho
Alan Connor
This turkey didn't even acknowledge any of the responses he
received.
Killfiled. Bet it isn't the first of his aliases I've killfiled,
and that it won't be the last.
[Note: I don't read the posts of "Sam" or any of his
many aliases, nor any responses to them.]
AC
--
URLs of possible interest in my headers.
~
~
Sam
> On comp.mail.misc, in <436c7a05$0$26379$afc3...@news.optusnet.com.au>, "Paul J. Campbell" wrote:
>
> This turkey didn't even acknowledge any of the responses he
> received.
And this is different from an average Beavis kookfart exactly how?
> Killfiled. Bet it isn't the first of his aliases I've killfiled,
> and that it won't be the last.
Beavis FAQ #5, below.
> [Note: it's not my fault that I'm a complete dumbass. I was dropped
> on my head as a child. See http://angel.1jh.com/nanae/kooks/alanconnor.shtml
> for more information]
FAQ: Canonical list of questions Beavis refuses to answer (V1.40)
This is a canonical list of questions that Beavis never answers. This FAQ is
posted on a semi-regular schedule, as circumstances warrant.
For more information on Beavis, see:
http://angel.1jh.com/nanae/kooks/alanconnor.shtml
Although Beavis has been posting for a long time, he always remains silent
on the subjects enumerated below. His response, if any, usually consists of
replying to the parent post with a loud proclamation that his Usenet-reading
software runs a magical filter that automatically identifies anyone who's
making fun of him, and hides those offensive posts. For more information
see question #9 below.
============================================================================
1) If spammers avoid forging real E-mail addresses on spam, then where do
all these bounces everyone reports getting (for spam with their return
address was forged onto) come from?
2) If your Challenge-Response filter is so great, why do you still munge
when posting to Usenet?
3) Do you still believe that rsh is the best solution for remote access?
(http://tinyurl.com/5qqb6)
4) What is your evidence that everyone who disagrees with you, and thinks
that you're a moron, is a spammer?
5) How many different individuals do you believe really post to
comp.mail.misc? What is the evidence for your paranoid belief that everyone,
except you, who posts here is some unknown arch-nemesis of yours?
6) How many times, or how often, do you believe is necessary to announce
that you do not read someone's posts? What is your reason for making these
regularly-scheduled proclamations? Who do you believe is so interested in
keeping track of your Usenet-reading habits?
7) When was the last time you saw Bigfoot (http://tinyurl.com/23r3f)?
8) If your C-R system employs a spam filter so that it won't challenge spam,
then why does any of the mail that passes the filter, and is thusly presumed
not to be spam, need to be challenged?
9) You claim that the software you use to read Usenet magically identifies
any post that makes fun of you. In http://tinyurl.com/3swes you explain
that "What I get in my newsreader is a mock post with fake headers and no
body, except for the first parts of the Subject and From headers."
Since your headers indicate that you use slrn and, as far as anyone knows,
the stock slrn doesn't work that way, is this interesting patch to slrn
available for download anywhere?
10) You regularly post alleged logs of your procmail recipe autodeleting a
bunch of irrelevant mail that you've received. Why, and who exactly do you
believe is interested in your mail logs?
11) How exactly do you "enforce" an "order" to stay out of your mailbox,
supposedly (http://tinyurl.com/cs8jt)? Since you issue this "order" about
every week, or so, apparently nobody wants to follow it. What are you going
to do about it?
12) What's with your fascination with shit? (also http://tinyurl.com/cs8jt)?
13) You complain about some arch-nemesis of yours always posting forged
messages in your name. Can you come up with even a single URL, as an example
of what you're talking about?
14) You always complain about some mythical spammers that pretend to be
spamfighters (http://tinyurl.com/br4td). Who exactly are those people, and
can you post a copy of a spam that you supposedly received from them, that
proves that they're really spammers, and not spamfighters?
Alan Connor
<body not downloaded>
This again?
I guess you must be lonely, "Sam".
That's your fault. If you hadn't been an utter asshole
when I first showed up on this group, I wouldn't have been
refusing to read your posts for these several years.
You reap what you sow.
[Note: I don't read the posts of "Sam" or any of his
many aliases, nor any responses to them.]
Post what you want. Put up a website about me, like the
punks below did.
I've never read those webpages.
wget -U MSIE --spider http://....
Tells me they are there.
AC
--
http://home.earthlink.net/~alanconnor/
http://www.pearlgates.net/nanae/kooks/alanconnor.shtml
http://www.netcomhost.net/wordpress/victims-of-alan-connor/
Sam
> On comp.mail.misc, in <cone.1131710085...@commodore.email-scan.com>, "Sam" wrote:
> <body not downloaded>
Beavis FAQ #9.
> This again?
Once a Beavis, always a Beavis, I suppose.
> I guess you must be lonely, "Sam".
Nope, Beavis. I recently met your good friend, Bigfoot:
http://tinyurl.com/23r3f
> That's your fault. If you hadn't been an utter asshole
> when I first showed up on this group, I wouldn't have been
> refusing to read your posts for these several years.
Beavis FAQ #9, again.
> You reap what you sow.
>
> [Note: it's not my fault that I'm a complete dumbass. I was dropped
> on my head as a child. See http://angel.1jh.com/nanae/kooks/alanconnor.shtml
> for more information]
>
> Post what you want.
Will do.
> Put up a website about me, like the
> punks below did.
I don't need to, Beavis. Google has already compiled quite a dossier on
you.
http://groups.google.com/groups?q=usenet+beavis
> I've never read those webpages.
FAQ #9 again.
> wget -U MSIE --spider http://....
>
> Tells me they are there.
Another Beavis URL to bookmark.
Bookmarked as http://tinyurl.com/9pjnt - how to masquerade as Internet
Explorer, according to Beavis. This goes hand in hand with his earlier
suggestion to use rsh for remote logins over the Internet
(http://tinyurl.com/5qqb6).
Thank you for posting your Internet hints and tips, to so many newsgroups.
Now, even more people can see what a mental genius you are.
Alan Connor
<body not downloaded>
Hi, "Sam".
Are we having fun?
[Note: I don't read the posts of "Sam" or any of his
many aliases, nor any responses to them. Haven't for
years.]
Sam
> On comp.mail.misc, in <cone.1131754406....@commodore.email-scan.com>, "Sam" wrote:
> <body not downloaded>
Beavis FAQ #9
> Hi, "Sam".
Hi, Beavis.
> Are we having fun?
Yeah. Get a load of this: http://www.geocities.com/suhatrasabib/