"Dee Earley" <dee.ear***@icode.co.uk> wrote in message
news:%23QILCEmTLHA.5944@TK2MSFTNGP06.phx.gbl...
> On 06/09/2010 20:55, fniles wrote:
>> Using winsock, how can I read POP 3 email attachment (the attachment is
>> an
>> .EML file) ?
>
> Have a look at RFC1939 for the POP3 protocol (It's as easy as login, get
> message, disconnect), and then RFC822, the MIME/multipart MIME specs and
> base64 decoding (if required).
> If the attachment is another email, then that is nothing special, it's
> just the same structure again.
>
> --
> Dee Earley (dee.ear***@icode.co.uk)
> i-Catcher Development Team
>
> iCode Systems
>
> (Replies direct to my email address will be ignored.
> Please reply to the group.)

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:i66vu7$bup$1@news.eternal-september.org...
>  I just tried this. It's a little bit tricky, at least in
> OE, because the attached email was not fully
> encoded. It was just sandwiched. Normally when you
> attach a file it gets inserted as a single Base64 string.
> (Note that you may have to remove carriage returns,
> tabs, or other formatting junk before decoding Base64.)
>
> Here's a sample of the format for an email with
> a JPG attachment. Note that the "boundary" value
> defines a random string that separates sections of the
> email. The email is parsed using boundary markers
> and empty lines to identify content. Boundaries must
> begin with "--". The closing boundary begins with
> "--" and also ends with "--".
>
> _________ Begin sample ______________
>
> from
> to
> date
> subject
> Message-ID
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> boundary="BOUNDARY_STRING_1"
> X-Mailer: [email program name here]
> #
> --BOUNDARY_STRING_1
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> #
> (email text here)
> #
> --BOUNDARY_STRING_1
> Content-Type: image/jpeg;
> name="pic1.jpg"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="pic1.jpg"
> #
> (base 64 here)
> #
> --BOUNDARY_STRING_1--
>
> ________________ end sample ________
>
> Notice that the attachment is identified
> with the line:
>
> Content-Disposition: attachment
>
>  The beginning of the attachment info. is marked
> by a boundary string. The Base64 string representing
> the actual file content has an empty line before and
> after. So it's fairly easy to check for attachments
> and it's easy to extract the attachment(s).
>
>  When I created an email with an attachment, then
> attached that to another email, I ended up with the
> entire first email copied in the second email. It began
> with this:
>
> Content-Type: message/rfc822;
> name="mmm.eml"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment;
> filename="mmm.eml"
>
> But then instead of a blank line followed by Base64, there
> was a blank line followed by the raw text of the first email:
>
> From:
> To:
> Subject:
>  ..etc.
>
> The attachment in the attached email is still there. Then
> the end is like this:
>
> --Boundary_string_from_attached_email--
>
> --Boundary_string_from_main_email--
>
>
>  So you have to parse an email within an email. But as
> you can see from the snippets I've posted, it still follows
> standards. You'll look for
>
>  Content-Disposition: attachment
> with
>  Content-Type: message/rfc822
>
> (It may be possible for an email to have other content
> type. i'm not sure.)
>
> The attached email will start after the next blank line.
> From there you find
>
> boundary=
>
> then find the end of the attached email by
> looking for that with "--" appended. Note,
> however, that the boundary is only necessary
> where Content-Type is multipart/*
> If Content-Type is text/plain in the attached
> email, the end of the attached email may be delineated
> only by a boundary marker in the main email.
>
>  Basically, attached plain text is inserted as
> plain text. Attached binary data is base64-encoded.
> In the case of an attached email with attachments,
> the attachment can be both because the actual file
> content of the attached .EML is both. (It's all plain
> text, technically, but any base64-encoded content
> represents binary data.) So in order to
> know whether you need to do any base64 decoding you
> need to check the Content-Type of the attachment.
> And you might have to do that recursively if you have
> an attached EML file.
>
> (I know this all sounds confusing, but it's actually
> a simple and fairly sensible system once you get
> the gist of it.)
>
>