Re: comast email issues, who else has them?
Ack: X-Originating-From should be mandatory. $.02, - ferg -- David Ulevitch <davidu@everydns.net> wrote: On Sep 1, 2006, at 6:33 PM, Brandon Galbraith wrote:
I never understood why Gmail didn't put an X-Originating-From header in mail sent out by web users.
Seconded! It may not be a requirement but the omission is certainly inconsistent with most web-based email services, particularly a popular one like Gmail. A lot of abuse ends at a dead-end because trying to deal with security/abuse @ gmail is a losing cause. -david -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
On Sat, 2 Sep 2006, Fergie wrote:
Ack: X-Originating-From should be mandatory.
Mandatory and the Internet? Heck even our standards are called "requests." You don't have to exchange E-mail with either Google, Comcast or any other Mail Service Provider if you don't want to. You don't even need to give a reason why unless you've made promises to a customer. Don't be excessively annoying. Don't be too easily annoyed.
Once upon a time, Sean Donelan <sean@donelan.com> said:
You don't have to exchange E-mail with either Google, Comcast or any other Mail Service Provider if you don't want to.
Just wait until "Net Neutrality" laws require you to. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
At 03:24 PM 9/6/2006, you wrote:
Once upon a time, Sean Donelan <sean@donelan.com> said:
You don't have to exchange E-mail with either Google, Comcast or any other Mail Service Provider if you don't want to.
Just wait until "Net Neutrality" laws require you to.
...or with spammers! That's always been my fear about net neutrality laws. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin
On Sat, 2 Sep 2006, Fergie wrote:
Ack: X-Originating-From should be mandatory.
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.) Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD.
On Mon, 11 Sep 2006, Tony Finch wrote:
On Sat, 2 Sep 2006, Fergie wrote:
Ack: X-Originating-From should be mandatory.
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. 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). In case of web-based email services however, the start of the transmission is the webserver which is the one putting data in RFC2822 format and initiating the transmission. So use of "with HTTP" is inappropriate here - the only case where "with HTTP" would be appropriate is when email client like Thunderbird creates entire email message as it normally would but instead of using SMTP or SUBMIT to send it, it is sending the data using HTTP PUT or SOAP or XML-RPC - this is not the case with web-based email. 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. -- William Leibzon Elan Networks william@elan.net
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. 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.
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?
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. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD.
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
william(at)elan.net wrote:
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.
Really?! -- Requiescas in pace o email Ex turpi causa non oritur actio http://members.cox.net/larrysheldon/
On Mon, 11 Sep 2006, Laurence F. Sheldon, Jr. wrote:
william(at)elan.net wrote:
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.
Really?!
Yes. Since we're talking text messaging protocols (i.e. email or alike). HTTP when used with webmail a transport protocol, but not messaging protocol as it does not define anything like "From" or "To" fields. -- William Leibzon Elan Networks william@elan.net
participants (7)
-
Chris Adams -
Fergie -
Laurence F. Sheldon, Jr. -
Robert Boyle -
Sean Donelan -
Tony Finch -
william(at)elan.net