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...
>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