Email attachments

[LutherRevisited]

Is there a way I can put a message together without having to download any
attachments there may be at the same time. I'm not having any problems dealing
with attachments, but the way I'm doing things makes me download the complete
message first, attachements and all:
mail = []
for j in M.retr(i)[1]:
mail.append(j.rstrip())
inMail = email.message_from_string('\r\n'.join(mail))

I don't have a real problem per se with this, it's just that I would just as
soon not download the attachments as well at first. Also I'm wondering, are my
attachments potentially dangerous at the state when I first get them as part of
the email, or are they not potentially dangerous until I binary write that part
of the message into a file(that's how I'm dealing with attachments, if I want
to keep an attachment in the already downloaded complete email, I just write it
to a file.

[Josiah Carlson]

lu*************@aol.com (LutherRevisited) wrote:

Is there a way I can put a message together without having to download any
attachments there may be at the same time. I'm not having any problems dealing
with attachments, but the way I'm doing things makes me download the complete
message first, attachements and all:
mail = []
for j in M.retr(i)[1]:
mail.append(j.rstrip())
inMail = email.message_from_string('\r\n'.join(mail))

I don't have a real problem per se with this, it's just that I would just as
soon not download the attachments as well at first. Also I'm wondering, are my
attachments potentially dangerous at the state when I first get them as part of
the email, or are they not potentially dangerous until I binary write that part
of the message into a file(that's how I'm dealing with attachments, if I want
to keep an attachment in the already downloaded complete email, I just write it
to a file.

On POP3 mail servers, there are but two parts of the message; the header
and body. Some servers support the TOP command, which is used like so:
TOP <message> <bodylines>

With that command, you can get the headers and <bodylines> number of
lines from the body of the email message, on servers that support it.
Now, understand that in the case of POP3, the server does not understand
what you think of as an attachment. It is all just the body of the
email (likely encoded with base64), separated with section delimiters.

Also understand that the ordering of these "attachments" can be
arbitrary (include the binary attachment, then the plain text email,
then the html email), so you may need to download the entire email to
get the plain text message body.

- Josiah

[LutherRevisited]

Thanks, I looked into TOP and it looks like I'll be able to handle that issue
satisfactorily with at least one, maybe many, but not all servers. POP3 is not
looking good to me now, but with Yahoo what can you do....

[Josiah Carlson]

lu*************@aol.com (LutherRevisited) wrote:

Thanks, I looked into TOP and it looks like I'll be able to handle that issue
satisfactorily with at least one, maybe many, but not all servers.
Perhaps you missed the later part of my post when I explained that the
location of attachments can be arbitrary. That is, attached files can
come before what most people consider to be the body of the email (text
like what you are reading now). At best, using TOP is a 95% solution.
The 100% solution is to just download the email and call it good.

If you merely care whether there is an attachment or not, deciding based
on the size of an email (the sizes returned by LIST) can be reasonable.

POP3 is not looking good to me now, but with Yahoo what can you do....

Well, with Yahoo, you can only access them via POP3 if you have paid for
their services.

Really, mail access comes down to the simple maildrop approach that is
all client-side (POP3), or the complicated server handles everything
approach (IMAP4).

With a simple approach comes a simple protocol. POP3 servers and
clients can be implemented in an afternoon, and I have done so a few
times (it is what I get paid to do).

The IMAP4 spec is huge, and allows asynchronous command processing (the
server can reply to command B before command A when command A was given
first), which complicates matters. Having written partial IMAP4 servers
and clients, I will tell you that it is not really approachable in
anything less than a weekend.

I believe that the reason why very few large webmail providers offer
IMAP4 access is due to the protocol being very difficult to get right,
and because POP3 does most of what is necessary.
In my opinion, what is really needed is a protocol that sits between
POP3 and IMAP4. POP3 with folder support and a few other little pieces
would be sufficient to implement all the protocol necessary for a
full-on webmail service with the features of both Gmail and Yahoo Mail.
Unfortunately, the liklihood of this happening and becoming widespread
is very low; both the POP3 and IMAP4 RFCs have been around for quite a
while, and many among the email community believe that they are
sufficient.

Ah well...
- Josiah