> >> I was thinking about not advertising SIZE myself, because our limits are
> >> already very high so people can send large attachments internally.
>
> I would still suggest setting a sensible limit, like 100 MB or similar, to
> avoid the problem that certain MUAs tend to timeout, crash or stall while
> sending the email. The email is soo large so the MUAs own timeout for sending
> email trips and then it cancels the request.
>
> I have seen my share of MUAs that behave in weird ways when encountering
> things larger than it can handle, so you have to always cope for them in the
> mail server. Implementing different types of restrictions, and filtering
> things out of subjects and certain headers to evade crashing MUAs.
998 characters (not including CRLF), as I recall, is the maximum
limit, which is specified in RFC 5322 (section 2.1.1):
RFC 5322 :: Internet Message Format
https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1
So, I make sure my software works within these limits, and although
I do try to keep automated message subject lines short-and-pithy, I'm
actually don't care if someone else's MUA crashes because it can't
handle 998 characters -- that's a serious problem with the MUA
software that needs to be resolved.
> As I said before, stumbled upon a MUA which tend to crash when subjects
> become too long. The thing is that the MUA stores emails on the harddrive, so
> when subject is very long, pathlen (C:\Users\....\.....\mail\[subject].eml)
> exceeds 255 characters (MAX_PATH), and when pathlen exceeds 255 then MUA
> fails to write the email file, and subsequently silently crash.
That's an incredibly stupid design decision. Seriously...
Storing eMail messages in files named by the subject line carries
many risks with it, including the need to program for the following:
1. duplicate filenames (when a subject name is used more than
once)
2. use of absolute path characters (e.g., "/boot/grub/grub.cfg")
3. use of pipe characters (e.g., "| deltree /y C:\Windows")
4. use of redirection characters (e.g., "> /etc/passwd")
5. use of invalid characters that result in a file creation
error
There are other problems too, which I choose to leave this to the
reader's imagination.
Anyway, such sofwtare either needs to be fixed, or replaced. And
when message are stored on the local file system by an MUA, the usual
practice is for some code to generate a filename that is based on
something rational, such as some sort of a unqiue sequence number.
> Resulting in user getting locked out from his mail account (as the MUA would
> silently crash immediately upon downloading the culprit email from server)
> until I delete the email with the excessive subject on server.
That's stupid software. Get it fixed, or replace it with something
else that's been written by people who understand why such a stupid
design choice also creates potential security problems (in addition
to the stability problems that you noted).
> So email operators, don't be afraid of putting limits, replaces and such, it
> just help people with troubles when things become too large.
Nope. It's not a matter of "being afraid" -- it's a matter of me
choosing not to hobble my system to accomodate someone else who's
trying to use broken software.
If someone is running software that requires everyone else reduce
the limits below what is clearly documented in the relevant RFCs (see
my RFC link, above), then I'm very likely not going to do it (unless
they pay enough money to make it worthy of my time and effort, or
they are a major provider being unreasonable that my users want to
communicate with, etc.) since what they're asking for is ... stupid.
Subject lines longer than 255 characters crashes your MUA? Yeah,
that's not my problem as long as the subject lines I'm sending to you
are within the 998 character maximum. Fix or replace your MUA, or
let it keep crashing -- the choice is yours, and it's not my problem.
> Email isn't directly made to send really huge things.
Correct. Originally, eMail didn't even have any provisions for
including file attachments. This was added later, albeit in a way
that enlarged binary data using base-64 encoding (to cleverly
accomodare the use of 7-bit ASCII communications in a reliable way),
and although it works well now (thanks again to RFCs making it clear
for software vendors to implement support for it), it would have been
nice if more efficient options were available, such as 8-bit raw data
inclusion, in the original specifications (just for starters).
Internet communications have improved tremendously over the past few
deaces, and the availability of high-speed internet has also become
widespread, so overall this isn't really a major issue anymore.
> Best regards, Sebastian Nielsen
>
> _______________________________________________
> mailop mailing list
> [email protected]
> https://list.mailop.org/listinfo/mailop
--
Postmaster - [email protected]
Randolf Richardson, CNA - [email protected]
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
