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:
signature.asc
Description: PGP signature
