ietf-smtp
[Top] [All Lists]

Re: revised Email Architecture draft

2005-01-29 12:47:03

On Thu January 27 2005 13:45, Dave Crocker wrote:
  ? The agent responsible for gatewaying the message may choose
  ? to specify a new address to receive handling notices.

  Generally it's not only a "may" for a gateway, but a "should".
  The only case where keeping the original "Mail From" could make
  sense is when original sender and recipient are in the same
  "messaging environment" (aka net), e.g. moderated newsgroups.

Actually, this depends upon how seamlessly the gateway can emulate being a 
relay. The goal of a gateway is to provide perfect emulation, to the two 
email services it is interconnecting.

There is a problem with the draft in that is speaks (in several
places) about gateways as exclusively dealing with email, which
is not the only situations where gateways are used. Gateways may
exist between voice mail (VPIM) and email, between email and fax,
and between email and Usenet news (that is not intended to be an
exhaustive list).  In the latter case in particular, there is no
equivalent of an envelope sender mailbox on the news side of a
gateway, so the only sensible thing is for a news-to-mail gateway
to provide is the mailbox of a responsible gateway administrative
authority in the SMTP envelope of mail sent via SMTP (or in the
equivalents if other mechanisms are used).

To each of them, it seeks to appear as an ideal relay.

No, a gateway modifies message content; a relay does not. A
gateway needs to have a complete message to do its job (as opposed
to a single MIME message/partial fragment); a relay doesn't care
about content.  Architecturally, therefore, all gateways must be
topologically located at a point on the destination side of all
MX hosts for the destination domain, so that fragments which take
different paths due to MX load balancing etc. can be guaranteed
to (all) be available at the gateway for reassembly as a precondition
for the gateway to do its message content processing.  That includes
gateways which purport to perform scanning of content, and failure
to do so properly has resulted in problems as documented in US-CERT
vulnerability note VU#386088.  These issues are not addressed
sufficiently in the draft under discussion, and the draft seems to
muddle matters by including both relays and gateways (as well as
list expanders) under the "mediators" category.

However gatewaying is needed when there are significant differences between 
the service; such differences pretty much always affect visible mail service 
semantics.  So perfect emulation is not possible. In any event when the two 
different email service have reasonably close semantics, then even the 
notifications/bounce mechanism can be emulated.  

Again, consider gateways where one side is non-mail; gateways
are not solely between mail environments.

  IMHO gateway considerations should not be a part of the MUA
  section.  MUAs (ab)used as gateways are normally very bad news.

The nature of a gateway is that it alters the message.  It is not merely part 
of the underlying transfer service.

So far, so good.

Recognizing that gateways operate at the MUA level (as well as, yes, the MHS 
level) is an explicit goal for the architecture document. 

But gateways do not operate at the MUA level.  An MUA does not
handle a message until a user (i.e. the 'U' in MUA) takes some
action.  A gateway receives and sends messages without any
user involvement.  One might liken a gateway to an MDA, since
both appear at the same topological point in the mail network.
But even that is a bit of a stretch; a gateway is really a
different type of entity.