python - 为什么 Python 的 MIMEMultipart 生成带有换行符的附件文件名？

Question

我正在发送一封带附件的电子邮件，该附件的文件名很长。为什么它会被换行符损坏，系统的哪一部分应该知道这些换行符应该被删除？

from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.mime.application import MIMEApplication
from email.utils import formatdate

msg = MIMEMultipart()
msg['Subject'] = 'subject'
msg['To'] = 'a@example.com'
msg['From'] = 'b@example.com'
msg['Date'] = formatdate(localtime=True)
msg.attach(MIMEText('abc'))

attachment_name = 'abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz.txt'
part = MIMEApplication("sometext", Name=attachment_name)
part['Content-Disposition'] = 'attachment; filename="%s"' % attachment_name
msg.attach(part)

print msg.as_string()

给我:

Content-Type: multipart/mixed; boundary="===============1448866158=="
MIME-Version: 1.0
Subject: subject
To: a@example.com
From: b@example.com
Date: Sat, 20 Jan 2018 13:11:42 -0500

--===============1448866158==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

abc
--===============1448866158==
Content-Type: application/octet-stream;
 Name="abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz
 abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz
 abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz.txt"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="abcdefghijklmnopqrstuvwxyz
 abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz
 abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz
 abcdefghijklmnopqrstuvwxyz.txt"

c29tZXRleHQ=
--===============1448866158==--

Answer 1

长头字段的处理在 section 2.2.3 of RFC 2822 "Internet Message Format" 中定义.该部分在过时的 RFC 5322 中保持不变。 .

2.2.3. Long Header Fields

Each header field is logically a single line of characters comprisingthe field name, the colon, and the field body. For conveniencehowever, and to deal with the 998/78 character limitations per line,the field body portion of a header field can be split into a multipleline representation; this is called "folding". The general rule isthat wherever this standard allows for folding white space (not simplyWSP characters), a CRLF may be inserted before any WSP. For example,the header field:

Subject: This is a test

can be represented as:

Subject: This
 is a test

Note: Though structured field bodies are defined in such a way thatfolding can take place between many of the lexical tokens (and evenwithin some of the lexical tokens), folding SHOULD be limited toplacing the CRLF at higher-level syntactic breaks. For instance, if afield body is defined as comma-separated values, it is recommendedthat folding occur after the comma separating the structured items inpreference to other places where the field could be folded, even if itis allowed elsewhere.

The process of moving from this folded multiple-line representation ofa header field to its single line representation is called"unfolding". Unfolding is accomplished by simply removing any CRLFthat is immediately followed by WSP. Each header field should betreated in its unfolded form for further syntactic and semanticevaluation.