Our users are getting hundreds of these!
One of the problems is that the actual spam email is sometimes not
attached. But interestly enough we are usually sent the email header of the
original email. From that we (the humans) can easily spot that the IP
address of the mailserver claiming to be ours is, in fact, not. So, if that
line in the returned email header can be parsed perhaps a program can
validate the IP address.
Only a suggestion - I'm sure a lot harder in real life.
SPF only works in these instances if (1) the domain users know what
mailservers they might use amd (2) the mailserver that received the
original SMTP connection analyzes SPF before accepting the connection and
doesn't just bounce the email back to the sender.
At 07:28 PM 4/10/2008, Jason Haar wrote:
I think we've detoured from the actual problem?
The fact is that lots of spam is now being sent to other sites, pretending
to be from (collectively) our email addresses, so that we get the bounces
containing the spam. And SA isn't marking these messages as spam, whereas
if it was directly sent the same spam, it would.
So how do we fix this situation? What about getting SA to "detach" the
associated bounced message as a separate message and score that instead? I
know I can casually just say that - doing is a different matter - but
isn't that really the only answer to this problem?
How are others (successfully) handling backscatter? Moving bounces into
yet another separate folder isn't a solution for our users - and I'm sure
the same applies elsewhere. Spam is spam...
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Best Regards,
Jeff Koch, Intersessions
