https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6421
--- Comment #10 from Bjørn Mork <[email protected]> 2011-10-29 14:29:22 UTC --- Created attachment 5000 --> https://issues.apache.org/SpamAssassin/attachment.cgi?id=5000 Logs showing the bug triggered with --ssl and not triggered without it I should have done this before, but better late than never... And I obviously forgot to mention an important part of my setup: I am using spamass-milter. The MTA is sendmail. It seems that spamass-milter is the missing part of the puzzle. I am not able to recreate the problem by merely calling spamc directly, even if I give it input which has previously failed (when spamc was called via spamass-milter). But resending the same mail via sendmail, having it call spamc through spamass-milter, will reliably trigger the problem. In fact, I can reliably trigger it using *any* sufficienly large enough mail as long as it goes through spamass-milter. But --ssl also affects this. The problem does not show up unless I use --ssl between spamass-milter and spamd. I am attaching a completely dummy "test.mail" which does trigger the problem for me, as long as it is passed via ssl to spamd by spamass-milter. The mail contains nothing but a large enough file full of null bytes. My tests indicates that the actual contents doesn't matter, just the size. I am also attaching "spamd-spamc-sendmail-log.txt" with logs showing "test.mail" received twice: first using --ssl and failing, and then without --ssl and working. Note that I sent it to an external address which is forwarded back to me, as my setup won't normally scan anything received from a host on the local network. This was just done so because it was simpler than modifying the setup to make spamass-milter scan local mail. Bjørn -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
