Subject: RE: [Asrg] How to defeat spam that uses encryption?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 20 Apr 2003 11:32:56 -0700

> HBP> Base64 exists for one reason alone - because stupid MTAs had a
> HBP> habit of molesting the messages they were transmitting.
> 
> DC> Base64 was added to permit sending random 8-bit data
> DC> within a 7-bit stream.
> 
> DC> There was no intent to try to trick intermediaries.

> I think Dave's real problem was with the term "molest" -- if a 7-bit 
> protocol is given 8-bit data, it can't do *anything* wrong or 
> malicious 
> -- having been fed illegal data, its behavior is completely 
> unspecified.  You're lucky it doesn't release poison gas into your 
> server room.  :-)  -- Nathaniel

Oh there are worse problems than 7-bit transport which was in
decline long before MIME came arround.

Lots of MTAs perform arbitrary transformations on text before
it is sent. In many cases an MTA will wrap lines so as not to
cause overflow on the user terminal of the MTA. Changing CR to
CRLF is common, as is the exact opposite. Lots of IBM mainframes
have MTAs that append the sequence =20 to the end of each line
for reasons only known to themselves. 

The word 'molest' was chosen quite deliberately. And all these 
problems exist whether you have 8-bit or 7-bit transport.

		Phill
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 20 Apr 2003 15:21:31 -0400

> problems exist whether you have 8-bit or 7-bit transport.

Yes, that's why I didn't recommend or even mention 8-bit transport.  I 
recommended binary transport.  There's a big difference, and the 
problems you describe all go away with binary transport.  You're 
arguing with a straw man that nobody is advocating -- please check out 
RFC 3030, as I mentioned in my previous message.

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 22 Apr 2003 15:53:39 +0100

On 20 April 2003 20:22 Nathaniel Borenstein wrote
> RFC 3030, as I mentioned in my previous message.

If you are claiming RFC3030 supports binary as opposed to 8-bit streams, try
reading it yourself sometime, explicitly this passage:-

> A new SMTP verb, BDAT, is defined as an alternative to the "DATA" command
of
> [RFC821]. The BDAT verb takes two arguments. The first argument indicates
the
> length, in octets, of the binary data chunk. The second optional argument
> indicates that the data chunk is the last.

That makes it pretty clear that the proposal supports the transport of
octets, (an 8-bit transport), not of bits (a binary transport). A binary
transport would allow me to transmit 37 bits, or 125 bits, or 10725412973
bits or indeed any number of bits, not just a multiple of 8 bits.  For an
example of a binary transport mechanism look at the definition of the HDLC
protocol (or IBM's SDLP, for that matter, if that's easier for you to find)
which are designed explicitly to permit units of any number of bits to be
transferred.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 22 Apr 2003 12:52:48 -0400

> transport would allow me to transmit 37 bits, or 125 bits, or 

I'll grant all of this, but I don't think it changes the answer in 
context; that is, even if you don't think it is appropriate to call it 
binary transport, I think it has the characteristics that I was 
ascribing to binary transport in terms of its (lack of) effect on the 
payload being transmitted.  -- NB