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

The purpose of this configuration option is to prevent your emails from blowing up on SMTP servers (rather than Extended SMTP servers). However, I find it often confuses people whose patches are otherwise correct, and they don't know how to solve the issue.

I haven't seen an SMTP server in a very long time which doesn't support extended SMTP. The default behavior should probably change. If not, the error message should be more clear about action items to address the issue.

I'll send a patch around to change this shortly.

-- Drew DeVault

On Fri, Jun 29, 2018 at 03:07:51PM -0400, Drew DeVault wrote:

Can you say a bit more about the exact error message you're seeing?

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.

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.

On 2018-07-01  6:15 PM, brian m. carlson wrote:

"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.

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.

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.

On Sun, Jul 01, 2018 at 08:17:53PM -0400, Drew DeVault wrote:

I don't think it's a good idea to continue when we know we're going to send invalid data. If you really want to send the email and you know it's safe in your environment, use --no-validate.

ESMTP doesn't lift the 998-octet limit. RFC 5321 specifies ESMTP and is silent about line length. RFC 5322, which defines the email message format, limits lines in an email message to 998 octets. The limit is in the email format, rather than the ESMTP protocol.

I'm not bothered if we don't support pre-ESMTP servers. I do care whether we produce properly formatted email messages. Long lines require wrapping, and that means either base64 or quoted-printable. For plain text data, quoted-printable is less likely to be filtered as spam than base64. It's also easier to read with plain text tools such as less.

I'd be willing to implement quoted-printable formatting at some point if that's the direction we want to go.

It is actually extremely effective. Most spam-ware produces invalid messages, and IME almost all malformed messages are spam. I use a variety of techniques, including this one and most of the others you've mentioned. Other people do so as well.

Regardless, a default mail server configuration on Debian rejects overly long lines, and there are various other systems that do so as well, so "just send it" isn't a viable solution. Fixing Git so it produces valid data in this case seems more robust.

I seem to be mistaken about the degree to which this is standardized and supported. The Debian argument cinches it for me. Quoted printable is probably the right way to go, then.