How do I block emails that are all the same but from different senders. They
all have a pdf attachment. The names are all different and the file names are
all different. I have not opened any and I am getting 20-30 a day. Help would
be greatly appreciated.

Dave <(E-Mail Removed)> wrote:

> How do I block emails that are all the same but from different
> senders. They all have a pdf attachment. The names are all different
> and the file names are all different. I have not opened any and I am
> getting 20-30 a day. Help would be greatly appreciated.

No need to ask more than once.
--
Brian Tillman

"Dave" wrote in message
news:90F56325-E18A-4BE2-8BDE-(E-Mail Removed)...
> How do I block emails that are all the same but from different
> senders. They
> all have a pdf attachment. The names are all different and the file
> names are
> all different. I have not opened any and I am getting 20-30 a day.
> Help would
> be greatly appreciated.


Start looking into using anti-spam software. SpamPal is free and beats
many of the commercialware products. SpamPal doesn't do anything but
tag the suspect mails. It is up to you to define a rule in your e-mail
client for what to do with these tagged e-mails.

The .pdf spams started about the 3rd week of last month. It is the
spammers' attempt to get past the image scanners of anti-spam filters by
requiring the use of a PDF viewer program, like Adobe Reader.
Previously they would embed a graphic image, like a .gif picture, to
hide their text within an image to bypass the anti-spam filters.

Although Outlook has the clause "has an attachment" that you can add to
a rule, it doesn't let you specify what type of attachment. All e-mail
is sent as plain-text. HTML is just text with special tags that an
interpreter uses to render the content of the text message. Attachments
get encoded into plain text and are inserted as MIME sections within the
body of your e-mail (your e-mail client merely shows those sections as
attachments). Each MIME section defines what type of content it
encodes. Outlook does let you define a rule with the clause "with
<specific words> in the message header". Search on the MIME's content
type declaration, which for a PDF document is:

Content-Type: application/pdf

For a GIF attachment, search in the message headers for the string:

Content-Type: image/gif

More than one search string can be specified for the "in message header"
clause.

If you don't get e-mails from friendlies that have PDF attachments then
use a rule to handle all e-mails with attachments. The friendlies
should be whitelisted in prior rules in the list (with the stop clause)
so if they send you an e-mail with a PDF attachment then this rule
doesn't get executed; i.e., if a prior rule with the stop-clause detects
the sender is in your whitelist (for rule looking for the sender or for
a rule that includes your contact-type folders) then their e-mail is not
processed by the later rule that deletes or moves out those e-mails with
attachments. Rules are OR'ed together unless the stop-clause is used
(which prevents exercising any further rules after the rule that
triggered).

As an example of what I use for rules, below is my list of them:

Rule name: Junk - Non-delivery report
Apply this rule after the message arrives
with "report-type= delivery-status" in the message header
move it to the "Junk" folder
and mark it as read
and stop processing more rules
Comment: If an e-mail from me is undeliverable, there's nothing that I
can do about it so I don't need fluff e-mail to be told about it. But I
can check by looking in Junk folder.

Rule name: Delete - SpamPal blacklist
Apply this rule after the message arrives
with "X-SpamPal: SPAM BLIST" in the message header
permanently delete it
and stop processing more rules
Comment: If the sender is blacklisted in SpamPal (which can be used by
all e-mail clients) then I won't get their e-mail. Their e-mail address
or IP address can be used.

Rule name: Keep - SpamPal whitelist
Apply this rule after the message arrives
with "X-SpamPal: PASS WLIST" in the message header
stop processing more rules
Comment: If the sender's e-mail address is whitelisted in SpamPal (which
can be used by all e-mail clients) then their e-mail stays in the Inbox
(i.e., no action against it).

Rule name: Keep - Global passcode in Subject
Apply this rule after the message arrives
with "<passcode>" in Subject
stop processing more rules
Comment: The <passcode> is a string that the sender must add to the
Subject header if they want to ensure bypassing all my other rules
(i.e., to ensure their e-mail gets received and not seen as spam or
other fluff mail that gets deleted). The passcode works across all
accounts (because the account through which the e-mail is received is
not specified in this rule). I mostly use this myself when sending me
e-mails from the same or different accounts, usually with an attachment,
to ensure that it shows up in my Inbox.

Rule name: Keep - Local passcode in Subject (<account>)
Apply this rule after the message arrives
through the "<account>" account
and with "<passcode>" in Subject
stop processing more rules
Comment: This passcode rule allows a unique passcode per account.
Rather than expose your global passcode, you let the sender know of only
the passcode for this one account. If the sender uses this local
passcode (or the global passcode if they know that one), their e-mail
skips past the remaining rules. If this account will only be used for a
specific purpose, like posting in newsgroups, you might want to use the
restrictive rule described next.

Rule name: Delete - No local passcode in Subject (<account>)
Apply this rule after the message arrives
through the "<account>" account
permanently delete it
except if the subject contains "<passcode>"
stop processing more rules
Comment: This is another passcode rule that is local to a specific
account. This rule demands the passcode be in the Subject header or the
e-mail gets immediately deleted permanently. won't get through at all.
Very handy when you want to expose your e-mail address in, say,
newsgroups while not having to munge it. Your signature should mention
what passcode must be added to the Subject header. Spambots harvest
e-mail addresses from newsgroups but they can't understand instructions
in signatures and they spammers don't capture the bodies of the posts
(so they don't get the instructions in your signature). Even if the
body were harvested with the signature, the spammer isn't going to
review his huge capture of post bodies to see those instructions. Some
****nut can use your e-mail address or add it to the body of their post
and even include the instructions to add the passcode but the spam won't
know to use the passcode so it won't get through. The account used for
this rule must be dedicated to a purpose, like posting to newsgroups
with an unmunged e-mail address, because all e-mails sent through it
will require the passcode to prevent them getting permanently deleted
upon delivery.

Rule name: Keep - Known sender (Contacts)
Apply this rule when the message arrives
sender is in "Contacts" Address Book
stop processing more rules
Comment: This whitelists everyone in your Contacts folder (the
contact-type folder that is mandatory in your personal folders for your
message store in Outlook). If you know them and have added them to this
address book then you probably want to get their e-mails (unless you
blacklisted them in the earlier SpamPal blacklist rule or they send
through the restricted account that demands a passcode).

Rule name: Keep - Known sender (Contacts - Work)
Comment: Same rule as above but specifies a different contact-type
folder that you created. I have a separate one for my contacts at work.
To help differentiate which folder you are targeting in a rule, use a
different name for the contact-type folder; else, you end up with
multiple "Contacts" folders and don't know which one you are selecting.
Microsoft only permits one contact-type folder be specified in the
"sender is in <contactfolder> Address Book" clause, so if you have N
contact-type folders then you need N copies of this rule.

Rule name: Delete - No @ in From header
Apply this rule after the message arrives
permanently delete it
except with "@" in the sender's address
stop processing more rules
Comment: If the sender doesn't want to include their e-mail address in
the From header then I don't want their e-mail. All e-mail addresses
must contain the "@" character. As a side effect, this also checks that
the From header is not blank (because it must contain, at a minimum, the
"@" character to get past this rule).

Rule name: Delete - Subject is blank
Apply this rule after the message arrives
permanently delete it
except if the subject contains 'a' or 'e' or 'i' or 'o' or 'u' or
'y' or '0' or '1' or '2' or '3' or '4' or '5' or '6' or '7' or '8' or
'9'
stop processing more rules
Comment: Non-English e-mails I can't read and don't want. In English,
there are few words that don't contain any vowels or without vowels they
don't contain "y". There might be some but not many and if there are
more than 2 words then the chances become far less that it's an e-mail
that I want. Anyone that uses chatspeak with compressed words are also
folks that I don't want to talk to. You don't need to include the
numbers but sometimes someone sends me an e-mail (as a response to a
separate request) regarding some account or other numerical-only info
which they might put into the Subject header. Basically, if the Subject
header doesn't have at least one vowel then it doesn't have words, and
e-mails with garbage Subjects are those you don't want.

Rule name: Delete - Me in From header (<account>)
Apply this rule after the message arrives
through the "<account>" account
and with "<myEmailAddyForThatAccount>" in the sender's address
permanently delete it
and stop processing more rules
Comment: I rarely send e-mails from myself to myself, and even rarer is
that I send them through the account where they also get received. If I
need to do that, I add the global passcode to skip past all my rules.
Since I have 6 e-mail accounts, I need 6 copies of this rule, one for
each account, because only one account can be specified in the "through
the "<account>" account" clause (to match up with the e-mail address for
that account).

Rule name: Junk - Not sent to me
Apply this rule after the message arrives
and move it to the "Junk" folder
and mark it as read
except if my name is in the To or Cc box
Comment: I don't use the stop-clause in this rule. I am merely checking
if the e-mail wasn't sent to me and holding that e-mail in the Junk
folder. I still want the rest of the rules to get exercised against
this same e-mail. If the e-mail is not addressed to me then I
*probably* don't want it. However, I might subscribe to a newsletter or
make an online purchase and the sender uses some alias or distro list
name in the To/Cc headers rather than using my e-mail address. Since
I'm expecting those e-mails, I can go check in the Junk folder for them,
but I still want the rest of the rules to check that e-mail for
nastiness. I mark the e-mail as read so the folder doesn't get bolded
in the tree list (most spam is not addressed to me). If I'm expecting a
sign-up, confirmation, registration, or online order e-mail then I'll go
look in the Junk folder for it since such e-mails arrive within a few
minutes after that online activity.

Rule name: Junk - PDF or GIF attachment
Apply this rule when the message arrives
with "Content-type: application/pdf" or "Content-type: image/gif" in
the message header
move it to the Junk folder
and mark it as read
and stop processing more rules
Comment: This is the one you were looking for. It checks for e-mails
with PDF and GIF attachments. GIF images (as an inline attachment;
i.e., embedded in the body) were what most spammers used (instead of
JPEG) to insert an image to hide the content of their crap from
anti-spam image scanners. Now they trying to use PDF to hide their
content within an image because it requires a common document viewer
application to see it, like Adobe Reader. I have *never* received good
e-mails with a .gif attachment. I can't remember getting a good e-mail
with a .pdf file attachment but it isn't outside the realm of
possibility in the future, so I junk these e-mails rather than
permanently delete them. I could have separated this into 2 rules: one
for GIF that permanently deletes the e-mail and another for PDF that
junks the e-mail.

Rule name: Junk - SpamPal trap
Apply this rule after the message arrives
with "X-SpamPal: SPAM" in the message header
move it to the "Junk" folder
and mark it as read
and stop processing more rules
Comment: I use SpamPal to detect spam. This is responsible but reactive
approach to getting rid of spam. Proactive and irresponsible schemes
include challenge-response which I don't use; see
http://spamlinks.net/filter-cr.htm#issues-harmful. After all the other
rules to catch bad e-mails, I then see if SpamPal says an e-mail is
suspicious. I don't go overboard configuring SpamPal to be overly
aggressive because that generates too many false positives (good mails
marked as spam) but neither do I want lots of false negatives (spam
mails that passes as good mails). After all my other rules and with
using SpamPal, I can tolerate the 3 to 4 spams that leak past in a week.
Hell, I see far more commercials on cable television in an hour. I
prefer to use headers to detect what SpamPal marks as spam but I also
have to configure SpamPal to add that info to the Subject header since
Outlook Express can't read the headers (other than the Subject header).

Rule name: Copy - Received Items
Apply this rule when the message arrives
move a copy to the "Received Items" folder
Comment: If a message gets past all my rules and past SpamPal, I
probably want to keep a copy of it. Auto-archiving is used on that
folder to remove items older than 6 months to an archive file (where
auto-archiving is enable to permanently delete them after 2 years).
This is a subfolder under the "Sent Items" folder. That way, when I do
an Advanced Find search on my e-mails with the starting point being at
the "Sent Items" folder (and because "include subfolder" option is
enabled by default), I get to find all related e-mails whether sent or
received, plus I can group the result to show them in threads. There is
possiblity that I might add another rule after this one so the
stop-clause was not used.

Auto-archiving is enabled and used on the Junk folder. Items older than
3 days get permanently deleted. That lets me capture false positives
before they disappear but gets rid of what is mostly spam. Having the
items marked as read when moved into the Junk folder eliminates me
having to see a bolded "Junk" folder which lures me into visiting there
more often than I should. Anything good mails that got junked are those
that I'm probably waiting for and that's the only time I want to look in
the Junk folder.

The rules are OR'ed in the order they are listed, so order is important.
Using the stop-clause prevents other rules from generating unwanted side
effects when a rule triggers. Usually (but not always) when a rule
triggers then you don't want other rules wasting time getting exercised
against that same e-mail, plus they could undo the action of the first
rule that fired.

The rules only get rid of some nuisance and spam e-mails but don't rely
on them. Never bother using the Blocked Senders feature since obviously
spammers never use their own e-mail address and they change it on
everytime they spew. You need to incorporate some anti-spam software.
I like SpamPal because it rolls into one free product many schemes to
detect spam whereas other products usually rely on just one or two
methods. Some but not all features of SpamPal include:

- Uses DNSBLs (DNS blocklists). These are lists of known spam sources.
Never use the SPEWS, APEWS, or UCEPROTECT blocklists as they are not
applicable to filtering your own e-mails and rate spamminess of domains
or portions of them rather than identify specific spam sources. SpamPal
doesn't allow scoring or weighting the blocklists (and these would get a
add a low scoring value to the overall spam/ham score, anyway). I use
SpamHaus SBL+XBL (which includes CBL and blitzed.org), ORBD, NJABL, and
SpamCop (considered a bit more aggressive but, so far, no false
positives for me).
- You can block by country-specific IP ranges. If you don't get good
e-mails from China, Malaysia, Russia, or wherever then they're probably
spam.
- Blacklist by e-mail address or IP address of the sender. This
blacklist is done in SpamPal which means it is available to any e-mail
client you use with SpamPal (i.e., you don't need duplicate blacklists
in multiple e-mail clients). Also has an Ignore List to exclude
providers, like Bonded Sender, or IP ranges from the blocklists.
Sometimes a blocklist will list a large IP range at an e-mail provider,
like Yahoo. It might be temporary but it means e-mails from your
friends there will get tagged as spam. It allows undoing part of a
blocklist, especially if you are stupid in using the SPEWS blocklist for
personal e-mail filtering.
- Whitelist by e-mail address, also done in SpamPal so available to all
e-mail clients. Includes automatic whitelisting. This is not
whitelisting e-mails address of to whomever you send e-mails. This is
checking if you receive e-mails from a sender that has consisently
proven not to be spam. I specified 15 separate days of getting good
mails from the same sender before they can get automatically
whitelisted.
- A Bayesian plug-in lets you use that method to detect spam. It
weights the words in an e-mail to determine how spammy it is. If too
spammy, it gets marked as spam. This is a database of weighted words
that takes time to learn. If you have a large set of good and bad
mails, you can make it pre-learn from those. It has a learning mode so
you can have it learn without tagging mails as spam. After a couple of
weeks, turn off the learn mode (it will still keep learning though
although now it will start tagging suspect mails). Unlike other Bayes
filters, this one can also learn from SpamPal via DNSBLs and other
plug-ins. If they determine a mail is spam then the Bayesian plug-in
will also weight the words in that mail as spam. There are some better
Bayes filters out there but the inclusion of this one in SpamPal with
all the other methods to detect spam and the ability of this Bayes
filter to also learn from all those other methods makes it a good Bayes
filter.
- The MX blocking plug-in will tag any e-mails that originate from
dynamically IP addressed hosts, like end-user hosts that connect to
their ISP (your's is probably a dynamic IP address for your host). Few
users get static IP address because this drain's the IP pool for the ISP
and there is usually an extra charge. Infected hosts running trojan
mailers typically have dynamic IP addresses. If the e-mail doesn't come
from a mail server on a static IP address then I don't want it. I don't
accept e-mails from some bozo or geek that wants to run their own mail
server for their own unknown reason from a dynamically IP addressed
host.

There are other features of SpamPal that make it an overall good
anti-spam solution. Just defining rules in your e-mail client is not
enough. Using just Bayes filtering is not enough (and is fraught with
false positives/negatives because it is a guessing scheme). Of course,
you should still enable the server-side spam filter provided by your
e-mail service. Server-side filtering is better than client-side: you
don't get the spam to have to then deal with it. Just be aware that
ISPs often use loose filtering because their customers are far more
sensitive to false positives (losing good mails) than of false negative
(spam that leaks past their filters).

The point is to use SOMETHING ELSE other than just rules in your e-mail
client to get rid of spam.