You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2008/08/01 22:46:05 UTC

[Bug 5402] SpamCop plugin occasionally timeouts reporting spam

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5402


Steven Chamberlain <st...@pyro.eu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven@pyro.eu.org




--- Comment #1 from Steven Chamberlain <st...@pyro.eu.org>  2008-08-01 13:46:04 PST ---
Hi,

(btw: I feel this issue may be a 'bug', rather than a request for enhancement
as it's currently flagged)

I shall provide a little more detail.  If reporting to SpamCop with
'spamassassin --report' times out, the following warnings are shown:

[11530] warn: reporter: SpamCop report to vmx1.spamcop.net failed: Net::SMTP
error
[11530] warn: reporter: SpamCop report to vmx2.spamcop.net failed: Net::SMTP
error
[11530] info: reporter: could not report spam to SpamCop
[11530] warn: reporter: no reporting methods available, so couldn't report
[11530] warn: spamassassin: warning, unable to report message
[11530] warn: spamassassin: for more information, re-run with -D option to see
debug output

I suffer this problem regularly, and have only just realised what was causing
it.  The above errors can also be found in mailing list archives, and it seems
that people have been affected by this but never discovered the cause:
in 2002,
http://mail-archives.apache.org/mod_mbox/spamassassin-users/200503.mbox/%3C9a80add1542b60f0866bb414ef36439f@comcast.net%3E
in 2007,
http://groups.google.com/group/spamcop.help/browse_thread/thread/f7e2eed18e753ce5

Exactly what happens is, after the server's 220 greeting, the reporter sends
the EHLO and waits for a 250 response before proceeding.  If this doesn't
happen within 10 seconds, the reporter times out, closing the connection and
showing the vague 'Net::SMTP error'.  Both of the two available MXes are tried,
and if both attempts time out, the reporter aborts the SpamCop submission and
displays the warnings above (but still returns a zero 'success' error code).

The 10-second timeout strikes me as unusually low.  RFC 2821 section 4.5.3.2,
'Timeouts', suggests minimum timeouts of 5 minutes for the MAIL and RCPT
commands.  Whilst it does not suggest a timeout for the EHLO command, the same
period of time seems appropriate for EHLO as for MAIL and RCPT.

Note that the RFC specifies shorter timeouts (2 and 3 minutes) or longer
timeouts (10 minutes) for other SMTP commands, and I don't believe Net::SMTP
offers that flexibility.

Therefore I believe this justifies raising the default from 10 seconds to at
least 5 minutes, and preferably 10 minutes (until such a time as Net::SMTP
allows timeouts to be specified differently for each SMTP command).  However,
I'm aware that in some situations people may consider these periods excessive,
alas, the RFC also states:
  Timeouts [in SMTP clients] SHOULD be easily reconfigurable, preferably
without recompiling the SMTP code.

Whilst Net::SMTP is effectively the 'SMTP client' in this situation, and its
timeout is easily configurable, I think the reporter is wrong to specify a
hard-coded timeout.

In summary, I propose three changes:

1. make sure that an SMTP timeout results in a more verbose warning, at least
when using the '-D' option
2. add a configuration option for the SMTP command timeout
3. raise the default SMTP command timeout from 10 seconds to 10 minutes

I don't feel competent enough to create a patch implementing changes 1 and 2,
but 3 is so trivial that applying a patch would be actually require more effort
than editing the plugin file directly.  In the SpamAssassin v3.2.5 distribution
the timeout is specified in file lib/Mail/SpamAssassin/Plugin/SpamCop.pm at
line 271.

Thanks!!


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.