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
