HTML/Newsletters being received as unreadable code

Scott Silva ssilva at sgvwater.com
Wed Feb 20 20:57:06 GMT 2008


on 2/20/2008 12:32 PM Scott Silva spake the following:
> on 2/20/2008 8:03 AM Julian Field spake the following:
>>
>>
>> Mark Sapiro wrote:
>>> Steve Freegard wrote:
>>
>>
>>>> Andrew Chester wrote:
>>>>    
>>>>> X-Ukuvuma Solutions-MailScanner-From: support at kalahari.net
>>>>>       
>>>>           ^^^
>>>>
>>>> There's your problem - you have spaces in your %org-name% setting in 
>>>> MailScanner.conf.
>>>>     
>>> While the space in %org-name% is wrong, it does not seem to be the
>>> cause of the problem.
>>
>>> Here's what I see in the last few headers and body:
>>
>>> ---------------------------------------------------------------
>>> content-transfer-encoding: base64
>>> content-type: text/plain; charset=utf-8
>>
>>> X-Ukuvuma Solutions-MailScanner-From: support at kalahari.net
>>> X-Spam-Status: No
>>
>>> X-Ukuvuma Solutions-MailScanner-From: support at kalahari.net
>>> X-Spam-Status: No
>>
>>> WW91ciBLYWxhaGFyaS5uZXQgcGFzc3dvcmQgaXMgODAwNjAwCi0tIApUaGlz
>>> IG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQKZGFu
>>> Z2Vyb3VzIGNvbnRlbnQgYnkgdGhlIFVrdXZ1bWEgQXBvbGxvIGdhdGV3YXkg
>>> YW5kIGlzCmJlbGlldmVkIHRvIGJlIGNsZWFuLgoK
>>> -----------------------------------------------------------------
>>
>>> The two sets of MailScanner headers are curious, but it looks from the
>>> Received: headers that the message passed twice through
>>> apollo.ukuvuma.co.za so it was probably scanned twice.
>>
>>> The real problem is the empty lines preceeding each set of MailScanner
>>> headers. This causes the MailScanner headers to be part of the body
>>> which totally destroys the base64 encoding and results in the garbled
>>> message.
>>
>>> I suspect that all base64 encoded messages get garbled this way and
>>> non-bas64 encoded messages show the MailScanner headers in the body.
>>
>>> Perhaps someone with more MailScanner experience has a clue as to why
>>> the MailScanner headers are preceded by an empty line.
>>
>> It's probably the MTA (or MailScanner) attempting to render the 
>> message in a form correct for the next mail handling program it passes 
>> through. There should always be a blank line after the last header. 
>> But I don't guarantee what MailScanner will do if the headers end on 
>> an incomplete line, as it never happens in real mail that hasn't been 
>> screwed by something (in your case, the space in %org-name%).
>>
>> The point about spaces in %org-name% is very clearly documented in the 
>> MailScanner.conf file.
>>
>> If you break that rule I make no guarantees what may happen to your mail.
>>
>> I will add some more code to check for that and flag it very boldly in 
>> the logs, and ensure that MailScanner --debug and MailScanner --lint 
>> check for it too.
>>
>> Jules
>>
> If you have to check for the space anyway, how hard would it be to force 
> the space to be an underscore? Still pound the logs with messages, but 
> at least it would work.
> 
I guess I need to read the list earlier out here in GMT-8 land.

-- 
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.mailscanner.info/pipermail/mailscanner/attachments/20080220/4dec934a/signature.bin


More information about the MailScanner mailing list