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: Kok-Yong Tan <email@hidden>
- Date: Thu, 10 Feb 2011 11:56:13 -0500
See replies inline.
On Thu, Feb 10, 2011, at 07:46, Axel Luttgens wrote:
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.
My pleasure.
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
<
johndoe
@example.com>;=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.
Interesting. Thank you for a very enlightening analysis. I would
never have been able to notice that very subtle discrepancy in that
immense volume of data.
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.
I'm afraid not. I tossed them.
But I fear we are somehow leaving the world of AppleScript,
here... ;-)
True. But since we know that we have a "workaround" in that saving to
file and then attaching the file always works (as done in the original
Applescript), it comes back to the question of why the original
Applescript occasionally drops an attachment or two or six during the
attaching process and how to fix that annoying problem... I know that
inserting delays into the Applescript doesn't work.
Tan
--
Reality Artisans, Inc. # Network Wrangling and Delousing
P.O. Box 565, Gracie Station # Apple Certified Consultant
New York, NY 10028-0019 # Apple Consultants Network member
<http://www.realityartisans.com> # Apple Developer Connection member
(212) 369-4876 (Voice) # My PGP public key can be found
at <https://keyserver.pgp.com>
_______________________________________________
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