| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
This should clarify an issue that Uli Zappe reported to the
fetchmail-users@ mailing list in February 2010.
|
| |
|
| |
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5480
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5472
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5469
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The IMAP client now uses "SEARCH UNSEEN" rather than "SEARCH UNSEEN NOT
DELETED" again on IMAP2, to fix a regression in fetchmail 6.2.5 reported by
Will Stringer in June 2004. (Sunil Shetye)
* The IMAP client now uses "SEARCH UNSEEN UNDELETED" on IMAP4 and IMAP4r1
servers (Sunil Shetye).
* Workaround: The IMAP client now falls back to "FETCH n:m FLAGS" if the server
does not support "SEARCH". (Sunil Shetye)
* The IMAP client now requests message numbers in batches of 1,000 to avoid
problems if there are more than 1860 unseen messages. (Sunil Shetye)
Note that this wasn't security relevant because fetchmail would only read up
to the maximum buffer size and leave the remainder of the string unread, going
out of synch afterwards.
svn path=/branches/BRANCH_6-3/; revision=5468
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5467
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apply patch from Sunil Shetye to fix a problem reported by James Moe.
Before this fix, fetchmail's SMTP client would not recover from errors
such as lost connections that were encountered when fetchmail had sent
RSET, for instance, after an anti-spam filter dropped the connection
after detecting spam. Fetchmail then tried to send subsequent mail
through this broken connection and deferred retrieval until the next
poll. Now, if RSET fails, fetchmail closes the connection and reopens
it for the next message to be delivered.
svn path=/branches/BRANCH_6-3/; revision=5463
|
|
|
|
|
|
| |
...and only include gssapi.h if we're not including gssapi/gssapi.h.
svn path=/branches/BRANCH_6-3/; revision=5461
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5460
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The IMAP client no longer skips messages from several IMAP servers including
Dovecot if fetchmail's "idle" is in use. Causes were that fetchmail (a)
ignored some untagged responses when it should not (b) relied on EXISTS
messages in response to EXPUNGE, which aren't mandated by RFC-3501 (the IMAP
standard) and aren't sent by Dovecot either.
Fix by Sunil Shetye (the fix also consolidates IMAP response handling,
improving overall robustness of the IMAP client), bug report and testing by
Matt Doran, with further hints from Timo Sirainen.
svn path=/branches/BRANCH_6-3/; revision=5459
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5457
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5449
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5445
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5444
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5439
|
|
|
|
|
|
|
|
| |
Smtpaddress is for RCPT TO, not MAIL FROM. Found by Gerard Seibert.
'Append to MAIL FROM line:' => 'Use domain on RCPT TO line:'
'Set RCPT To address:' => 'Set fixed RCPT TO address:'
svn path=/branches/BRANCH_6-3/; revision=5433
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5432
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5430
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5428
|
|
|
|
|
|
| |
but there are more functions that need fixing (look for smtp_response).
svn path=/branches/BRANCH_6-3/; revision=5425
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5423
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5422
|
|
|
|
|
|
|
| |
Problem was improper scoping of xfree(tt). Patch courtesy of Thomas Heinz.
Fixes Gentoo bug #280760.
svn path=/branches/BRANCH_6-3/; revision=5415
|
|
|
|
|
|
| |
Courtesy of Ernest Adrogué Calveras, Francisco Molinero, Jakub Bogusz.
svn path=/branches/BRANCH_6-3/; revision=5408
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5407
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5406
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5394
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5393
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5389
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5388
|
|
|
|
|
|
|
| |
RFC-5322 allows for messages without the CRLF+body part, so fetchmail should
not complain about legal messages.
svn path=/branches/BRANCH_6-3/; revision=5387
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5385
|
|
|
|
|
|
|
| |
Through the documentation project.
Courtesy of Ji Zheng-Yu and Francisco Molinero.
svn path=/branches/BRANCH_6-3/; revision=5375
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5369
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5365
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5363
|
|
|
|
|
|
| |
Fixes Debian Bug#530749, filed by Reuben Thomas.
svn path=/branches/BRANCH_6-3/; revision=5361
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5357
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5354
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5353
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5350
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5349
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5348
|
|
|
|
|
|
| |
Courtesy of Petr Pisar [cs] and Takeshi Hamasaki [ja].
svn path=/branches/BRANCH_6-3/; revision=5346
|
|
|
|
|
|
|
| |
These are usually configuration errors (missing TLS/SSL). Patch
partially taken from Petr Cerny, Novell's Bugzilla 246829.
svn path=/branches/BRANCH_6-3/; revision=5339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Short timeouts could cause fetchmail to not wait long enough for the
"250 Ok" after shipping a long message, particularly with synchronous
mailers and extensive spam filtering. This caused fetchmail to re-fetch
long messages.
While the actual fix is making sure that the timeout is no shorter than
the time the SMTP server takes to process the message, we now enforce
the minimum RFC-5321 recommended timeouts even if the user configures a
lower timeout.
This is to fix Berlios Bug #10972, reported by Viktor Binzberger.
NOTE: it is untested whether we will properly delete the message from
the POP3/IMAP server or mark it as seen, as the upstream server may
close the connection sooner.
svn path=/branches/BRANCH_6-3/; revision=5338
|