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

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- 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 --]