Re: send-email: change the default value of sendmail.validate

From: Drew DeVault <sir@cmpwn.com>
Date: Jul 2, 2018, 00:17 UTC
Message-ID: <20180702001753.GA30086@homura.localdomain>
In-Reply-To: <20180701181546.GD7965@genre.crustytoothpaste.net>

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.