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 comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP 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 that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere.

The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation.