Joerg Jung @ 2016-04-04T20:42:03 +0200: > On Mon, Apr 04, 2016 at 11:53:47AM +0200, LÉVAI Dániel wrote: > > Hi! > > > > 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). So the only option I have is to set the global message size in smtpd.conf, and hope for the best? Am I correct in that a client doesn't necesarrily have to specify the message size at the beginning of a transaction? What if smtpd doesn't know the message size beforehand -- then it'll just 4xx messages seemingly random times based on how fast the connection can push lines into it? Doesn't seem this spamassassin filter was thought through properly :-/ (seeing this option present in spamc (--max-size)) 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... Equally hacky as the filter itself... :-P Daniel -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
