| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5349
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5348
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5347
|
|
|
|
|
|
| |
Courtesy of Petr Pisar [cs] and Takeshi Hamasaki [ja].
svn path=/branches/BRANCH_6-3/; revision=5346
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5345
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5344
|
|
|
|
|
|
| |
This is useful after installing missing -dev[el] packages.
svn path=/branches/BRANCH_6-3/; revision=5342
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5341
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5340
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5337
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5336
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5335
|
|
|
|
|
|
| |
They should instead compile with resolver or fix it.
svn path=/branches/BRANCH_6-3/; revision=5334
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5333
|
|
|
|
|
|
|
|
| |
Non-delivery messages now mention the original reason for the bounce
message again. It was lost in merging Holger Mauermann's patch before
6.3.0, and caused a sink.c compiler warning ever since.
svn path=/branches/BRANCH_6-3/; revision=5332
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5331
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5330
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5329
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5328
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5327
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5326
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5325
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5324
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5323
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5322
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5321
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5320
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5319
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5318
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5317
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fetchmail no longer drops permanently undelivered messages by default,
to match historic documentation. It does this by adding a new
"softbounce" option, see below.
Fixes Debian Bug#471283, demotes Debian Bug#494418 to wishlist.
There is a new "softbounce" global option that prevents the deletion of
messages that have not been forwarded. It defaults to "true" for
fetchmail 6.3.X in order to match historic documentation. This may
change its default in the next major release.
NOTE: untested.
svn path=/branches/BRANCH_6-3/; revision=5315
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5314
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5313
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5312
|
|
|
|
|
|
| |
Reported by Stepan Golosunov. The original asserts were off-by-one anyways…
svn path=/branches/BRANCH_6-3/; revision=5311
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5310
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5309
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5308
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5307
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5306
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5305
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5304
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5303
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5302
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5301
|
|
|
|
| |
svn path=/branches/BRANCH_6-3/; revision=5300
|
|
|
|
|
|
| |
In fact, these are linux kernel bugs, hopefully fixed in Linux 2.6.30.
svn path=/branches/BRANCH_6-3/; revision=5299
|