> Is there any experience about creating a application, which reads/
> receives mail from a mail server?
> I did found about sending, but I need for receiving mail.

No, this has never been done before. ;-)

The question you should be asking yourself is "which protocol(s) do
I want to support?". The answer to that question is also the best
search terminology to use with Google or this list's archives. Namely
POP3 / IMAP and Cocoa.

>> Is there any experience about creating a application, which reads/
>> receives mail from a mail server?
>> I did found about sending, but I need for receiving mail.>
> No, this has never been done before. ;-)

I was afraid of this. So I will have the ultimate app later.

>
> The question you should be asking yourself is "which protocol(s) do
> I want to support?". The answer to that question is also the best
> search terminology to use with Google or this list's archives. Namely
> POP3 / IMAP and Cocoa.

Just POP3. For cocoa, I did found only pantomine, and that's to heavy.
I was also looking for a blog or article about this subject.
Like firewall issues, sockets e.t.c. Just to get better and more
informed.

POP3 itself is pretty easy. It's a protocol that was designed to be
typed in manually by humans, and hence, it's pretty easy to just look
at the POP3 RFC documentation and write your app to send/receive the
command. The thing where it becomes difficult is parsing the actual
messages themselves: The RFC 822 message format and its extensions
(MIME etc.) are quite involved, and if you want to handle all that
correctly, you'll have a bunch of work ahead of you. If you want to
also handle all messages that some of the less standards-compliant
mail clients may throw at you, you'll have even more work.

> For cocoa, I did found only pantomine, and that's to heavy.

Well, it's intended to be used for cloning an application like
Mail.app, and last I checked, PantoMIME was very lightweight if you
considered that.

And that only demonstrates SMTP. But as I said, the protocol was
designed for humans. Generally you send a line, get a line (or
several). The RFCs are also pretty nicely written.

> Like firewall issues, sockets e.t.c. Just to get better and more
> informed.

Well, sockets are a Unix standard thing, so you can probably get a
good book on Unix sockets and that'll inform you much more than
anyone here can. There's not much Firewall stuff you should have to
do: Your application is making an outgoing connection, and the server
should have the right ports open. It should Jsut Wrok(tm).

One Cocoa-specific trick: After you've opened the socket, create an
NSFileHandle for your connection. That makes reading/writing much
more convenient. I just wrote myself wrappers for line-wise reading
of ASCII strings and put them in an object of my own that owns the
NSFileHandle. Worked beautifully. Also, keep in mind to do all this
stuff on a second thread, so the user can use the GUI even while
you're downloading e-mail.

That said, there's a couple of URL connection and socket classes
out there that might also be handy.

> Am 01.10.2007 um 20:48 schrieb René v Amerongen:>> Just POP3.>
> POP3 itself is pretty easy. It's a protocol that was designed to
> be typed in manually by humans, and hence, it's pretty easy to just
> look at the POP3 RFC documentation and write your app to send/
> receive the command. The thing where it becomes difficult is
> parsing the actual messages themselves: The RFC 822 message format
> and its extensions (MIME etc.) are quite involved, and if you want
> to handle all that correctly, you'll have a bunch of work ahead of
> you. If you want to also handle all messages that some of the less
> standards-compliant mail clients may throw at you, you'll have even
> more work.

Text and url pointers to get extra information about where to get
blobs ( also in an separated thirt thread ). But the url's are of
course just text.

> >> For cocoa, I did found only pantomine, and that's to heavy.>
> Well, it's intended to be used for cloning an application like
> Mail.app, and last I checked, PantoMIME was very lightweight if you
> considered that.

Hmmm, maybe I could use a part of it. I will check the licence.

> >> I was also looking for a blog or article about this subject.>
> Well, I only know a German page from Mannheim University:
>
> http://krum.rz.uni-mannheim.de/inet-2003/
>
> And that only demonstrates SMTP. But as I said, the protocol was
> designed for humans. Generally you send a line, get a line (or
> several). The RFCs are also pretty nicely written.
> >> Like firewall issues, sockets e.t.c. Just to get better and more
>> informed.>
> Well, sockets are a Unix standard thing, so you can probably get a
> good book on Unix sockets and that'll inform you much more than
> anyone here can. There's not much Firewall stuff you should have to
> do: Your application is making an outgoing connection, and the
> server should have the right ports open. It should Jsut Wrok(tm).

I just did buy an older version of 'core macosx and unix'. I have
something to read.

>
> One Cocoa-specific trick: After you've opened the socket, create
> an NSFileHandle for your connection.

I remember something about that. I did read this somewhere to.
Thanks for mention this.

> That makes reading/writing much more convenient. I just wrote
> myself wrappers for line-wise reading of ASCII strings and put them
> in an object of my own that owns the NSFileHandle. Worked
> beautifully. Also, keep in mind to do all this stuff on a second
> thread,

I did prepare that already, but I dont know why, but I have scary
feelings about how to pass through the handle or socket to another
thread to follow the input and output stream, like in the image athttp://krum.rz.uni-mannheim.de/inet-2003/ -=> sockets -=> Pic. E

> so the user can use the GUI even while you're downloading e-mail.
>
> That said, there's a couple of URL connection and socket classes
> out there that might also be handy.

> Op 2-okt-2007, om 10:01 heeft Uli Kusterer het volgende geschreven:
> >> Am 01.10.2007 um 20:48 schrieb René v Amerongen:>>> Just POP3.>>
>> POP3 itself is pretty easy. It's a protocol that was designed to
>> be typed in manually by humans, and hence, it's pretty easy to
>> just look at the POP3 RFC documentation and write your app to send/
>> receive the command. The thing where it becomes difficult is
>> parsing the actual messages themselves: The RFC 822 message format
>> and its extensions (MIME etc.) are quite involved, and if you want
>> to handle all that correctly, you'll have a bunch of work ahead of
>> you. If you want to also handle all messages that some of the less
>> standards-compliant mail clients may throw at you, you'll have
>> even more work.>
> Text and url pointers to get extra information about where to get
> blobs ( also in an separated thirt thread ). But the url's are of
> course just text.

I don't understand what you mean here... if you are talking about
loading additional resources linked to from HTML e-mails, yes, that
could be an additional thing to do, but you could also just use
WebKit to display those, maybe with a custom URL loader that allows
referencing images attached to the message using relative URLs. MIME
is how attachments are stored.

>>> For cocoa, I did found only pantomine, and that's to heavy.>>
>> Well, it's intended to be used for cloning an application like
>> Mail.app, and last I checked, PantoMIME was very lightweight if
>> you considered that.>
> Hmmm, maybe I could use a part of it. I will check the licence.

IIRC it's LGPL.

>> That makes reading/writing much more convenient. I just wrote
>> myself wrappers for line-wise reading of ASCII strings and put
>> them in an object of my own that owns the NSFileHandle. Worked
>> beautifully. Also, keep in mind to do all this stuff on a second
>> thread,>
> I did prepare that already, but I dont know why, but I have scary
> feelings about how to pass through the handle or socket to another
> thread to follow the input and output stream, like in the image at
> http://krum.rz.uni-mannheim.de/inet-2003/ -=> sockets -=> Pic. E

That picture is about using Java and sockets to communicate between
two applications. Nothing is being passed around there. You said you
wanted to implement a POP3 client, so you only need to handle one
half of this diagram. It's really easy, trust me. Just start a new
thread, and have that create the socket and file handle, and use the
blocking I/O code in NSFileHandle. Since this is a separate thread,
it's OK to block, because control will be given back to the main
thread while you're blocking.

The only thing where you have to be careful is when you give back
the received data to the main thread (e.g. add the e-mail object you
created to your array of messages in the inbox). In that case, you
need to either do this on the main thread, or use a lock of sorts
(NSLock or @synchronized or whatever), so you don't try to insert
something in the array in one thread while your UI thread is
iterating over the message list. The easiest way is probably to just
use performSelectorOnMainThread to pass a "message" object to the
main thread and have it added there.

>> so the user can use the GUI even while you're downloading e-mail.
>>
>> That said, there's a couple of URL connection and socket classes
>> out there that might also be handy.>
> I will search for them

I think I used NetSocket once, which was kind of OK. But really,
you only really need those if you want to implement a server, or if
you're really scared of sockets. But If you're implementing a client,
it's pretty straightforward to just connect to a particular host at a
particular port (all the complicated threading and forking is
happening on the server side, completely transparently for you), you
get back a file descriptor, and then you create an NSFileHandle for
that, and use it to write your requests and read the answers, line-wise.

>>> For cocoa, I did found only pantomine, and that's to heavy.>>
>> Well, it's intended to be used for cloning an application like
>> Mail.app, and last I checked, PantoMIME was very lightweight if
>> you considered that.>
> Hmmm, maybe I could use a part of it. I will check the licence.

I've used a part of it for DEVONthink Pro Office for their mail
archive plugin and it's a nice library. Rather easy to use and Ludo
is very helpful and flexible. And like someone before me posted on
this thread: you do not want to reinvent a MIME parser. It is a very
thankless task and prone with all kinds of exceptions (it reminds me
of HTML parsing a lot of times, some mail apps seem not to follow the
RFC to the letter).

>
> One Cocoa-specific trick: After you've opened the socket, create
> an NSFileHandle for your connection. That makes reading/writing
> much more convenient. I just wrote myself wrappers for line-wise
> reading of ASCII strings and put them in an object of my own that
> owns the NSFileHandle. Worked beautifully. Also, keep in mind to do
> all this stuff on a second thread, so the user can use the GUI even
> while you're downloading e-mail.
>

Just a non-related question, why do you prefer sockets +
NSFileHandle / (insert a network framework here) instead of NSStream?
I'm asking because I'm working on a project and we went to NSStream
route, and got SSL/TLS for "free".

> On Oct 2, 2007, at 05:01 , Uli Kusterer wrote:
>
> [ snip ]
> >> One Cocoa-specific trick: After you've opened the socket, create
>> an NSFileHandle for your connection. That makes reading/writing
>> much more convenient. I just wrote myself wrappers for line-wise
>> reading of ASCII strings and put them in an object of my own that
>> owns the NSFileHandle. Worked beautifully. Also, keep in mind to
>> do all this stuff on a second thread, so the user can use the GUI
>> even while you're downloading e-mail.
>> >
> Just a non-related question, why do you prefer sockets +
> NSFileHandle / (insert a network framework here) instead of
> NSStream? I'm asking because I'm working on a project and we went
> to NSStream route, and got SSL/TLS for "free".
>
> <http://developer.apple.com/documentation/Cocoa/Conceptual/Streams/

> Articles/NetworkStreams.html>

Indeed, I was also going to say that CF/NSStream is probably a better
match for sockets. Also, I'm not sure if CF/NSStream suffer from the
bug in various NSFileHandle methods where an EINTR return from a
system call triggers an exception. (It shouldn't; it should just
cause the code to retry the system call, but that's now how it works
right now.)

(Since you mention it, it's worth noting, by the way, that SSL and
TLS support is slightly limited, in that you don't get proper support
for client certificates [because the underlying Secure Transport code
still doesn't have that]. It might work as long as you only have a
single client cert on your machine, but it won't work in the more
general case where you may have more than one.)

> Just a non-related question, why do you prefer sockets +
> NSFileHandle / (insert a network framework here) instead of
> NSStream? I'm asking because I'm working on a project and we went
> to NSStream route, and got SSL/TLS for "free".

Mainly because when I last tried to write an e-mail client,
NSStream didn't yet exist, and I just looked at the sockets part of
my code when I answered this question. I can't give any tips
regarding NSStream, but it should work.