Is there any suggestions on a rule or procedure to implement that will help defend against the MAILSPLOIT type of spoofing?

Full details of it here: https://www.mailsploit.com/index

I was thinking if there is a way to have a rule that checks for encoding in the FROM header. OR better, maybe it could be expanded to only react if the decoded FROM header translates to a domain that is not a match to the domain in the raw data

eg (from the mailsploit webpage example)

|=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com|

translates to 'FROM: po...@whitehouse.com' even though the raw line clearly says "....@mailsplot.com.

Sadly, it is obvious to most that the translating of the encoded from data is dependant on the email client but Mozilla (Thunderbird) refuse to acknowledge this and claim it to be the responsibility of the server (as stated in the info web page). Therefore a rule in spamassassin that can independently see these attempts of tom-foolery and stop it at server level would remove the risk of the email clients being fooled.

(p.s I performed the test from the webpage to my server and email client and confirm that Thunderbird does get fooled by the exploit).
||

Reply via email to