Max Message Size
Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=5371
Printed Date: 31 July 2025 at 11:33am
Topic: Max Message Size
Posted By: Desperado
Subject: Max Message Size
Date Posted: 03 November 2005 at 8:19am
|
Roberto, Can a message size be detected *before* it is processed? We ge into high, nonstop bandwidth issues when an inbound message is huge and the sender keeps retrying forever. Here is a graph of one that is going on now (if the graph posts correctly)
Regards, ------------- The Desperado Dan Seligmann. Work: http://www.mags.net Personal: http://www.desperado.com |
Replies:
Posted By: LogSat
Date Posted: 03 November 2005 at 4:27pm
|
Dan, What build are you using? Before build 2.6.3.485, SpamFilter was disconnecting the sender as soon as the max size limit was reached, thus saving possibly a lot of bandwidth as the remainder of the email was not sent. However we recently discovered that in some cases the remote SMTP server would not see the numeric error code that SpamFilter sends just before disconnecting, and this was causing the remote server to continue trying on regular intervals. Due to this, starting from build 485, we have been forced to completely receive the message (as the remote server may not listen until it's done sending...), and only then issue an error code and disconnect them. This solved the problem of the continuous retries, but does force the email to be fully received (SpamFilter will save CPU by not processing the message after it reached the max size, as it will already know it's going to be discarded). ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |
Posted By: Roman
Date Posted: 04 November 2005 at 2:30pm
|
Hello, Roberto
Is it possible to show Maximum Message Size (in reply to EHLO, as per RFC1870) so the remote server should not start sending oversized messages at all? |
Posted By: LogSat
Date Posted: 04 November 2005 at 4:47pm
|
Excellent suggestion. We've placed it on top of our priority list, both
due to its importance and ease of implementation. Please look for it in
the next pre-release build, within a few days.
------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |
Posted By: LogSat
Date Posted: 06 November 2005 at 11:09pm
|
Roman, We've just pre-released build 2.6.3.981 in the registered user area. The release notes for it are below. As a side note, it was interesting to notice how several SMTP servers, including Yahoo's, do support the SIZE command in RFC1870 when *receiving* email. They however do not make use of it when *sending* emails to others... In simple terms, Yahoo specifies a max SIZE in their EHLO text. However, when they send an email to SpamFilter, even though SpamFilter supports the new EHLO parameter, Yahoo completely ignores it and still sends the message over the max size specified... We're looking to see if there's anything we're missing here, but so far it looks as SMTP servers are simply ignoring the SIZE parameter. // New to VersionNumber = '2.6.3.491'; {TODO -cNew : Added support for maximum message size in reply to EHLO and MAIL FROM, as per RFC1870} ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |
Posted By: Roman
Date Posted: 12 November 2005 at 10:31am
|
Hello, Roberto
Version 491 still accepts oversized messages (in cases when remote server could ingnore "SIZE" parameter in EHLO response):
while it should act like this:
BTW, as I can see, yahoo servers use "SIZE" feature on recieve, but they use only old simple HELO command while sending messages (at least from webinterface) |
Posted By: LogSat
Date Posted: 12 November 2005 at 1:19pm
|
Roman, The entry you posted is *very* strange. I found in our SpamFilter's log your test, but its timestamp is *after* your posting (meaning that the forum posting with the SMTP conversation occurred before our SpamFilter receved the connection). According to our logs, you were indeed immediately disconnected because the message would have exceeded the max msg size. In the log below, the time shown is GMT -5: 11/12/05 12:51:39:735 -- (592) Connection from: aaa.bbb.191.122 - Originating country : United States 11/12/05 12:51:59:193 -- (592) EMail from roman@__.ru will exceed the max msg size - rejected. 11/12/05 12:51:59:233 -- (592) Disconnect I also tested our own install using your same SMTp commands, and was correctly disconnected: 220 mail2.netwide.net Welcome to SpamFilterISP SMTP Server v2.6.3.491 EHLO __serv.l____a.com 250-8BITMIME 250-SIZE 5120000 250 HELP MAIL FROM:<roman@__.ru> SIZE=70000000 552 This email is rejected. It exceeds the maximum allowed message size. Connection to host lost. If you used a different address in your original post, then that would explain why I did not find you in the logs. If you can let us know what that was, I can try to see if we have some kind of whitelisting in our config that allowed you to send the email. ------------- Roberto Franceschetti http://www.logsat.com" rel="nofollow - LogSat Software http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP |
Posted By: Roman
Date Posted: 12 November 2005 at 2:05pm
|
Hmm, i've just tested again and was unable to reproduce my first test. Everything works as it should. It's very strange for me too. I definitly got "250 Address okay" at the first time, and it took for while to put my telnet output to clipboard, and then disconnected. I don't know what has happened, may be my misprint or something. Sorry for false alert.
PS: I'm GMT+3 and I use SNTP. I've updated this post at 22:51 (Moscow), 19:51 (UK), 14:51(NY), I'll see time stamp at forum 5:51pm. and all dates looks reasonable to me: test at 12:59, post at 13:31 |