Joerg Jung @ 2016-04-05T12:58:23 +0200: [...] > > 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.
I don't think I should have to bend over spamassassin to an smtpd filter that fails to implement a basic check for the message size. With eg. filter-clamav, it is a bit easier, because you define the size limit for clamd. But with the the spamd/spamc duo, you'd do that with spamc (and in this case, filter-spamassassin is the 'client'). > > > 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? It's not the solution to the problem. I *want to* receive "large" messages. I just don't want them to be *scanned* by spamassassin. See the difference? > > 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. Okay, understood, so the (my) use-case still stands. > > 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). But it really is not (in my case) :) See, my connection to a remote site doesn't get upgraded after a 4xx respone... But I see your point. If *my* link was saturated, there'll be more chance for delivery next time. > > 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. Okay, okay. Sorry about that. Naturally I saw your name in the source; didn't want to offend you of course (but I tend to have a big mouth). This is simply my use-case. I can understand why no one else sees this as a problem; I'm not saying that the filter is useless. > > 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. Nope. Why would I drop the message? Of course that wouldn't make sense. I just push the first n bytes to spamd(1), then when it reaches the configured limit, it just bypasses spamd(1) for the rest of the lines. So basically, I get only the first n bytes scanned by spamd(1) and not the rest. See, this is arguably not a good solution for a lot of people, but for my use-case, this is perfect. I'm willing to sacrifice getting large spam mails because of this. I won't try to bore you with statistics from google about how big a spam message is, in average, but they rarely hit 1+ megabytes. > > Equally hacky as the filter itself... :-P > > No need to become annoying. I have not seen any code or diff from you yet. All right... I see we got off on the wrong foot here, and it is my fault. So, I'm saying sorry, and how about just start off with a clean slate. I won't send my diff to the list, because as I've said, it's a hackity-hack, and don't want someone to find it in the archives, and god forbid use it. If you're interested, or want to get an idea of what I was explaining, I'll gladly send it to you in private. Daniel -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
