[REBOL] import-email: a bug?
Hi all, experimenting mail filters and talking to Phil Bevan some problems with email headers faced us: 1) Missing colon I had a problem when writting my email client sometimes the incoming message started From instead of From: (ie no colon ...) which caused import-mail to fail. 2) Huge To: or Cc: fields Havent had any problems with multiple recipients though 3) Splitted lines looks like import email doesnt like the first line which has been split up with = signs. Received: from x400.icl.co.uk (umg1.x400.icl.co.uk [145.227.248.89]) by = wwmessd045.man23.icl.local with SMTP (Microsoft Exchange Internet Mail = Service Version 5.5.2653.13) If the equals signs are removed then import-email will work. I want to report it via feedback but the proxy still isolates me, so I hope someone at RT (Holger, Jeff, Carl!?) takes a look here. Has anyone out there a patch/rewrote of import-email or some hint to handle strange headers? No parse-ability, here... :( 8-- ? import-email USAGE: IMPORT-EMAIL data DESCRIPTION: Constructs an email object from an email message. IMPORT-EMAIL is a function value. ARGUMENTS: data -- The email message (Type: string) source import-email import-email: func [ Constructs an email object from an email message. data [string!] The email message /local content ][ data: parse-header system/standard/email copy/part data content: any [find/tail data ^/^/ tail data] data/date: parse-header-date data/date data/from: parse-email-addrs data/from data/to: parse-email-addrs data/to data/reply-to: parse-email-addrs data/reply-to data/content: content data ] --8 In import-email I really miss something to import real names from addresses, like: [...] From: Gino Pilotino [EMAIL PROTECTED] [...] msgheader/from-real == Gino Pilotino actually only: msgheader/from == [EMAIL PROTECTED] Xie-xie Ni-men Mario Cassani -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with unsubscribe in the subject, without the quotes.
[REBOL] import-email
Hi Rebols,
can someone enlighten me, on how import-email is
supposed to work?
I saved an email that I sent locally and try to
import it, that's what I get.
;; START OF Rebol session
m: read %mail
== {From [EMAIL PROTECTED] Thu Nov 11 14:36:01 1999
Received: from localhost (fuchur) [127.0.0.1] (ingo)
^-by localhost with smtp (Exim 2...
print m
From [EMAIL PROTECTED] Thu Nov 11 14:36:01 1999
Received: from localhost (fuchur) [127.0.0.1] (ingo)
by localhost with smtp (Exim 2.05 #1 (Debian))
id 11luOO-MY-00; Thu, 11 Nov 1999 14:36:00 +0100
To: "Ingo Hohmann" [EMAIL PROTECTED],
"Root" [EMAIL PROTECTED],
"Tester" [EMAIL PROTECTED]
From: "Ingo Hohmann" [EMAIL PROTECTED]
Date: Thu, 11 Nov 1999 14:36 +0100
Subject: test
X-REBOL: 2.2.0.4.2 "The Internet Messaging Language (TM) WWW.REBOL.COM"
Message-Id: E11luOO-MY-00@localhost
Status: RO
Content-Length: 93
Lines: 4
test
--
Und etwas mehr ...
im: import-email m
probe im
make object! [
To: none
CC: none
BCC: none
From: none
Reply-To: none
Date: none
Subject: none
Return-Path: none
Organization: none
Message-Id: none
Comment: none
X-REBOL: {2.2.0.4.2 "The Internet Messaging Language (TM) WWW.REBOL.COM"}
MIME-Version: none
Content-Type: none
Content: {test
--
Und etwas mehr ...
}
]
Do I do something wrong?
BTW, its 2.2.0.4.2, and I have not yet started to
patch import-email or its helpers ;-)
regards,
Ingo
-- _ ._
ingo@)|_ /| _| _ We ARE all ONE www._|_o _ _ ._ _
www./_|_) |o(_|(/_ We ARE all FREE ingo@| |(_|o(_)| (_|
http://www.2b1.de/Rebol/ ._| ._|
[REBOL] import-email Re:(2)
Hi Jeff, you wrote:
[snip]
The first line there confuses IMPORT-EMAIL. Set-words are
being looked for, (from: subject: etc..) and the 'from' on
the first line in UNIX mail format and eudora format doesn't
have a colon after it. The fix is to either skip a line, or
skip forward to a field you want to have, that is:
mail-obj: IMPORT-EMAIL FIND message "Received:"
I first thought so too. However, check this out:
message: {Return-Path: [EMAIL PROTECTED]
Received: from bigplanet.com (1Cust44.tnt1.providence.ri.da.uu.net
[63.21.181.44])
by patty.loop.com (8.9.3/8.9.3) with SMTP id XAA27885
for [EMAIL PROTECTED]; Sun, 26 Sep 1999 23:38:41 -0700 (PDT)
From: [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
Date: Mon, 27 Sep 1999 02:39:11 -0400 EDT
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
To: [EMAIL PROTECTED]
Subject: New Online Business Databases on CD-ROM
X-UIDL: a99d25d6bc54cd513a9e2a403cc65a41
Dear Elan,
I wanted to share with you the latest update to our cutting edge database
of online businesses.
}
msg: import-email message
probe msg
make object! [
To: none
CC: none
BCC: none
From: none
Reply-To: none
Date: none
Subject: none
Return-Path: "[EMAIL PROTECTED]"
Organization: none
Message-Id: none
Comment: none
X-REBOL: {2.2.0.3.1 "The Internet Messaging Language (TM) WWW.REBOL.COM"}
MIME-Version: none
Content-Type: none
Content: {Dear Elan,
I wanted to share with you the latest update to our cutting edge database
of online businesses.
}
Received: {from bigplanet.com (1Cust44.tnt1.providence.ri.da.uu.net
[63.21.181.44])}
]
Pretty much everying is set to none. The fields To and Subject, for
instance, are provided in the email. Here the problem is not due to the
first line.
The problem was that the message includes newlines here:
Received: from bigplanet.com (1Cust44.tnt1.providence.ri.da.uu.net
[63.21.181.44])
by patty.loop.com (8.9.3/8.9.3) with SMTP id XAA27885
for [EMAIL PROTECTED]; Sun, 26 Sep 1999 23:38:41 -0700 (PDT)
I believe that these multiple lines in the Received field threw
header-rules/parse-head off as well.
header-rules/parse-head expects to find a new field on each line (I
believe, after quickly browsing the code), doesn't it?
Probably the better solution would be to first check the header for
conformance with the parse rules, either remove lines that do not conform
or reformat them so that they do and then parse the stuff. If modifications
were made, this could be reported in an additional Parse-Error-Report field
in the header.
BTW, Ingo, if you want to check it out for yourself, look at:
source import-email
source parse-header
probe header-rules
that should tell you everything you could possible want to know. I don't
have the time right now to review the stuff in detail.
Hope this helps,
Elan
[REBOL] import-email Re:(3)
Howdy Elan: I believe that these multiple lines in the Received field threw header-rules/parse-head off as well. header-rules/parse-head expects to find a new field on each line (I believe, after quickly browsing the code), doesn't it? Good job! Would that everyone was as diligent as you at finding the source of bugs. Sometimes our bug database winds up with entries of gigantic run on scripts with the note "there is a bug in here". Boy--oh--boy! Those are the best. :-) Probably the better solution would be to first check the header for conformance with the parse rules, either remove lines that do not conform or reformat them so that they do and then parse the stuff. If modifications were made, this could be reported in an additional Parse-Error-Report field in the header. At some point we'll have to make IMPORT-EMAIL more robust. So many little dangling items to get worked out with core, though we're swamped on command. Of course, I'm sure that if someone fixed IMPORT-EMAIL and sent it in, with a little due process on our part, we'd certainly include it in the core and give credit within the source of the code. No one ever takes my threats seriously... )-: (-: Cheers-- -jeff
