Hi all --
This is not *really* an Exim question, but this list has a lot of
collective RFC (2)822 expertise, so I thought I'd bring this up as a
point of curiosity.
A mailing list we run recently received a legitimate, non-spam message
with the following headers:
MIME-Version: 1.0
Message-Id: <3BF4D342.24968@mta4>
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 16 Nov 2001 16:50:10 +0800 (CST)
From: dchli@???
To: mems-talk@???
Subject: =?gb2312?B?TUVNUyBUZXN0aW5nIQ==?=
X-Originating-IP: [162.105.201.36]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
X-Converted-To-Plain-Text: from Multipart/Alternative by demime 0.98e
X-Converted-To-Plain-Text: Alternative section used was text/plain
Note the garbled subject line.
Can anyone explain what encoding is being used in this subject line? It
*looks* like base64, but I tried running it through Python's base64
module, and it complained of incorrect padding.
More importantly, can someone give me good, solid, technical grounds on
which to recognize such garbled subject lines and reject them? This
doesn't violate the *letter* of RFC 822 (the subject line is all 7-bit
ASCII), but it sure as hell violates the *spirit*. ArghhH!
Obligatory Exim content: how can I make Exim recognize and reject this?
;-) Perhaps something in the system filter like this:
if $header_subject matches ^=\S+=\$ then
# ... reject, subject line is junk ...
endif
I can't think of any good reason to accept a subject line that starts
and ends with '=' and has no intervening spaces. But this feels like a
rather flimsy regex. Ideas?
Thanks --
Greg
--
Greg Ward - software developer gward@???
MEMS Exchange http://www.mems-exchange.org
