mail-in db/app

  • Hello

    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.

    thanks

    RvA
  • > 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.

    --
    I.S.
  • Op 1-okt-2007, om 19:34 heeft I. Savant het volgende geschreven:

    >> 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.

    Thanks l.S

    Someone else more?

    RvA
  • 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.

    > 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.

    > 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).

      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.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • 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.

    >
    >> 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 at
    http://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.

    I will search for them

    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >

    Thank you

    René
  • Am 02.10.2007 um 10:31 schrieb René v Amerongen:
    > 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.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On 2 Oct 2007, at 10:31, René v Amerongen wrote:

    >>> 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).

    Annard
  • 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
    >

    :: marcelo.alves
  • On 2 Oct 2007, at 13:48, Marcelo Alves wrote:

    > 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.)

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • Am 02.10.2007 um 14:48 schrieb Marcelo Alves:
    > 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.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today