Re: header-munging

[Einar Stefferud <Stef@xxxxxxx>]

I have to agree with Dan here (though I must say it makes me smile as
I am reminded of how many times people grudgingly announce that they
suddenly find themselves agreeing with me;-)...  I can appreciate the
pain;-)...

>From Dan's 11 Sep 1996 04:38:05 reply to Randall's msg...
}
}> I think it might be much easier to consolidate these policy rules into
}> one SMTP server, in which case allowing both RELAY and SUBMIT on the
}> SMTP port would be good.
}
}I don't understand. Does code consolidation imply port consolidation?
}

The fact is that code consolidation does not require port
consolidation, or standards document consolidation, or ...  If it did,
then I expect that all Internet code would best be consolidated in a
single Internet Code Monolith, with only one constantly evolving
standards document.

The biggest point I was trying to make, and which Randall is trying to
negate, is that it does not matter how, or how much, code is
consolidated into your favourite monolith, as long as your runing code
results are faithful to the abstract model as cast in the standards
when the results of running the monolith are inspected "on the wire".

If I cannot detect any violations "on the wire" then I cannot claim
that your monolith has done anything improper.

}
}> The I-D draft-gellens-submit-01.txt proposes an ESMTP keyword to specify
}> RELAY or SUBMIT, and also suggests an optional additional port.
}
}In what situation is SUBMIT better than a separate port?
}

So, one reason to adopt the use of separate port numbers for RELAY and
SUBMIT is to expose the choice "on the wire" and thus be better able
to get implementors to do a better job of doing the right thing.

Again, we must make a very clear and simple delineation between the
abstract model:

 MUA-COMPOSE => MUA-SUBMIT => MTA-RELAY => MTA-MUA-DELIVER => MUA-RECEIVE
                           ***************

SMTP defines only MTA-RELAY.  All other processes are performed under
MUA authority (according to our undocumented abstract Internet EMail
model), as they are outside the realm of relaying.  IMAP and POP part
and parcel operate under MUA authority (actually under control of an
MUA "client"), and SUBMIT should be equally so.

So, what is the point of combining these things on a single port, just
so you can spend cycles and complicated round trips negotiating about
what you really meant to do after connecting to a dual purpose port.

What do yuou gain by overloading the port, if you have to spend sycles
and round trips disambiguating the overload?  Do you work for a
hardware vendor, or for a bandwith vendor?

If you know what you want to do (i.e., RELAY or SUBMIT), just connect
to the right port an do it.  If you want a single monolith to answer
separately to two ports, be my guest.  

Doing so is Mostly Harmless;-)...  Cheers...\Stef