POP use of UIDL command ?

POP use of UIDL command ?

am 11.03.2007 00:38:39 von news

It's not clear to me from my RFCs: 1939, 1725, 2449 how the
[list unique IDs of mails still on the server] UIDL is used.

I'm speculating that when a list of mails is left on the server and the
client, then the ability to check/synchronize the 2 lists-of-mails is
needed. Provision must be made for the possibility of mail[s] being
deleted from either the server or client, without the corresponding
client or server deletion; which would cause a loss of synchronism.

Q - what would the alrogithm be for using such UIDL facility ?

Perhaps:
ForEach ServerMail: Get the unique-ID;
Compare with the Client's listing & provide info. re. any miss-match.

Perhaps any mails which are on one only of the server and client,
would be marked as such ?

Forcing a synchronisation would need deleting the unmatched
mails ?

Thanks for any info.

== Chris Glur.

Re: POP use of UIDL command ?

am 11.03.2007 02:13:46 von Sam

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_mimegpg-commodore.email-scan.com-15704-1173575626-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

news@absamail.co.za writes:

> It's not clear to me from my RFCs: 1939, 1725, 2449 how the
> [list unique IDs of mails still on the server] UIDL is used.

It's for mail clients that cache message's contents. A mail client that
sees a UIDL for the first time recognizes that it's a new message, and will
download it. A mail client that already saw the same UIDL will not need to
download its contents again, because it already has it.

Recording each message's UIDL is still useful even if the mail client always
deletes messages, after downloading them from a POP3 maildrop. If there's
an exception that interrupted the download process, messages that were
downloaded will still remain on the server (pay careful attention to how
DELE and QUIT works); and the next time the client reconnects it will
otherwise end up downloading duplicate copies of some of the messages.

Recording each message UIDLs will prevent that, since the mail client will
easily recognize message that it already has, making the POP3 mail download
process essentially bulletproof.



--=_mimegpg-commodore.email-scan.com-15704-1173575626-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBF81fKx9p3GYHlUOIRAnwqAJwIWumeyGYKcFv8oVsmf0/xHRlHQwCf eRNW
zFgNzRv1LhlM091UjR0dmmI=
=K+Lp
-----END PGP SIGNATURE-----

--=_mimegpg-commodore.email-scan.com-15704-1173575626-0002--

Re: POP use of UIDL command ?

am 12.03.2007 03:59:51 von news

news@absamail.co.za writes:

> > It's not clear to me from my RFCs: 1939, 1725, 2449 how the
> > [list unique IDs of mails still on the server] UIDL is used.

Sam wrote:
> It's for mail clients that cache message's contents. A mail client that
> sees a UIDL for the first time recognizes that it's a new message, and will
> download it. A mail client that already saw the same UIDL will not need to
> download its contents again, because it already has it.
>
> Recording each message's UIDL is still useful even if the mail client always
> deletes messages, after downloading them from a POP3 maildrop. If there's
> an exception that interrupted the download process, messages that were
> downloaded will still remain on the server (pay careful attention to how
> DELE and QUIT works); and the next time the client reconnects it will
> otherwise end up downloading duplicate copies of some of the messages.
>
> Recording each message UIDLs will prevent that, since the mail client will
> easily recognize message that it already has, making the POP3 mail download
> process essentially bulletproof.

OK thanks ! That really makes it clear.

== Chris Glur.