Hi all, Just trying to track down whose bug this is:
I run a mime checking acl in exim and reject mail that supposedly does
anything non-standard. (helps to pick up virii)
I notice that some base64 encoded attachments fropm Squirrelmail trigger
this and get rejected.
I am running squirrelmail 1.4.4-6sarge1 under debian sarge.
I ran some tests and noticed the following:
When squirrelmail attaches a file, the encoding finishes up like this:
.
.
.
AAAAAAAAAQAgALaBAAAAAFNJTUVRQVROLjgzUFBLAQIUABQAAgAIAAdNhgHB78I1ZwAAAJYAAAAM
AAAAAAAAAAEAIAC2gVIBAABTaW1lcWF0bi5uZm9QSwUGAAAAAAIAAgB0AAAA4wEAAAAA------=_20051213101035_76559--
Notice that the boundary part is tacked onto the end of the last line.
This has the affect of making the last line longer than 76 characters
and also introduces characters that are not part of mime base64 encoding
scheme.
Hence my exim acl rejects the mail for two reason:
demime acl condition: base64 line length exceeds 76 characters
demime acl condition: base64 line contains illegal character
Who is right here? Is it legal to tack the mime boundary straight on the
end of the base64 encoding?
For what it is worth, mutt encodes the same file like this:
.
.
.
UFBLAQIUABQAAgAIAAdNhgHB78I1ZwAAAJYAAAAMAAAAAAAAAAEAIAC2gVIBAABTaW1lcWF0
bi5uZm9QSwUGAAAAAAIAAgB0AAAA4wEAAAAA
--cWoXeonUoKmBZSoM--
Notice the blank line before the mime boundary.
Also, can anyone confirm that the behaviour is the same or different in
more recent versions of squirrelmail or non debian versions?
cheers
dc
--
David Purton
[EMAIL PROTECTED]
For the eyes of the LORD range throughout the earth to
strengthen those whose hearts are fully committed to him.
2 Chronicles 16:9a
signature.asc
Description: Digital signature
