TeraByte Unlimited

I've noticed on a system with a lot of profiles, which potentially means a lengthier log than normal (even at default log level), that IFW's /email function (at least through 3.47) truncates the email at about 15,000 characters (150 lines in this case). Is this intentional? If so, any harm in increasing the limit in a future version?

Thanks

There is no limit to the size of the session log except memory. That will be sent via email then saved in the file up to the max log size set (default is 1MiB).

I just did a test creating an additional 100,000 lines bring the email size to 16MiB and it was sent and received perfect.

There's never a problem with what appears in the log, just the email. And there's no way it can be memory (as in overall RAM, if that's what you mean) in this case.

The email size is 97KB, not unusual in and of itself.

So, I guess this might be down to the SMTP provider (Google, in this case), or the destination (Outlook.com)? I've never heard of such a limitation, but then I never think of email limits in terms of body text, just attachments, and there is no attachment in this case.

Update: It's not where it's sent to, so that leaves Gmail's SMTP or some other variable I'm not accounting for given that you said that you're not seeing the limitation.

Update 2: And testing Google's SMTP with Outlook also shows no body-length limit for things around this size.

How exactly did you run your test? I will also try that way. However you did it might contain the explanation. For example, what if the limit only happens in conjunction with an actual backup?

it's it's in the .log it's sent, the data isn't added to the .log until after email sent (it's the same data), the data in the .log could be truncated if it exceeds the max log file size however.

I've checked that before: the log is complete, right down to the "Email sent to..." line at the end. It's something else.

maybe look at the raw email code. Everything in the .log for that session would have been sent. Sometimes email clients can chop off stuff decoding it.

I think that's on the right track and made me realize that in my earlier test I forgot to send as Plain Text instead of HTML for an apples-to-apples comparison. So, I did that: taking the complete portion of the log that would have been sent and made sure it went out, via the same SMTP as IFW uses and to the same destination, as Plain Text. It still came through perfectly, however, just as the earlier HTML test had.

In looking at the headers for both IFW's and the Plain Text test though, I noticed a difference in the Content Type line, and I wonder if that might be involved.

IFW: multipart/mixed; boundary="__=_Part_Boundary_001_025652.009012"
Test from Outlook: text/plain; charset="us-ascii"

And missing entirely from the IFW one is "Content-Transfer-Encoding," which reads as "7bit" in the Outlook test's' header.

BTW, where it stops in the email is nothing notable. It's just yet another path line, like the many before it:
[01/02/2022 03:45:08 AM] \Users\bookkeeper\AppData\Loca