Droid SMTP [padding the stack] TRansitional errors causing overflow?

[Russell Reiter]

Some info and a couple of questions in pursuit of ASCII email
messaging from my droid.

Bare LF's in Message bodies are not allowed per RFC 2821:

2.3.7 Lines

   SMTP commands and, unless altered by a service extension, message
   data, are transmitted in "lines".  Lines consist of zero or more data
   characters terminated by the sequence ASCII character "CR" (hex value
   0D) followed immediately by ASCII character "LF" (hex value 0A).
   This termination sequence is denoted as <CRLF> in this document.
   Conforming implementations MUST NOT recognize or generate any other
   character or character sequence as a line terminator.  Limits MAY be
   imposed on line lengths by servers (see section 4.5.3).

   In addition, the appearance of "bare" "CR" or "LF" characters in text
   (i.e., either without the other) has a long history of causing
   problems in mail implementations and applications that use the mail
   system as a tool.  SMTP client implementations MUST NOT transmit
   these characters except when they are intended as line terminators
   and then MUST, as indicated above, transmit them only as a <CRLF>
   sequence.

Is this actually a violation of the RFC?

if a body is base64 encoded, the LF can not be mistakenly interpreted
as an SMTP line terminator, can it?

RFC 3548

2.3.  Interpretation of non-alphabet characters in encoded data

   Base encoding uses a specific, reduced, alphabet to encode binary
   data.  Non alphabet characters could exist within base encoded data,
   caused by data corruption or by design.  Non alphabet characters may
   be exploited as a "covert channel", where non-protocol data can be
   sent for nefarious purposes.  Non alphabet characters might also be
   sent in order to exploit implementation errors leading to, e.g.,
   buffer overflow attacks.

   Implementations MUST reject the encoding if it contains characters
   outside the base alphabet when interpreting base encoded data, unless
   the specification referring to this document explicitly states
   otherwise.  Such specifications may, as MIME does, instead state that
   characters outside the base encoding alphabet should simply be
   ignored when interpreting data ("be liberal in what you accept").
   Note that this means that any CRLF constitute "non alphabet
   characters" and are ignored.  Furthermore, such specifications may
   consider the pad character, "=", as not part of the base alphabet
   until the end of the string.  If more than the allowed number of pad
   characters are found at the end of the string, e.g., a base 64 string
   terminated with "===", the excess pad characters could be ignored.

What happens if they are not being ignored correctly?

If the mta just sweeps up all the bits it sees and pushes them
upstream, the transport server drops the ball on the first hop. It may
not be able to handle the bits which begin with = or other parts
thereof.

Is it multiple concurrent pushing of mime content which is bleeding
over to smtp or truly does android lack the ability to mail plain
ascii text?

--
Apologies to Simon Travaglia

SCK=Science Centre Kid
BOFH=Bash Operator From Hell

SCK: Hey I can't get this bash script you gave me to work!

BOFH: Try single quoting it.

SCK: Ok, it's running.

SCK: Hey, what's `rm -r .* '. do anyway?

BOFH: hehehehehehe
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists