On 3 Apr 2009, at 20:24, Tony Hansen wrote:
> Are there any Mail User Agents that use BINARYMIME (and CHUNKING, of
> course) to submit messages, if the submission server supports
> BINARYMIME+CHUNKING? Or do all the MUAs just encode their attachments
> using base64/quoted-printable and not bother checking to see if they
> need to?
Even the clients from vendors who servers support CHUNKING don't seem
to know how to construct MIME sections with CTE of Binary.
Indeed. I don't believe I've ever seen a publicly available client capable of
it either. All the binary messages I have are ones I've constructed myself
using a seriously hacked up client.
FWIW, we have had some support in place for binary for a long, long time, but
I've never been willing to enable it. We had quite enough trouble with CHUNKING
and various firewalls, thank you very much.
Sad, really. There's no reason why SMTP can't be a perfectly usable
asynchronous file transfer service, and that'll be all the more
essential when we're all using IPv6 and do it for ourselves. (Or
perhaps the coffee is a little too strong again.)
Binary isn't required for an asynchronous file transfer service, it merely
makes it more efficient. And most of the benefits of binary would be provided
by a more efficient encoding that stays within the line limits.
On a related note, Pegasus Mail refuses to adapt to the awful reality
that everybody else is willing to handle arbitrary line lengths.
Shall we go around making it mandatory?
You're quite wrong about that. We don't allow arbitrary line lengths in our
software. In fact even though we allow longer lines internally we enforce the
RFC-stated limits pretty carefully and provide a number of options for dealing
with incompliant material, NOT including sending it on unchanged. (I reject
categorically and absolutely the "I can send along anything I got" theory of
operation.) I would object in the strongest terms to any attempt to alter this
in the standards at this late date.
Now, if Pegasus Mail falls over when presented with overly long lines or
something similar, that's a robustness issue that needs to be fixed. But it is
in no way a standards issue - it is axiomatic that no input, no matter how
malformed, should be able to kill a piece of server software.
Ned