> On 04 Apr 2016, at 23:27, LÉVAI Dániel <[email protected]> wrote: > >>> filter-spamassassin doesn't have a parameter to specify a maximum >>> message size like spamc(1), and when it encounters a message weighing in at >>> a >>> few MBs, it fails, and drops back the message with a 4xx. >>> >>> Is this like a caveat, a known limitation or something? >> >> Not really, the filter just pipes everything through towards spamd(1). >> The message size can be adjusted in smtpd.conf. >> >>> smtpd: >>> Apr 4 10:40:48 malcolm smtpd[12759]: smtp-in: New session f49a69df17bc3046 >>> from host hostname [ip_address] >>> Apr 4 10:40:49 malcolm smtpd[12759]: smtp-in: Started TLS on session >>> f49a69df17bc3046: version=TLSv1.2, cipher=ECDHE-RSA-CHACHA20-POLY1305, >>> bits=256 >>> Apr 04 10:40:49 malcolm spamd[540]: spamd: connection from localhost >>> [127.0.0.1]:46081 to port 783, fd 6 >>> Apr 04 10:40:59 malcolm spamd[540]: spamd: timeout: (10 second timeout >>> while trying to PROCESS) >> >> Your message does not really fail because of size, spamd run into >> timeout while processing. This can have various reasons depending on >> your spamassassin config, e.g. additional dnsbl/pyzor/razor/whatever >> checks might take a while. >> >> But yes, this might also be related to size, longer mails take longer to >> transfer and to check and will run more likely into a timeout. >> >> You seemed to have tweaked the timeouts: the default is 300s and makes >> sense -- not the 10s mentioned in your log above. >> So You get what you requested ;) > > Indeed, this was because of the --timeout-child option to spamd(1). > However, raising this limit just because it might cover every message > size doesn't really make sense. Even with 600 secs, there will be a > message large enough for smtpd to spit back (given, depending on eg. the > connection speed -- I could easily scan a ~10MB mail submitting from > localhost, but not from a remote site eg. gmail).
A 10 MB mail should be no problem within the default 300s. Even with a slow link. I have remote sites sending me 20-30MB mails taking about 1-3s to scan. As I wrote earlier, you may want to double-check your spamassassin config to figure out why it takes so long to check. > So the only option I have is to set the global message size in > smtpd.conf, and hope for the best? What’s wrong with the message size setting in smtpd.conf? > Am I correct in that a client doesn't > necesarrily have to specify the message size at the beginning of a > transaction? Yes. But it depends, ESMTP supports the SIZE command. There are also reasonable timeout values specified in RFC for SMTP transactions. > What if smtpd doesn't know the message size beforehand — No “what if” here. It may not know. > then it'll just 4xx messages seemingly random times based on how fast > the connection can push lines into it? Yes, which is fine. 4xx means: try again later (maybe your line is fast enough then). > Doesn't seem this spamassassin filter was thought through properly :-/ > (seeing this option present in spamc (--max-size)) As the author of the filter, I feel a bit offended by this statement now. The filter works fine for me in larger production environments. It does more or less exactly the same as the similar sendmail milters, which also work fine for many people in production since years. I’m trying to help you with some vague issue here in this thread: For some reason you want a max-size option for the filter, but fail to explain why. > Anyway, I just injected a hacky patch in spamassassin_on_dataline() with > a basic test of a `static size_t' that records the lines' length… So now you drop the message earlier, once the size limit is reached instead of running into the timeout later. I fail to see how this helps you? You get less mail and even more 4xx replies this way. > Equally hacky as the filter itself... :-P No need to become annoying. I have not seen any code or diff from you yet. -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
