On 2018-07-01 6:15 PM, brian m. carlson wrote: > Can you say a bit more about the exact error message you're seeing? "patch contains a line longer than 998 characters" A recent occasion when this came up was when someone attempted to send me a patch which included a base64-encoded data URI, which cannot be wrapped. > Are you suggesting that we not limit lines to 998 octets? I've seen > lots of mail servers that do reject mail over 998 octets. I've > configured Postfix to do so because being strict on mail standards is a > great way to stop spam. Yes, that's what I'm suggesting. We should error out later when the SMTP server rejects the mail. Also, Extended SMTP is a standard. RFC 1869. > If that's the issue you're seeing, it might be better to either > automatically encode those patches as binary patches or teach git > send-email and git am how to automatically handle quoted-printable. I'm really not fond of quoted-printable. Extended SMTP has been standardized for over 20 years. Assuming people don't blithly disable it on their servers, we can expect it to be present on almost all mail servers. I don't think I've ever seen a spam email that would have been stopped because it contained 998 lines. Approaches like SpamAssassin, greylisting, DNSBLs, SPF/DKIM, these are much more effective.
