I would like some opinions on how certain RFCs are to be interpreted.
My core question is: Is it possible to send mail RFC-conformly into a
Postfix, such that there are more than 1000 consecutive Non-CRLFs?
I think everybody agrees that this is not possible with DATA. The
BDAT_README seems to imply that this isn't possible without BINARYMIME
either (which Postfix does not support):
Postfix does not support BINARYMIME at this time because:
BINARYMIME support would require moderately invasive changes to
Postfix, to
support email content that is not line-oriented. [...] Without BINARYMIME
support, email RFCs require that binary content is base64-encoded, and
formatted as lines of text
I am not so sure about the last sentence.
It is clear that the transported payload needs to adhere to RFC2045,
with DATA or BDAT, with or without BINARYMIME.
RFC3030 explicitly associates BINARYMIME with RFC2045's "binary"
mechanism, i.e. "Content-Transfer-Encoding: binary". RFC2045 even
acknowledges the following for binary:
As of the initial publication of this document, there are no standardized
Internet mail transports for which it is legitimate to include
unencoded binary
data in mail bodies. Thus there are no circumstances in which the "binary"
Content-Transfer-Encoding is actually valid in Internet mail.
But the same paragraph also states:
However, in the event that binary mail transport becomes a reality in
Internet
mail, or when MIME is used in conjunction with any other
binary-capable mail
transport mechanism, binary bodies must be labelled as such using this
mechanism.
It seems that the BDAT_README sees the announcement of BINARYMIME
support as necessary to "becoming reality", while I do not see a reason
why BDAT support itself could not already have made it become reality.
BINARYMIME has been explicitly designed for RFC2045's binary mechanism,
yes, but BDAT might just be one of "any other binary-capable" mechanisms.
So where does some of the RFCs forbid to combine BDAT with BODY=7BIT or
BODY=8BITMIME, Content-Transfer-Encoding: binary, and a 1000+ octet
Non-CRLF-ASCII string?
Note that the term "binary-capable" cannot be defined as
"BINARYMIME-capable", because RFC2045 is older than RFC3030, so one
cannot mechanically infer "not binary-capable" from "not
BINARYMIME-capable".
Also note that although RFC1652 (8BITMIME) explicitly mentions the 1000
octet limit itself, it also mentions dot-stuffing, which Postfix
(rightfully) ignores when using BDAT.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
