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

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

[Drew DeVault]

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

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

On Fri, Jun 29, 2018 at 03:07:51PM -0400, Drew DeVault wrote:
> 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.

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

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

[Drew DeVault]

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.

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

On Sun, Jul 01, 2018 at 08:17:53PM -0400, Drew DeVault wrote:
> On 2018-07-01  6:15 PM, brian m. carlson wrote:
> > 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.

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.

> Also, Extended SMTP is a standard. RFC 1869.

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.

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

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

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.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

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

[Drew DeVault]

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.