Kjetil Torgrim Homme <kjetilho(_at_)ifi(_dot_)uio(_dot_)no> writes:
>> For an example of a less general than expected test,
>> consider looking for Subject: containing "MAKE MONEY FAST"
>> to filter spam into a separate folder, and an incoming
>> message having a Subject: of "=?CP-1252?q?MAKE_MONEY_FAST?=.
>
> I believe that message should be filtered just fine.
How? Compare the following from RFC 3028 [2.7.2]. Assuming the
implementation does not support CP-1252, I don't see how "MAKE
MONEY FAST" and "=?CP-1252?q?MAKE_MONEY_FAST?=" would match.
oh, I assumed that an implementation would decode quoted-printable and
base64, but mark the string as "unknown charset". that seems to "do
what I want" more often.
That approach would only work, for this example, if the unknown
charset was ASCII compatible. Of course, non-ASCII charset doesn't
occur in practice, but I was talking about the case where the sender
acts malicously to cause certain behaviour the user didn't think of.
If picking a non-ASCII charset makes the client behave badly, the
attacker will do so.
iso-2022-* charsets commonly occur in practice, and are not ASCII compatible
in this sense.
But I agree that your draft isn't the place for these generic Sieve
security considerations.
Exactly.
Ned