Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: comast email issues, who else has them?

  • From: william(at)elan.net
  • Date: Mon Sep 11 15:39:04 2006


On Mon, 11 Sep 2006, Tony Finch wrote:

On Mon, 11 Sep 2006, william(at)elan.net wrote:
On Mon, 11 Sep 2006, Tony Finch wrote:
Far better to use a Received: header stating HTTP in the "with"
protocol field. (And the IANA registry should be updated to include
that as one of the standard values.)
That suggestion is likely to be contrary to SMTP design. Received trace
fields are for use of recording of where data that was RFC2822 formatted
came from and how. Use of these fields also assumes that start of email
transmission took place somewhere else.
I'm not entirely convinced by that argument. You could squint a bit
and view webmail as a sort of gatewaying, in which case it makes sense to
map webby concepts onto 821 and 822 as accurately as possible.
You need to have protocol to map it from. HTTP is not a protocol but type of transport of initial email submission data to a submission
server.

The other
reason for using Received: for this kind of job is it scales better to
other submission methods: what about an XMPP-to-email gateway, for
example? It would be madness to define ad-hoc X- headers for each
submission protocol.
I never said about defining X- fields for each protocol (although it
does appear to be the way things are being done right now). I said
that there is a need for submission trace field to identify source of
submission no matter how initial submission of data was done.

As far as XMPP if you can define proper mapping from and to SMTP then
you likely can start using "with" clause in Received for when first
SMTP email server is talking about message that came from XMPP.

The "with" clause in Received is used to indicate the "transport"
protocol but assumes that data itself is already properly formatted
(compare to that the same type of L7 protocol can use either TCP or UDP;
this is not perfect fit but gives you some idea).
What about "with MMS" where the message format is not (quite) 822?
They defined proper mapping in RFC4356. Personally I think mapped protocols
should use "via" clause but it appears the way things are currently being done is that when mapping exist then "with" can be used. If you do not
have mapping and just using protocol for direct transfer of data then
"with" is only appropriate if entire data was already in appropriate RFC2822 form.

If you really want to indicate the source of transmission for non-SMTP
origination point, the best is to create new trace field for this purpose.
With Received the closest clause would be "via" but I think via is largely for
use with complete message being gatewayed through non-SMTP protocol and this
is probably not the correct use of it either.
The only non-TCP via defined at the moment is UUCP, which I guess implies
batch SMTP - i.e. "via" is the level under the message transport protocol.
I think that "via" is probably for use with a transport-level protocol independent of internet, i.e. gateway to/from non-internet world. That is why I think that "via" would have been better for use with "MMS". In any
case I've yet to see any convincing argument that "with HTTP" as couple
places are doing is appropriate nor is "via HTTP" likely any better.


P.S. I've distinct feeling there < 1% on this list who care about such
details of SMTP as we discussed and are interested in discussing it (the person who raised the issue originally probably only meant that he wants
to see ip address of the user creating webmail message and does not care how that information is carried as long as all are doing it). For protocol
details, perhaps it would be better if this discussion were to move to ietf-smtp@imc.org...

--
William Leibzon
Elan Networks
william@elan.net




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.