forked from pool/fetchmail
790324228f
- Update to 6.4.1 [bsc#1152964] ## REGRESSION FIXES: * The bug fix Debian Bug#941129 was incomplete and caused - a regression in the default file locations, so that fetchmail was no longer able to find its configuration files in some situations. - a regression under _FORTIFY_SOURCE where PATH_MAX > minimal _POSIX_PATH_MAX. - Update to 6.4.0 ## SECURITY FIXES THAT AFFECT BEHAVIOUR AND MAY REQUIRE RECONFIGURATION * Fetchmail no longer supports SSLv2. * Fetchmail no longer attempts to negotiate SSLv3 by default, even with --sslproto ssl23. Fetchmail can now use SSLv3, or TLSv1.1 or a newer TLS version, with STLS/STARTTLS (it would previously force TLSv1.0 with STARTTLS). If the OpenSSL version used at build and run-time supports these versions, --sslproto ssl3 and --sslproto ssl3+ can be used to re-enable SSLv3. Doing so is discouraged because the SSLv3 protocol is broken. While this change is supposed to be compatible with common configurations, users may have to and are advised to change all explicit --sslproto ssl2 (change to newer protocols required), --sslproto ssl3, --sslproto tls1 to --sslproto auto, so that they can benefit from TLSv1.1 and TLSv1.2 where supported by the server. The --sslproto option now understands the values auto, ssl3+, tls1+, tls1.1, tls1.1+, tls1.2, tls1.2+, tls1.3, tls1.3+ (case insensitively), see CHANGES below for details. * Fetchmail defaults to --sslcertck behaviour. A new option --nosslcertck to override this has been added, but may be removed in future fetchmail versions in favour of another configuration option that makes the insecurity in using this option clearer. ## SECURITY FIXES * Fetchmail prevents buffer overruns in GSSAPI authentication with user names beyond c. 6000 characters in length. Reported by Greg Hudson. OBS-URL: https://build.opensuse.org/request/show/737166 OBS-URL: https://build.opensuse.org/package/show/server:mail/fetchmail?expand=0&rev=88
42 lines
1.6 KiB
Diff
42 lines
1.6 KiB
Diff
# Patches fetchmail's behaviour for SMTP servers which:
|
|
# 1) insist on using TLS - we do not want messages which cannot
|
|
# be sent due to server negotiation problems lost - rather we
|
|
# keep them on the mailserver. As users should realize rather
|
|
# quickly that something went wrong, the overhead shouldn't
|
|
# be considered that important.
|
|
# 2) use the 501 error code to mark spam - in such a case
|
|
# the 'antispam' option should be used
|
|
Index: fetchmail-6.4.1/sink.c
|
|
===================================================================
|
|
--- fetchmail-6.4.1.orig/sink.c
|
|
+++ fetchmail-6.4.1/sink.c
|
|
@@ -536,6 +536,19 @@ static int handle_smtp_report(struct que
|
|
free(responses[0]);
|
|
return(PS_TRANSIENT);
|
|
|
|
+ case 501: /* Syntax error in parameters or arguments */
|
|
+ /*
|
|
+ * Some SMTP servers use this error code to refuse spam, however
|
|
+ * as we don't want to delete message if e.g. the address is (possibly
|
|
+ * by mistake) malformed, user has to use the 'antispam' option to
|
|
+ * treat this as spam symptom
|
|
+ */
|
|
+ free(responses[0]);
|
|
+ if (outlevel > O_SILENT)
|
|
+ report_complete(stdout,
|
|
+ GT_(" SMTP 501 error - if the server uses this code to report spam, include '501' in the 'antispam' option .\n"));
|
|
+ return(PS_TRANSIENT);
|
|
+
|
|
default:
|
|
/* bounce non-transient errors back to the sender */
|
|
if (smtperr >= 500 && smtperr <= 599)
|
|
@@ -601,7 +614,7 @@ static int handle_smtp_report_without_bo
|
|
case 553: /* invalid sending domain */
|
|
return(PS_REFUSED);
|
|
|
|
- default:
|
|
+ default:
|
|
/* bounce non-transient errors back to the sender */
|
|
if (smtperr >= 500 && smtperr <= 599)
|
|
return(PS_SUCCESS);
|