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