More encoded subject woes

[Nick Smith]

On 5/24/06, Julian Field <MailScanner at ecs.soton.ac.uk> wrote:
><snip>
>
> Before I read your solution I was already thinking that if I allow 20
> spaces on the end it would provide reasonable security against
> malicious subjects but still allow trailing spaces on possibly-
> malicious mime-encoded Subject: lines.
>
> So I would go for your suggestion, but how about we compromise on 10
> spaces instead of 2 or 20?
>
> There are many things like this where I have to apply as strict
> security as I can get while not breaking reasonable use of things
> like Subject: lines. It's a judgement call as to where to draw the line.
>
> I always err on the cautious side, as it is much better to slacken it
> off a little bit for some specific problem later, than it is to get a
> security vulnerability into the code that can actually be exploited.
> I believe firmly in "defence in depth" and so every bit of
> MailScanner is written looking from a hacker's point of view, so that
> you never actually create an exploitable vulnerability as there are
> so many layers the hacker would have to get through.
>
> --
> Julian Field
> www.MailScanner.info
> Buy the MailScanner book at www.MailScanner.info/store
> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> MailScanner thanks transtec Computers for their support.
>
> --
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
>
> Before posting, read http://wiki.mailscanner.info/posting
>
> Support MailScanner development - buy the book off the website!
>
Thanks Julian - I'd be entirely happy with any reasonable number >= 2.
Like you I was just trying to take the safe way by opening a crack in
the door just large enough to accommodate the real-life sample that
was hurting, but if you think it wouldn't hurt too much to open it a
little wider then that's fine with me

Picking up your comment about many other things like this - I did also
get bitten by an app that generated a MIME boundary with a leading
space. It's using a padded timestamp with the day of the month first
to create the boundary string, so on days 1-9 of every month the
boundary has a leading space. This leads to a "Could not analyze
message" report

Would you consider relaxing Message.pm's efforts ~line 1625 to look
for null boundaries so that it doesn't also consider leading
whitespace to be fatal?

Drew - next time I get an issue I'll pretend I'm using sendmail :)

Thanks

Nick