Subject: Message munging?

From: Dave Sill <[email-masked]>
Date: Thu, 13 Jul 2000 07:58:49 -0400 (EDT)

Is there anything in 821 or its proposed sucessor that prevents MTA's
from arbitrarily munging messages? I couldn't find anything.

This came up on the list-managers list when it was reported that AOL
was replacing "<" in subjects with "<." to disable some potentially
dangerous HTML-like extensions their mailer supports. This breaks a
list subscription confirmation scheme that encloses magic cookies in
angle brackets.

-Dave

---

From: Dave Sill <[email-masked]>
Date: Fri, 14 Jul 2000 07:38:21 -0400 (EDT)

>list subscription confirmation scheme that encloses magic cookies in

I've received no responses. If this is stupid question, please
enlighten me.

-Dave

---

From: Philip Hazel <[email-masked]>
Date: Fri, 14 Jul 2000 14:12:07 +0100 (BST)

> I've received no responses. If this is stupid question, please

The RFCs are all about interworking, that is, how to transfer a message
over the Internet. They don't say anything about what an MTA may or may 
not do in the privacy of its own host.

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: Dave Sill <[email-masked]>
Date: Fri, 14 Jul 2000 09:34:04 -0400 (EDT)

>not do in the privacy of its own host.

I understand that 821 only covers message transfer between hosts, and
that hosts can do what they want once the message is received, but
does it not provide any guarantee that a message leaving one host
bears a resemblence to the message received by another? So if
Microsoft Exchange replaced all occurrences of the string "Winblows"
with "Windows"--even for messages it's only relaying--that wouldn't
violate any RFC's? Strange.

Outside of the question of RFC-legality, what do people think of AOL's
Subject rewriting ("<" replaced with "<.") as a solution to their
problem?

-Dave

---

From: Philip Hazel <[email-masked]>
Date: Fri, 14 Jul 2000 14:59:50 +0100 (BST)

> violate any RFC's? Strange.

Ah well, that depends on what you mean by "relaying". The new draft for 
821bis says:

  2.3.8 Originator, Delivery, Relay, and Gateway Systems            
                                                              
  This specification makes a distinction among four types of SMTP            
  systems, based on the role those systems play in transmitting             
  electronic mail.  An "originating" system (sometimes called an SMTP   
  originator) introduces mail into the Internet or, more generally, into  
  a transport service environment.  A "delivery" SMTP system is one that   
  receives mail from a transport service environment and passes it to a    
  mail user agent or deposits it in a message store which a mail user    
  agent is expected to subsequently access.  A "relay" SMTP system   
  (usually referred to just as a "relay") receives mail from an SMTP    
  client and transmits it, without modification to the message data other
  than adding trace information, to another SMTP server for further        
  relaying or for delivery.       
  
  A "gateway" SMTP system (usually referred to just as a "gateway")
  receives mail from a client system in one transport environment and      
  transmits it to a server system in another transport environment.      
  Differences in protocols or message semantics between the transport      
  environments on either side of a gateway may require that the gateway  
  system perform transformations to the message that are not permitted to  
  SMTP relay systems.  For the purposes of this specification, firewalls   
  that rewrite addresses should be considered as gateways, even if SMTP    
  is used on both sides of them.  

That is, if a system is "relaying", it must not modify the message. But
who declares that a particular host is a "relay"? I think this is a post 
hoc thing: IF a host receives messages AND transmits them without 
modification THEN it is a relay. Otherwise it's a gateway. Sounds like 
AOL is a gateway in this terminology.

> Subject rewriting ("<" replaced with "<.") as a solution to their

It's crap, of course.

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Jul 2000 11:45:31 -0400

--On Friday, July 14, 2000 2:59 PM +0100 Philip Hazel
<[email-masked]> wrote:

>... 
> That is, if a system is "relaying", it must not modify the
> message. But who declares that a particular host is a "relay"?
> I think this is a post  hoc thing: IF a host receives messages
> AND transmits them without  modification THEN it is a relay.
> Otherwise it's a gateway. Sounds like  AOL is a gateway in this
> terminology.

It is a little tighter than that although arguably not much.  If
I have a boundary, with an Internet and Internet mail environment
on one side and some "other" stuff (e.g., private transport
protocols, a private address space one is trying to use to hide
information,  and/or a proprietary mail system on the other side)
then the "gateway" rules clearly apply.  AOL, as I understand it,
meets several of those criteria so, while what they are doing is
arguably in lousy taste, it isn't prohibited by the standards.

Personally, I would love to prohibit it (and I suspect most of
DRUMS would as well), but I believe it is nearly impossible to
write rules that would make their behavior protocol-invalid while
permitting more traditional gateways into other sorts of mail
systems (e.g., UUCP mail as well as proprietary ones) to work in
a way generally believed to be acceptable and conforming.  

And, of course, if we were to put the effort into constructing
such a rule, AOL would almost certainly ignore it, since what
they are doing makes market sense to them and "works" as they and
the overwhelming number of their users define that term.   If one
doesn't like that, the best option is to try to convince a large
fraction of their users that they actually don't like the
behavior and are willing to move on if AOL doesn't fix it.  If
one could do that, I'd predict a quick change of course from
them.  The odds, however, are not good.

> It's crap, of course.

Yes, that about covers it.  Put more politely, working around
what is apparently a piece of sloppy implementation work with a
nasty, user-visible kludge is never anything of which one should
be proud.

     john

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Jul 2000 14:08:42 -0400

> bears a resemblence to the message received by another? 

perhaps not.  it doesn't tell you not to shoot yourself either.
sometimes obvious things are left unspecified.

Keith

---

From: Dave Sill <[email-masked]>
Date: Fri, 14 Jul 2000 15:02:59 -0400 (EDT)

>perhaps not.  it doesn't tell you not to shoot yourself either.

Right, but if I do that, mail won't be affected.

>sometimes obvious things are left unspecified.

Yeah, but it seems a little odd to spend years hashing out the
minutiae when something as fundamental as message integrity isn't even 
specified. But I do realize it's a sticky subject and not something
DRUMS should try to fix.

But when some 800-pound gorilla starts munging messages, it's a lot
better to be able to point at an RFC than to tell them that what
they're doing is so obviously wrong that it wasn't specified--and,
hence, isn't illegal.

Not that the gorilla would care, though...

-Dave

---

From: Keith Moore <[email-masked]>
Date: Fri, 14 Jul 2000 17:32:23 -0400

> Right, but if I do that, mail won't be affected.

depends on which MTA you're running. :)

> specified. But I do realize it's a sticky subject and not something

for what it's worth, the BINARYMIME SMTP extension does specify 
rules for message integrity.  821bis could quite reasonably adopt
similar rules, but gorillas will always be able to get around the
rules by claiming that they're operating gateways rather than 
relaying MTAs.

> Not that the gorilla would care, though...

I suspect that the gorilla already knows that it's doing bad things,
and that there are better ways to fix the problem, but it would 
rather gather more bananas.

Keith