04-10-2012 07:56 AM
How can I block UPS, USPS and FexEd delivery notice scams where the From: address is *@ups.com, *@usps.com, or *@fedex.com but the Envelope-From: is some bogus address that is NOT @ups.com, @usps.com or @fedex.com?
Legit messages will have both a From and Envelope-Recipient from the @ups.com, @usps.com or @fedex.com domains.
Example:
Envelope-from="nobody@server4.vedcor.net"
From: FedEx Express Services <providing.us@fedex.com>
04-12-2012 03:47 PM
We currently struggle with the same issue on a daily basis. The best way we've found to resolve this issue is create an Incoming Mail Policy which is based on these senders @fedex.com, @usps.com, and @ups.com and have an Incoming Content Filter attached to this Mail Policy which checks the condition of their SPF record and if the record comes back as any other than PASS the message gets sent to a quarantine for further analysis. So far this seems to have worked fairly well. Only a very small handful of messages ever hit the quarantine that are legitimate. Of course this all relies on the sender having their SPF record setup properly which in some cases (@cisco.com for instance) although they have an SPF record pretty much every place they send from is considered a spoof of their domain so almost all messages hit the quarantine. In these cases we've had to remove the sender domain from the incoming mail policy.
If you hear of a better method or if someone wants to offer a better solution I'm game. Otherwise it feels like a constant cat and mouse game to me.
Thanks,
Mike
04-13-2012 05:45 AM
Mike,
I ended up with two solutions. One was to increase the size of messages I scan from 256k to 768k. A lot of the delivery scams had very large zip attachments and were getting in because they were over 256k.
The other thing I did was create a dictionary named "foil_delivery_notice_scams" and put the domain names ups.com, usps.com, fedex.com and delta.com in it. I check the header for messages "From" containing those domains and a zip attachment. I can't use envelope sender because they forge that - which is how they get around the SPF check.
A more effective way to do this would be to reject all messages with a From of those domains where the Envelope Sender is forged from a different domain. I don't know how to write that without having a very nasty, spaghetti rule.
Order | Condition | Rule | Delete |
---|---|---|---|
1 | Other Header | header-dictionary-match("foil_delivery_notice_scams","From", 1) | |
2 | Attachment File Info | attachment-filetype == "Compressed" |
Order | Action | Rule | Delete |
---|---|---|---|
1 | Send Copy (Bcc:) | bcc ("myaddress@mycompany.com", "[TAGGED DELIVERY SCAM] - $Subject") | |
Final | Drop (Final Action) | drop() |
Thanks
Charles
04-13-2012 08:23 AM
I thought about going the more effective route myself but ran into issues where way too many legitimate senders do not have the same Mail From address as they do Envelope Sender address.
We do use this method though for all of our internal domains. This way if anyone tries to spoof our domains from the outside they are unable too. Of course even in this case we've had to add some specific allows for certain vendors of ours who spoof us when sending into us but so far the message filter shown below has worked very well.
Basically I reference a dictionary file which has all of our internal domains listed in it. Then I compare it to the HAT RELAYLIST which contains all of the approved sending addresses. Then I wrap it up with an ALLOWEDSPOOF and TLS_Required HAT groups with include exception IPs that are allowed to send as us. If the message doesnt meet this criteria it notifies me with an email and sends the message to a quarantine called Spoofed Domain Names for further analysis. So far its been working like a champ!
AntiSpoofing: if (mail-from-dictionary-match("internal_domain_list", 1)) AND (sendergroup != "RELAYLIST") {
if (sendergroup != "ALLOWEDSPOOF") AND (sendergroup != "TLS_Required") {
notify (youremailaddress@here.com);
quarantine("Spoofed Domain Names");
}
}
04-16-2012 03:38 PM
This is a shot in the dark. Create three new inbound policies, one each for sender addresses matching @fedex.com, @usps.com, and @ups.com. These will catch messages whose envelope sender is one of those three. Initially set each policy to the same actions as your default policy to preserve that set of behaviors for these messages. Then add a single content filter to each one that makes sure the domain in the From: header matches that the envelope sender. This is the reverse of what you're looking for, and I rather doubt you'll see very many hits this way.
Then, create a content filter that checks for a From: header whose domain is @fedex.com, @usps.com, or @ups.com. Bind this content filter to every other inbound policy. Since all messages whose envelope senders are one of those three will go to one of the policies you just created, anything that lands in another policy will not have those domains in the envelope sender. So if you see a From: header that matches one of those domains, you know it's a spoof.
I haven't looked into this particular situation to know if checking the header against the envelope is a good way to deal with it. However, assuming it is, this idea should do that for you. I think. If your incoming policies are already rather complex then you may not be able to make this idea interact properly with your existing policies.
++Don
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide