diff options
| author | Matthias Andree <matthias.andree@gmx.de> | 2009-05-25 12:35:54 +0000 |
|---|---|---|
| committer | Matthias Andree <matthias.andree@gmx.de> | 2009-05-25 12:35:54 +0000 |
| commit | bd2e568da48acbae7e0b43c48226541220b85340 (patch) | |
| tree | f60ee29a3e1d8897c3e2713af7442938ad89c8ec /NEWS | |
| parent | b2f54f5fbf4c98a3e37003d5642eab20c3971432 (diff) | |
| download | fetchmail-bd2e568da48acbae7e0b43c48226541220b85340.tar.gz fetchmail-bd2e568da48acbae7e0b43c48226541220b85340.tar.bz2 fetchmail-bd2e568da48acbae7e0b43c48226541220b85340.zip | |
Enforce minimum recommended SMTP timeouts, apply to EHLO/LHLO as well.
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
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 12 |
1 files changed, 12 insertions, 0 deletions
@@ -81,6 +81,18 @@ fetchmail 6.3.10 (not yet released): * Non-delivery notice ("bounce mail") now mentions the original reason again, before the address list. This fixes a regression introduced in 6.3.0. * Several compiler warnings were fixed. +* The minimum recommended SMTP (RFC-5321) timeouts are enforced to leave + sufficient time for the listener to respond. Some synchronous listeners, + particularly when used with spam filtering and other policy enforcement + services, take extended amounts of time to process messages after the sender, + recipient, or data block and EOM line. This can cause fetchmail to not wait + long enough for the "250 Ok" and make fetchmail believe the message wasn't + properly delivered when in fact it was; fetchmail would then retry the + download next time and never make progress. + Fixes Berlios Bug #10972, reported by Viktor Binzberger. +* The ESMTP/LMTP client will now apply an application-specific timeout while + waiting for the EHLO/LHLO response, rather than wait for the server or TCP + connection timeout. # CHANGES * Make the comparison of the SSL fingerprints case insensitive, to |