Mailing List Archive

[Bug 956] spamd fallback only for connect(). Lack of fallback for other types of errors.
https://bugs.exim.org/show_bug.cgi?id=956

--- Comment #4 from Gedalya <gedalya@gedalya.net> ---
Hello,

Apart from the points mentioned above, would someone be kind enough to
otherwise review my (draft) patch for correctness?

I find myself worrying about connectivity issues and perhaps a bug in exim's
code, and not so much about exim knocking out an r?spamd server (or two). Could
a configuration option be perhaps added to control the failover behavior?

Gedalya

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 956] spamd fallback only for connect(). Lack of fallback for other types of errors. [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=956

Gedalya <gedalya@gedalya.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |gedalya@gedalya.net

--- Comment #3 from Gedalya <gedalya@gedalya.net> ---
Created attachment 1374
--> https://bugs.exim.org/attachment.cgi?id=1374&action=edit
spamd: fallback on all errors

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 956] spamd fallback only for connect(). Lack of fallback for other types of errors. [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=956

Gedalya <gedalya@gedalya.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #1374|0 |1
is obsolete| |

--- Comment #5 from Gedalya <gedalya@gedalya.net> ---
Created attachment 1375
--> https://bugs.exim.org/attachment.cgi?id=1375&action=edit
V2 - spamd: fallback on all errors

Changes:
1. Reset start time when trying a new spam server.
2. With rspamd, we expand $sender_host_name and this is done after we've
already connected to the server. When this takes a very long time, it
potentially takes up a significant portion of the server's configured timeout.
Since this delay is imposed entirely by our end, it would make sense to expand
this before recording the start time and connecting. Also, don't do this more
than once.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 956] spamd fallback only for connect(). Lack of fallback for other types of errors. [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=956

Gedalya <gedalya@gedalya.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #1375|0 |1
is obsolete| |

--- Comment #6 from Gedalya <gedalya@gedalya.net> ---
Created attachment 1377
--> https://bugs.exim.org/attachment.cgi?id=1377&action=edit
V3 spamd: add retry_failed option to try spamd server after failure

Changes:

Add a retry_failed option to spamd server specification

Doc:

The `retry_failed` option specifies that this server should be tried
after exim has successfully established a connection to another server,
but that server failed to properly respond.
This is disabled by default, due to the concern that a bad message could
cause a server to crash, and trying other servers could crash them as well.
Possible values are "true", "1", "false" or "0".

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##