Re: SpamCop script which worked in Tiger suddenly dropping some attachments in Leopard
Re: SpamCop script which worked in Tiger suddenly dropping some attachments in Leopard
- Subject: Re: SpamCop script which worked in Tiger suddenly dropping some attachments in Leopard
- From: Tommy Bollman <email@hidden>
- Date: Fri, 11 Feb 2011 18:41:05 +0100
Hello
I have followed this thread, and I remembered some debug settings you can enable in mail via the "defaults system".
Those settings may or may not help you, but they can be found at:
http://hints.macworld.com/article.php?story=2004101603285984&query=mail+debug+settings
HTH
Tommy
Den 10. feb. 2011 kl. 13.46 skrev Axel Luttgens:
> Le 9 févr. 2011 à 23:19, Kok-Yong Tan a écrit :
>
>> [...]
>>
>> I'll send you both of my tests above in raw source and the results from SpamCop as 4 separate emails privately so you can see what I mean. [...]
>
> Thanks Tan.
>
> OK, there's something wrong at work here.
> The problem seems to appear when Mail (at least on OSX 10.5.8) encounters an email needing to be encoded for building the attachment and chooses to make use of quoted-printable encoding.
>
> When attaching the email's raw source stored in a file (i.e. "make new attachment..."), the encoded data is attached without alteration.
>
> When making use of the menu item "Message/Forward as Attachment", the encoded data is the same as the one obtained with the former method, yet a slight alteration may occur from times to times: an extraneous empty line gets added near the beginning of the encoded data.
>
> For example (slightly altered to preserve the innocent):
>
> =46rom=email@hidden=20Wed=20Feb=20=209=2003:24:49=202011=0A=
> Lines:=2024=0AReturn-Path:=20<email@hidden>=0AX-Original-To:=20=
> email@hidden=0ADelivered-To:=email@hidden=0AReceived:=20from=20=
>
> mail2.example.com=20(mail2.example.com=20[192.168.1.1])=0A=09by=20=
> mailbackend.example.com=20(Postfix)=20with=20ESMTP=20id=2073D8132E63=0A=09=
> for=20<email@hidden>;=20Wed,=20=209=20Feb=202011=2003:24:49=20-0500=20=
>
> which translates into:
>
> From email@hidden Wed Feb 9 03:24:49 2011
> Lines: 24
> Return-Path: <email@hidden>
> X-Original-To: email@hidden
> Delivered-To: email@hidden
> Received: from
> mail2.example.com (mail2.example.com [192.168.1.1])
> by mailbackend.example.com (Postfix) with ESMTP id 73D8132E63
> for <email@hidden>; Wed, 9 Feb 2011 03:24:49 -0500
>
> This is of course wrong, since one should have:
>
> From email@hidden Wed Feb 9 03:24:49 2011
> Lines: 24
> Return-Path: <email@hidden>
> X-Original-To: email@hidden
> Delivered-To: email@hidden
> Received: from mail2.example.com (mail2.example.com [192.168.1.1])
> by mailbackend.example.com (Postfix) with ESMTP id 73D8132E63
> for <email@hidden>; Wed, 9 Feb 2011 03:24:49 -0500
>
> but doesn't really matter for SpamCop's engine: "Received: from" and "mail2.example.com ..." are just malformed headers and are simply skipped.
>
> But such an extraneous empty line may also be inserted at a very bad place:
>
> =46rom=email@hidden=20Wed=20Feb=20=209=2005:11:47=20=
> 2011=0ALines:=2020=0AReturn-Path:=20<email@hidden>=0A=
> X-Original-To:=email@hidden=0ADelivered-To:=email@hidden=0A=
> Received:=20from=20mail1.example.com=20(mail1.example.com=20[192.168.1.1])=0A=
>
> =09by=20mailbackend.example.com=20(Postfix)=20with=20ESMTP=20id=20=
> 048C132C14=0A=09for=20<email@hidden>;=20Wed,=20=209=20Feb=202011=20=
> 05:11:47=20-0500=20(EST)=0AReceived:=20from=20stephe170.lnk.telstra.net=20=
>
> Translation:
>
> From email@hidden Wed Feb 9 05:11:47 2011
> Lines: 20
> Return-Path: <email@hidden>
> X-Original-To: email@hidden
> Delivered-To: email@hidden
> Received: from mail1.example.com (mail1.example.com [192.168.1.1])
>
> by mailbackend.example.com (Postfix) with ESMTP id 048C132C14
> for <email@hidden>; Wed, 9 Feb 2011 05:11:47 -0500 (EST)
> Received: from stephe170.lnk.telstra.net (stephe170.lnk.telstra.net
>
> No luck here: an encoded linefeed (=0A) is followed by that extraneous empty line, and thus yields an empty line in the unencoded message. Such an empty line means: end of the message's headers, body follows. As a result, SpamCop's engine gives up for that message.
>
> It thus seems there's a bug with the way "Message/Forward as Attachment" handles emails needing to be encoded, when the encoding is quoted-printable.
>
> Note that the extraneous empty line isn't always inserted (see for example the message with subject "DEAR BELOVED ONE(PLEASE USE THE DONATION FOR MOTHERLESS)"), as if the structure of only some messages triggered the bug.
>
> I'll try to see whether such a behavior can be reproduced here on 10.6.6.
>
> BTW, do you still have those spams:
>
> Fw: news
> YOUR DEPOSITED FUND WITH OUR BANK
> Great prices is available! Order Xanax Online at cheap price
>
> If yes, it would be interesting to check whether applying "Message/Forward as Attachment" upon those messages systematically inserts extraneous empty lines, always at the same place.
>
> But I fear we are somehow leaving the world of AppleScript, here... ;-)
>
> Axel
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> AppleScript-Users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> Archives: http://lists.apple.com/archives/applescript-users
>
> This email sent to email@hidden
>
Best regards
Tommy Bollman
--------------------------------------------------------------------------------------------------
Mollison's Bureaucracy Hypothesis:
If an idea can survive a bureaucratic review
and be implemented it wasn't worth doing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden