[YahooPOPs-Users] YahooPOPs!/Windows 0.4.6 released

[Anuj S. <anu...@us...>]

YahooPOPs! is an open-source multi-platform web to POP3/SMTP gateway that
allows the use of standard email clients like MS Outlook, Netscape, Opera=
,
Eudora, etc to download emails from Yahoo Mail accounts.=0D
=0D
YahooPOPs!/Windows 0.4.6 has been released. This release is available in =
two
versions:=0D
=0D
1) Full Version: This just be downloaded by first time users of YahooPOPs=
!
or those who are using very old versions it.=0D
2) Upgrade Version: This version should be downloaded by YahooPOPs! v0.4.=
5
users=0D
=0D
Both versions are available for download at http://yahoopops.sf
net/downloads.html=0D
=0D
This version introduces the following changes:=0D
=0D
# Removed check that either of INBOX or Bulk Mail folder must be checked.
User might have some user defined folders to check emails for only=0D
# Improved log dumping for debugging purposes=0D
# Uninstaller now removes the YahooPOPs! shortcut from the startup menu, =
if
it exists.=0D
! 25+ emails can be downloaded without any problems now (timeout issues
still remain though). This fix is for emails that span across multiple pa=
ge
lists in the mail folder=0D
! Invalid log file truncation when "limit log size" was unchecked has bee=
n
fixed=0D
! SMTP Bug fixed: Empty subject lines are now allowed=0D
! When a Yahoo user receives a message encoded with base64, it is
automatically decoded when YP requests its body. This happens with encode=
d
HTML messages as well as a message without any text - just a binary
attachment. The fix searches for =0D
  "content-transfer-encoding: base64" and when found it encodes the messa=
ge
back. The header cannot be simply removed, since this would result in
downloading binary data and passing it to email client=0D
! Modified HTTP handling code to allow working with binary message bodies=
=0D
! Receiving SMTP data from client is changed to cope with "\r\n.\r\n"
falling on buffer boundary. This does not seem to be an issue with a well
written client, but there were voices complaining of YP hanging on DATA
request and I believe this could be the reason. Also, a buggy client can
submit a not encoded binary attachment (happend with OE, when I changed a
bitmap file's extension to nws) which can hang DATA request as well. For
this reason data from client is treated as a binary stream instead of tex=
t
until all zeros are removed and the string will be NULL terminated (a zer=
o
in data could trick YP into losing the rest of buffer). Changing those by=
tes
will not affect the message much, as it is trash anyway=0D
! RCTP address handling is rolled back to my previous implementation with=
out pointers, but with additional fix for RSET handling=20