Mail Attachment size restriction..

abmonge · Post by **abmonge** » 2008-01-14 10:09

I would like to suggest an add on feature on hmailserver to have a size attachment restriction.

-tony

^DooM^ · Post by **^DooM^** » 2008-01-14 10:24

You can already set max message size.

abmonge · Post by **abmonge** » 2008-01-14 11:41

hmmm where can i see the set max message size and I need to restrict only the attachment size not the email message itself..

^DooM^ · Post by **^DooM^** » 2008-01-14 13:41

It's difficult to just restrict just the attachment as some emails are encoded and the email and attachment are just one big text file. This would require hMail to decode the message, check the file size, Re-encode the message and send it on which would not be practical.

Most emails are tiny and would rarely be over 10k in size, anything larger than that then you can safely assume that there is an attachment of some kind.

http://www.hmailserver.com/documentatio ... rence_smtp

plobby · Post by **plobby** » 2008-03-02 21:00

How does this work with outlook? Lets say I set the max message size for smtp to 10mb and I am using outlook express/outlook, I try to send a 30mb attachment, will it allow it to upload to the server then deny it once it gets to the 10mb mark?

redrummy · Post by **redrummy** » 2008-03-02 22:38

^DooM^ · Post by **^DooM^** » 2008-03-03 00:05

redrummy wrote:Yes.

That's not strictly true. If i remember correctly if the size is sent to hMail and it is over the limit then it will be rejected but not all clients send the size before sending the email in which case hMail will download the whole file and then reject it.

Pretty sure thats how it works

plobby · Post by **plobby** » 2008-03-03 00:40

^DooM^ wrote:
redrummy wrote:Yes.
That's not strictly true. If i remember correctly if the size is sent to hMail and it is over the limit then it will be rejected but not all clients send the size before sending the email in which case hMail will download the whole file and then reject it.

Pretty sure thats how it works

Thats what seems to happen with outlook, it'll send the entire file then reject it, but with my webmail (horde) it'll reject it before uploading it.

redrummy · Post by **redrummy** » 2008-03-03 00:42

Right, that's what I meant. hMS reports SIZE after EHLO, but in response to plobby's question if a client (like Outlook Express, specifically) just starts sending an oversize message anyway then hMS has to accept it up to the limit, at which point it rejects the message.

EDIT: Right, again, what ^DooM^ said below. Maybe I had too much fun last night, a little "slow" today. Think I'll just stop posting for the day. =P

^DooM^ · Post by **^DooM^** » 2008-03-03 03:11

hMail will reject the message after it has the whole file. hMail never kills a connection halfway through a transaction so if your limit is 10meg and the file is 100meg it will accept 100megs then reject it if the SIZE has not been sent beforehand.

Not sure if this behaviour has been altered for V5 or if my mind is remembering it incorrectly.

plobby · Post by **plobby** » 2008-03-03 03:45

I think it would be very useful if this was changed in v5. Could cut down on a lot of wasted bandwidth.

redrummy · Post by **redrummy** » 2008-03-03 08:39

I agree that it seems a waste to accept an oversized message when the server advertizes it's limit, but RFC1870 says that once a server starts receiving a message it must accept the whole thing before issuing a rejection. (Someone correct me if I'm wrong or a newer RFC negates this.) Since Martin seems to be emphasizing RFC compliance I doubt the behavior will change in v5.

The problem is that the server has no way to tell the client in the middle of the transfer that the message has exceeded the limit. The only way to avoid receiving a message over the limit is to drop or reset the connection, but then the client won't know why and will likely try again (who knows how many times). This could easily exceed the bandwidth used by just waiting until the end of the 1st attempt then issuing the proper rejection.

plobby · Post by **plobby** » 2008-03-03 19:13

Hmm shoot, because I just had a client sending a few 100mb emails and the limit is 10mb. I don't know much about how mail clients communicate with the server as to dropping connections and what not, but there isn't a way to drop the connection yet give a reason as to why it did it?

redrummy · Post by **redrummy** » 2008-03-03 19:27

Nope, because once the client gets "354 OK, send." it starts sending the stream and doesn't check for responses until after "." (if memory serves, corrections welcome).

For some people it's hard enough to understand a plain english error like "542 Rejected - Message size exceeds fixed maximum message size. Size: 14811 KB, Max size: 10240 KB". Convincing them of the problem with anything more esoteric like "connection dropped" or "server stopped responding" is nealy impossible. Have you tried applying a ruler to the user's wrist?

plobby · Post by **plobby** » 2008-03-03 19:33

Not all the users are within reach unfortunately

^DooM^ · Post by **^DooM^** » 2008-03-03 22:38

I think ASSP has this functionality.

plobby · Post by **plobby** » 2008-03-04 00:09

^DooM^ wrote:I think ASSP has this functionality.

Ill look now, but do you happen to know where off the top of your head?

^DooM^ · Post by **^DooM^** » 2008-03-04 03:37

No sorry. I may be miss-remembering which is not uncommon for me

plobby · Post by **plobby** » 2008-03-04 03:56

Haha alright, i looked through the settings and didn't see anything related to that. Maybe I just missed it, who knows.

katip · Post by **katip** » 2008-03-04 06:24

ASSP doesn't check message size for allowing/rejecting purposes. There are various size checks but for other things after receiving process ends. This problem has been discussed in Mercury forums some time ago. Conclusion was: Nothing to do unless SIZE is declared by sending server/client. Otherwise you MUST receive entire message first, if you want to stay RFC-conform.

Bill48105 · Post by **Bill48105** » 2010-04-27 01:29

Howdy,
I hate bumping such an old thread but hey it's not in "Archived"

I vote for a setting to *optionally* drop the connection if the limit is reached. (Optional is key for RFC sticklers.. Default could be off but it's there if a mail server admin chooses to stray a bit in the name of sanity) If a response isn't possible then I suppose they could retry over & over. Perhaps the total could be more than if the message was just received in the 1st place but what if the sender NEVER stopped?

Maybe it'd make sense to have tiered limits: level 1 is reject if size is in EHLO (current method) or level 2 drop unconditionally if reached.

Another option could be to log the IP TO & FROM into a database and if another email comes in matching all 3 within a certain time frame to reject that with "5xx max size reached - Recent large attachment over xKB? (x = whatever the hmail size setting is)" then purge the record at that point or after a set time (like an hour) so that odds are the huge email will get bounced on retry with a semi descriptive response. Of course this opens up possibility that other good email could be rejected & not the BIG one but odds are super slim since all 3 values would need to match (essentially the same person emailing the same person from the same IP). Perhaps just from/to need to match in case senders server has multiple outgoing servers and not much more of a chance of a false positive..

Anyhow perhaps after getting an email bounced with that error the sender would get the hint & stop sending such big emails.

Either way hopefully it catches some of the craziness possible if someone sent a 1GB email or a spammer tried to waste your bandwidth by sending continuously forever.

Of course if size would just be included in the SMTP HELO this wouldn't be needed but I file this under 'sanity check necessary evil'.
Bill

rolaids0 · Post by **rolaids0** » 2010-04-27 02:10

This may be good to add, even if its not RFC compliant. I'd do it just by sending the client a message "523 message size exceeded" with the proper code and drop the connection after sending.

katip · Post by **katip** » 2010-04-27 05:38

katip wrote:ASSP doesn't check message size for allowing/rejecting purposes. There are various size checks but for other things after receiving process ends. This problem has been discussed in Mercury forums some time ago. Conclusion was: Nothing to do unless SIZE is declared by sending server/client. Otherwise you MUST receive entire message first, if you want to stay RFC-conform.

As this thread is alive again, some update to above info...
Newer ASSP versions since then support the following options:

Code: Select all

Max Size of Local Message (maxSize)
30000000
If the value of ([message size]) exceeds maxSize in bytes the transmission of the local message will be canceled. No limit is imposed by ASSP if the field is left blank or set to 0. This option allows admins to limit useless bandwidth wasting based on the transmit size.
 
Max Size of External Message (maxSizeExternal)
30000000
If the value of ([message size]) exceeds maxSizeExternal in bytes the transmission of the external message will be canceled. No limit is imposed by ASSP if the field is left blank or set to 0. This option allows admins to limit useless bandwidth wasting based on the transmit size.
 
Max Message Size Error (maxSizeError)
552 message exceeds MAXSIZE byte
SMTP error message to reject maxSize / maxSizeExternal exceeding mails. For example:552 message exceeds MAXSIZE byte (size)! MAXSIZE will be replaced by the value of maxSize / maxSizeExternal.

Bill48105 · Post by **Bill48105** » 2010-04-27 05:48

Thanks katip! I hadn't updated ASSP in awhile because of some custom mod's I made to it but will have to check it out. Good to know there is an option at least & especially good for me since I already use ASSP but my vote is still YES for hmail to have this.
Bill

Mail Attachment size restriction..

Do you need this feature?

Mail Attachment size restriction..

Re: Mail Attachment size restriction..

Re: Mail Attachment size restriction..

Re:

Re: Mail Attachment size restriction..