Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
David F. Skoll wrote: There is no need for you to know who the ultimate enduser composing the e-mail is. I don't want to know who the ultimate end-user is. I just want to know the IP address of the machine that injected the email into Google. It's a valuable of information I can use in my filter. How can it possibly matter if my laptop is sending from a Panera Bread hotspot or a hotel room where it hasn't been before and probably won't be again? Any decision you make based on that information is almost certainly going to be wrong or biased by unrelated things done by other people at some other time. The relevant piece of information is that I authenticated to the server that sent the message. -- Les Mikesell lemikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Les Mikesell wrote: How can it possibly matter if my laptop is sending from a Panera Bread hotspot or a hotel room where it hasn't been before and probably won't be again? Any decision you make based on that information is almost certainly going to be wrong or biased by unrelated things done by other people at some other time. The relevant piece of information is that I authenticated to the server that sent the message. It's my decision to make, not Google's. And anyway, if you used SMTP rather than HTTP to submit the message, I *would* know your IP address. Anyway... let's kill this thread because we will never agree. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 5:55 PM, Les Mikesell wrote: not add a Received: header for the browser client IP. Likewise when sending from outlook 2003 or 2007 (much more believable as mail clients) through exchange, the first Received: header is the server's. Does that Received: header say where it got the message from, and how? ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
-Original Message- From: Matt Garretson On 2/17/2010 5:55 PM, Les Mikesell wrote: not add a Received: header for the browser client IP. Likewise when sending from outlook 2003 or 2007 (much more believable as mail clients) through exchange, the first Received: header is the server's. Does that Received: header say where it got the message from, and how? Actually mail from an Exchange server - whether through an Outlook client or Outlook Web - does not have a Received header at all. The first one you see will be added by the next server upstream. Instead it will have X-MimeOLE: Produced By Microsoft Exchange Vx.x Exchange will only add a Received header when it relays a message received via SMTP. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Joseph Brennan wrote: I was baiting you :-) The HTTP hop from end user to Gmail's webmail server is not SMTP, so it's not covered by RFC 2821. Well, RFC 5321 says: When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header section. and it defines a gateway as: As discussed in Section 2.3.10, when such a system is at the boundary between two transport service environments, we refer to it as a gateway or gateway SMTP. So... I would say that gmail.com is violating a MUST requirement of RFC 5321. Here's something similar. When I log into a timeshare and send mail with Pine, you don't get to see the ssh hop from my Mac either. There's no email gatewaying going on between your Mac and Pine. And the IP address of the Pine box is sufficient to determine the organization (maybe even the person) responsible for originating the mail. I agree that it is extremely desirable to have the originating IP and like you I wish Gmail would provide it. I just don't think it's a standards violation. As I read RFC 5321, it seems like a violation. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On Wed, 17 Feb 2010 09:47:54 -0500 David F. Skoll d...@roaringpenguin.com wrote: Joseph Brennan wrote: I was baiting you :-) it should work :D) The HTTP hop from end user to Gmail's webmail server is not SMTP, so it's not covered by RFC 2821. Well, RFC 5321 says: When forwarding a message into or out of the Internet environment, a gateway MUST prepend a Received: line, but it MUST NOT alter in any way a Received: line that is already in the header section. and it defines a gateway as: As discussed in Section 2.3.10, when such a system is at the boundary between two transport service environments, we refer to it as a gateway or gateway SMTP. So... I would say that gmail.com is violating a MUST requirement of RFC 5321. ditto :-) Here's something similar. When I log into a timeshare and send mail with Pine, you don't get to see the ssh hop from my Mac either. There's no email gatewaying going on between your Mac and Pine. And the IP address of the Pine box is sufficient to determine the organization (maybe even the person) responsible for originating the mail. I agree that it is extremely desirable to have the originating IP and like you I wish Gmail would provide it. I just don't think it's a standards violation. As I read RFC 5321, it seems like a violation. seconded ;-) ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 8:47 AM, David F. Skoll wrote: So... I would say that gmail.com is violating a MUST requirement of RFC 5321. Here's something similar. When I log into a timeshare and send mail with Pine, you don't get to see the ssh hop from my Mac either. There's no email gatewaying going on between your Mac and Pine. And the IP address of the Pine box is sufficient to determine the organization (maybe even the person) responsible for originating the mail. How is running pine on a remote machine any different than running a web interface to mail, perhaps on that same remote machine? The real app is on the server side and the fact that it is displayed remotely doesn't have much to do with the mailer. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Les Mikesell wrote: How is running pine on a remote machine any different than running a web interface to mail, perhaps on that same remote machine? Because running pine over SSH is not a gateway as defined in RFC 5321, whereas running a Webmail server that accepts email using some kind of transport (HTTP or HTTPS) and then delivers it using SMTP *is* a gateway as defined in RFC 5321. Maybe you think it's splitting hairs, but we have to abide by the RFC, which is abundantly clear. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 10:07 AM, David F. Skoll wrote: Les Mikesell wrote: How is running pine on a remote machine any different than running a web interface to mail, perhaps on that same remote machine? Because running pine over SSH is not a gateway as defined in RFC 5321, whereas running a Webmail server that accepts email using some kind of transport (HTTP or HTTPS) and then delivers it using SMTP *is* a gateway as defined in RFC 5321. Sorry, but a web interface isn't an email gateway. The application running email isn't where the web interface displays it any more than it would be if you display thunderbird in a remote X session. Maybe you think it's splitting hairs, but we have to abide by the RFC, which is abundantly clear. But the RFC says nothing about remote displays and remote application acccess, whether provided by ssh, X, or http(s). My web browser knows nothing about mail and there is no gatewaying of email going on between it and gmail - it just displays what the remote app wants it to. Any concept of 'mail' starts on the server side - and is tied to the login on that remote system. Yes, you could pervert this to originate mail with a remote program, but you could do the same over ssh/pine (or a serial port for that matter), equally tied to your credentials on the remote host where the mail activity actually happens. I wouldn't object to showing the remote display's IP address in a header so I'm not arguing against that, but it is somewhat imaginative to think a web browser is the other half of an email gateway so the RFC requirement would apply. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Les Mikesell wrote: Because running pine over SSH is not a gateway as defined in RFC 5321, whereas running a Webmail server that accepts email using some kind of transport (HTTP or HTTPS) and then delivers it using SMTP *is* a gateway as defined in RFC 5321. Sorry, but a web interface isn't an email gateway. Transmitting an email via HTTP from a client computer qualifies as gatewaying by my reading of the RFC. The application running email isn't where the web interface displays it any more than it would be if you display thunderbird in a remote X session. No, that's not correct at all. Using HTTP as a transport protocol for email is quite different from using the X protocol to draw pixels on a remote display. But the RFC says nothing about remote displays and remote application acccess, whether provided by ssh, X, or http(s). The RFC defines a gateway as: 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. This describes webmail exactly. You type your email into a form in the Web browser which transmits it over HTTP to the server. That's the server receiving mail from a client system. [...] I wouldn't object to showing the remote display's IP address in a header so I'm not arguing against that, but it is somewhat imaginative to think a web browser is the other half of an email gateway so the RFC requirement would apply. I suppose we'll have to agree to disagree. I'd note that all other webmail providers and open-source Webmail programs disagree with Google. (Hotmail has to be different, of course; it uses X-Originating-IP: rather than a Received: header.) Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 12:05 PM, David F. Skoll wrote: Because running pine over SSH is not a gateway as defined in RFC 5321, whereas running a Webmail server that accepts email using some kind of transport (HTTP or HTTPS) and then delivers it using SMTP *is* a gateway as defined in RFC 5321. Sorry, but a web interface isn't an email gateway. Transmitting an email via HTTP from a client computer qualifies as gatewaying by my reading of the RFC. That means you have to think my web browser is also an email gateway. I don't see any reason to think it is more than a display transport. The application running email isn't where the web interface displays it any more than it would be if you display thunderbird in a remote X session. No, that's not correct at all. Using HTTP as a transport protocol for email is quite different from using the X protocol to draw pixels on a remote display. How so? X does more than draw pixels, but neither X nor http know anything about email or the contents of what they transport. That's all up to the application at the other end - and it's why they are both so useful. But the RFC says nothing about remote displays and remote application acccess, whether provided by ssh, X, or http(s). The RFC defines a gateway as: 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. This describes webmail exactly. You type your email into a form in the Web browser which transmits it over HTTP to the server. That's the server receiving mail from a client system. The browser displays a form, but only the application at the other end knows anything about the contents being mail. Which is exactly the same scenario as if I typed it into thunderbird in a remote X window. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Les Mikesell wrote: Transmitting an email via HTTP from a client computer qualifies as gatewaying by my reading of the RFC. That means you have to think my web browser is also an email gateway. No. You misunderstand. The web *server* is the email gateway. It gateways mail *from* the browser (using HTTP) *to* the Internet (using SMTP). How so? X does more than draw pixels, but neither X nor http know anything about email or the contents of what they transport. That's all up to the application at the other end - and it's why they are both so useful. The difference is that the SMTP gateway in the forwarded-X case cannot possibly know the IP address of the X display. In the Webmail case, the HTTP server absolutely does know the IP address of the client. Similar reasoning applies to the pine-over-SSH scenario: The SMTP gateway cannot possibly know the IP address of the SSH client. A gateway cannot supply information it does not have. Google, however, suppresses information it *does* have. The browser displays a form, but only the application at the other end knows anything about the contents being mail. Which is exactly the same scenario as if I typed it into thunderbird in a remote X window. I can't tell if you're baiting me or deliberately being obtuse, so I think I'll withhold further replies. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 12:56 PM, David F. Skoll wrote: Transmitting an email via HTTP from a client computer qualifies as gatewaying by my reading of the RFC. That means you have to think my web browser is also an email gateway. No. You misunderstand. The web *server* is the email gateway. It gateways mail *from* the browser (using HTTP) *to* the Internet (using SMTP). Gateways need something on both sides to participate. If it isn't email inside the browser (and it isn't, it is a form that the browser displays mindlessly and http carries blindly), how can it be a gateway operation? It originates as email from the web application on the server with the user's credentials. The browser displays a form, but only the application at the other end knows anything about the contents being mail. Which is exactly the same scenario as if I typed it into thunderbird in a remote X window. I can't tell if you're baiting me or deliberately being obtuse, so I think I'll withhold further replies. Partly both I suppose, but I don't like people interpreting RFC's oddly to support their own agenda, and I don't see how anything a browser does can be considered as any more than a remote display for a server side application. As an email admin you have the right to discard email whimsically - you don't have to interpret RFC's imaginatively to justify it. If that RFC had been intended to cover remote displays or web forms it could have said so - web interfaces were pretty well understood by then. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
(Why do I get sucked in? :)) No. You misunderstand. The web *server* is the email gateway. It gateways mail *from* the browser (using HTTP) *to* the Internet (using SMTP). Gateways need something on both sides to participate. Yep. On one side: The Web browser. On the other side: The rest of the Internet. Why is that so hard to understand? If it isn't email inside the browser (and it isn't, it is a form that the browser displays mindlessly and http carries blindly), how can it be a gateway operation? I'll explain... It originates as email from the web application on the server with the user's credentials. No. It originates as email from withing the browser. You may claim it's some black-box blob of data, but everyone who uses webmail will disagree. Stop someone and say What are you doing? He/she will say Writing an email, not filling in a form that the browser carries blindly and that turns into an email on the server. And if you ask Joe Brennan what he's doing, he'll say Composing an email on machine x.y.z.w that's running Pine. And if you ask a knowledgeable Thunderbird user with a remote X display what he's doing, he'll say Composing an email in Thunderbird running on machine x.y.z.w. It's clear to everyone where the real action is happening. Partly both I suppose, but I don't like people interpreting RFC's oddly to support their own agenda, You and Gmail are the only ones with this interpretation. Other Webmail providers (Yahoo, Hotmail) and Webmail software (Squirrelmail; Horde) use my interpretation. So I submit that you are the one interpreting the RFC oddly. and I don't see how anything a browser does can be considered as any more than a remote display for a server side application. Here's the thing: Between the Google Webmail server and the client's Web browser, there is an interface between two administrative domains. Google doesn't own the Web browser (yet!), but it does own the Web server. For tracing purposes, it is desirable (I would say mandatory) to track the flow of email across this interface. Generally speaking, between an X client and an X server, or between an SSH client and an SSH server, there is not an interface between two administrative domains. So apart from the fact that the SMTP gateway *cannot* report the client's IP, there's *no need* for it to do so. (If people started offering public-access Pine-over-SSH or public-access Thunderbird-over-X, I would change my position.) As an email admin you have the right to discard email whimsically. It's not whimsical at all. Google is suppressing critical information showing the flow of email from one administrative domain to another. This is purely evil and utterly unjustifiable. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 1:47 PM, David F. Skoll wrote: (Why do I get sucked in? :)) Because you would be equally pedantic if you thought someone else was misinterpreting and abusing an RFC... No. You misunderstand. The web *server* is the email gateway. It gateways mail *from* the browser (using HTTP) *to* the Internet (using SMTP). Gateways need something on both sides to participate. Yep. On one side: The Web browser. On the other side: The rest of the Internet. Why is that so hard to understand? It is not a non-internet mail system running inside my browser - which is what the RFC covers. No. It originates as email from withing the browser. You may claim it's some black-box blob of data, but everyone who uses webmail will disagree. Stop someone and say What are you doing? He/she will say Writing an email, not filling in a form that the browser carries blindly and that turns into an email on the server. No one thinks they are using a non-internet email system that runs inside their web browser or on their own machine - unless maybe they'd think facebook runs inside their laptop too. And if you ask Joe Brennan what he's doing, he'll say Composing an email on machine x.y.z.w that's running Pine. And if you ask a knowledgeable Thunderbird user with a remote X display what he's doing, he'll say Composing an email in Thunderbird running on machine x.y.z.w. It's clear to everyone where the real action is happening. Just as clear as it is that there is no mail system running inside my browser and no gateway operation from one mail system to another happening as I post. A person who would understand thunderbird running remotely would equally understand that gmail does not run on his local machine. Partly both I suppose, but I don't like people interpreting RFC's oddly to support their own agenda, You and Gmail are the only ones with this interpretation. Other Webmail providers (Yahoo, Hotmail) and Webmail software (Squirrelmail; Horde) use my interpretation. So I submit that you are the one interpreting the RFC oddly. Just because they add a header doesn't mean an RFC requires it - or at least not that RFC. Here's the thing: Between the Google Webmail server and the client's Web browser, there is an interface between two administrative domains. Google doesn't own the Web browser (yet!), but it does own the Web server. For tracing purposes, it is desirable (I would say mandatory) to track the flow of email across this interface. I don't necessarily disagree, I just don't think the gateway-related RFC applies here. Generally speaking, between an X client and an X server, or between an SSH client and an SSH server, there is not an interface between two administrative domains. So apart from the fact that the SMTP gateway *cannot* report the client's IP, there's *no need* for it to do so. (If people started offering public-access Pine-over-SSH or public-access Thunderbird-over-X, I would change my position.) I have an ssh account on a remote machine under approximately the same terms as my gmail mail account. I don't see any point here or any difference in originating mail from a program on that machine or the gmail program displaying in my web browser. They both originate under my credentials on the remote server and have no relationship to the keyboard where I'm typing. As an email admin you have the right to discard email whimsically. It's not whimsical at all. Google is suppressing critical information showing the flow of email from one administrative domain to another. This is purely evil and utterly unjustifiable. OK, but that is unrelated to the RFC - and a matter of opinion since it is really a remote display from the administrative domain where the mail originates. Anyway, I don't like web mail interfaces and almost never use it to access gmail. How do you process mail that came through a gmail account from a user interface that submits via SMTP where the appropriate Received: line is added (coming from thunderbird, I see both my private and NATted address in there)? If you drop that, who is doing the evil and unjustified thing? -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On Wed, Feb 17, 2010 at 02:47:53PM -0500, David F. Skoll wrote: You and Gmail are the only ones with this interpretation. Other Webmail providers (Yahoo, Hotmail) and Webmail software (Squirrelmail; Horde) use my interpretation. So I submit that you are the one interpreting the RFC oddly. Well, and me. As much as I like the idea of knowing the IP of the web client, its absence does not violate the RFC. The RFC reads to me to be discussing SMTP gateways, not requiring that the headers include the IP assigned to the computer on which the user is typing. I believe the ssh analogy is appropriate. Even better, consider telnet. If I telnet to the telnetd of a machine, and then use that machine to telnet to the localhost smtpd, I would expect to see the machine running telnetd as the first hop. The machine I am sitting on, with the first telnet client, would never appear in SMTP headers. A machine running httpd instead of telnetd is doing the same thing, so I would not expect the http client (or, possibly a telnet client!) to appear in the SMTP headers. The problem I see with David's interpretation is that the SMTP RFC can not, by definition, make requirements the protocol can not enforce. How can an smtpd know the IP of the original machine, since there are limitless ways to hop around networks before first speaking to an smtpd? The RFC appropriately requires any smtpd to record and include the full path an email has traversed, but it can't be asked to record information to which it can not possibly have access (specifically, it can't know the IP address of the machine before the earliest IP which began speaking the SMTP protocol). Lastly, google is not alone in this. Many private email systems offer http(s) interfaces and do not include the IP of the user's http client. This does not mean I do not agree that the ubiquity of web-to-smtp gateways introduces a special problem for the anti-spam crowd. And David, like everyone, is certainly free to decide from whom he will accept mail and for what reasons. I just do not agree that Google is violating the RFC. Matt -- GnuPG Key ID: 0xC33BD882 aim/google/MSN/yahoo: beyondzero123 A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. -Lazarus Long ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Les Mikesell wrote: It is not a non-internet mail system running inside my browser - which is what the RFC covers. The RFC defines a gateway as this: 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. Unfortunately, a transport environment is not defined by the RFC. I consider submission via HTTP to be sending mail over a transport environment. I think it's a reasonable interpretation, but alas... the RFC doesn't say. [...] OK, but that is unrelated to the RFC - and a matter of opinion since it is really a remote display from the administrative domain where the mail originates. Anyway, I don't like web mail interfaces and almost never use it to access gmail. How do you process mail that came through a gmail account from a user interface that submits via SMTP where the appropriate Received: line is added (coming from thunderbird, I see both my private and NATted address in there)? If you drop that, who is doing the evil and unjustified thing? Gmail has made its own bed. I can't trust anything coming from Gmail, so I reject it. Anyway... I guess this is a religious issue. I know I'm right, just as I know that emacs is the ultimate text editor. :) Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On Jul 10, 9:23am, David F. Skoll wrote:
}
} No. You misunderstand. The web *server* is the email gateway. It
} gateways mail *from* the browser (using HTTP) *to* the Internet (using
} SMTP).
}
} Gateways need something on both sides to participate.
}
} Yep. On one side: The Web browser. On the other side: The rest of
} the Internet. Why is that so hard to understand?
Yes, a web browser, not an MUA of any sort! I've worked with
numerous different e-mail related protocols over the years, but until
now, nobody has tried to convince me that HTTP{,S} has anything to do
with e-mail.
} If it isn't email inside the browser (and it isn't, it is a form
} that the browser displays mindlessly and http carries blindly), how
} can it be a gateway operation?
}
} I'll explain...
}
} It originates as email from the web application on the server with the
} user's credentials.
}
} No. It originates as email from withing the browser. You may claim
No, it doesn't.
} it's some black-box blob of data, but everyone who uses webmail will
Actually, multiple black-box blobs of data, but who's counting?
} disagree. Stop someone and say What are you doing? He/she will say
} Writing an email, not filling in a form that the browser carries
} blindly and that turns into an email on the server.
Yeah, so what? 99.9% of people using computers don't have the
slightest clue how it works or what is going on under the hood at any
given moment (this even goes for most Linux users -- most of them will
tell you that it's better then Windows, but ask them to articulate what
is going on under the hood, and they won't have a clue, unless they
happen to be a programmer).
BTW, what's an EGR and how does it work? What's a PCV and how
does it work? The only hint that I'll give is that these don't have
anything to do with computers.
} And if you ask Joe Brennan what he's doing, he'll say Composing an
} email on machine x.y.z.w that's running Pine. And if you ask a
} knowledgeable Thunderbird user with a remote X display what he's
} doing, he'll say Composing an email in Thunderbird running on machine
} x.y.z.w. It's clear to everyone where the real action is happening.
Yes, these people don't fit the 99.9%, and notice that they won't
tell that they are composing e-mail on their local machine.
} Partly both I suppose, but I don't like people interpreting RFC's oddly
} to support their own agenda,
}
} You and Gmail are the only ones with this interpretation. Other
No, they aren't the only ones. I've been mostly enjoying the
popcorn until now.
} Webmail providers (Yahoo, Hotmail) and Webmail software (Squirrelmail;
} Horde) use my interpretation. So I submit that you are the one
So what, we all know the general state of privacy in the US, i.e.
you have none. The rest of the world generally does a better job.
Google is at least trying.
} interpreting the RFC oddly.
}
} and I don't see how anything a browser does can be considered as any
} more than a remote display for a server side application.
}
} Here's the thing: Between the Google Webmail server and the client's
} Web browser, there is an interface between two administrative domains.
} Google doesn't own the Web browser (yet!), but it does own the Web
} server.
Yeah, so?
} For tracing purposes, it is desirable (I would say mandatory) to track
} the flow of email across this interface.
How do you know they don't? Just because they don't give you the
info, doesn't mean they don't track it.
} Generally speaking, between an X client and an X server, or between an
} SSH client and an SSH server, there is not an interface between two
} administrative domains. So apart from the fact that the SMTP gateway
I'm using an SSH client to talk to an SSH server on a different
machine. On that machine, I'm running an MUA to compose this e-mail.
The SSH client and SSH server are most definitely in different
administrative domains.
} *cannot* report the client's IP, there's *no need* for it to do so.
Nor, is there any need for Gmail to do so. Google is fully
responsible for anything emitted by the Gmail system. If you receive
spam from a Gmail user, report it to Google/Gmail. If Google fails to
deal with it appropriately that would make Google a spam friendly
entity and a problem. You can then deal with them on that basis.
There is no need for you to know who the ultimate enduser composing the
e-mail is.
} (If people started offering public-access Pine-over-SSH or
} public-access Thunderbird-over-X, I would change my position.)
Why? The person offering the service would still be responsible
for what happens on it.
} As an email admin you have the right to discard email whimsically.
}
} It's not whimsical at all. Google is suppressing critical information
} showing the flow of email from one administrative domain to another.
} This is purely evil and utterly unjustifiable.
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
On 2/17/2010 3:59 PM, David F. Skoll wrote: The RFC defines a gateway as this: 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. Unfortunately, a transport environment is not defined by the RFC. I consider submission via HTTP to be sending mail over a transport environment. I think it's a reasonable interpretation, but alas... the RFC doesn't say. We are obviously not going to agree here but a few more data points: using the OWA interface (outlook web access) to an exchange server does not add a Received: header for the browser client IP. Likewise when sending from outlook 2003 or 2007 (much more believable as mail clients) through exchange, the first Received: header is the server's. -- Les Mikesell lesmikes...@gmail.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Op 17 feb 2010, om 20:47 heeft David F. Skoll het volgende geschreven: You and Gmail are the only ones with this interpretation. And me too. What I find lacking in this discussion is the reason why google would do this. And I think I know why, because I'm tempted to do the same, at least for some recipients... For tracing purposes, it is desirable (I would say mandatory) to track the flow of email across this interface. Precisely. And here also lies the problem, as some receivers start rejecting email based on the contents of IP addresses found in the Received headers, based on questionable IP reputation lists. We have customers complaining to us that some other big (local, dutch) provider rejects all of their email. But if they send mail via gmail, it works fine, so it must be xs4all's problem (ie: my problem), according to the customer. Somehow, the IP address of a customer ended up on a reputation blacklist, possibly because of a virus infection somewhere in the past. A blacklist that is not easily queried even, and the remote mail server gives a very unhelpful 550 Message rejected. Provided the email was received as authenticated SMTP, scanned for spam, and the sender/IP checked for clean email behavior (not sending too much mail, causing too many bounces, etc), then my interpretation of what email is legit versus what email is spam, is probably better than the flaky deep-header-inspecting reputation list of the receiver, and I'd be tempted to remove or hide the real origin of that message, at least for specific receiving ISPs (we're not doing anything like that yet, though, that would really directly go against the RFC). I believe that that's the motivation why google hides the remote HTTP address (blaming privacy seems very silly in light of Eric Schmidt's recent remarks). There are probably too many receivers out there that have rules like oh, it was submitted via webmail from Nigeria, it's junk. It could be that gmail is actually better at detecting spam than just applying blanket blocks to entire countries, and these 'random blocking based on submitting IP' occurred more often than outgoing spam was getting through the gmail defenses. So, it was a source of queries to the gmail support department that was easily 'fixed' (do they even have a support dpt? I dunno...) Generally speaking, between an X client and an X server, or between an SSH client and an SSH server, there is not an interface between two administrative domains. So apart from the fact that the SMTP gateway *cannot* report the client's IP, there's *no need* for it to do so. (If people started offering public-access Pine-over-SSH or public-access Thunderbird-over-X, I would change my position.) We offer just that (well, pine/mutt over ssh), at least, it requires that you sign up for a monthly fee. Do note that although all of our customers get this ability for free, only about 1% ever use it. Our pine/mutt installations do not include an X-SSH-Connected-from: header :) It's not whimsical at all. Google is suppressing critical information showing the flow of email from one administrative domain to another. How so? It's being sent by a gmail subscriber, via the gmail system. Seems like the same domain to me :) (OK, I admit, now I _am_ teasing you, I know what you meant :) I'm sure the information on the submitting IP isn't lost (hah, google and deleting data??!), it's just not publicly available. Google will surely dish up the info if they get abuse complaints. (... or a visit from the feds. Or a request from a big law firm. Or a request from any law enforcement agency anywhere on earth. Even from China or Pakistan.) -- Jan-Pieter Cornet joh...@xs4all.nl People are continuously reinventing the flat tyre. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
Jan-Pieter Cornet wrote: [...] I'm sure the information on the submitting IP isn't lost (hah, google and deleting data??!), it's just not publicly available. Google will surely dish up the info if they get abuse complaints. (... or a visit from the feds. Or a request from a big law firm. Or a request from any law enforcement agency anywhere on earth. Even from China or Pakistan.) Yes, I might buy that argument if Google weren't a free email provider. But it is; spambots can (and do) break CAPTCHAs of free email providers and routinely use them to send spam. And although Google may be pretty good at stopping spam, it's not perfect. I want the originating IP address so I can use it in my decision-making process. xs4all provides services to paying customers, so you at least have some idea of the end-user's identity. Google has none at all. -- David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] GMail (was Re: stripping Received headers based on authentication)
John Nemeth wrote:
} Yep. On one side: The Web browser. On the other side: The rest of
} the Internet. Why is that so hard to understand?
Yes, a web browser, not an MUA of any sort!
Really? Why isn't it an MUA? What part of the definition of an MUA
does composing mail in a Web browser and then hitting send fail to meet?
I've worked with
numerous different e-mail related protocols over the years, but until
now, nobody has tried to convince me that HTTP{,S} has anything to do
with e-mail.
HTTP(S) has everything to do with email if it's used as the protocol to
submit email. In this respect, it's equivalent to MAPI or any other
non-SMTP protocol used for email.
BTW, what's an EGR and how does it work? What's a PCV and how
does it work? The only hint that I'll give is that these don't have
anything to do with computers.
How are they relevant? (I vaguely recall they have something to do
with car engines, but so what?)
[...]
So what, we all know the general state of privacy in the US, i.e.
you have none. The rest of the world generally does a better job.
Google is at least trying.
BS. The privacy claim from Google is absurd. Why do they add a
Received: header for mail submitted via SMTP? If they were serious
about privacy, they wouldn't.
} Here's the thing: Between the Google Webmail server and the client's
} Web browser, there is an interface between two administrative domains.
} Google doesn't own the Web browser (yet!), but it does own the Web
} server.
Yeah, so?
So, unless Google is 100% accurate at detecting spam and 100% pro-active on
following up complaints, hiding this interface hides useful information
from people trying to fight abuse. Google is helping spammers.
} For tracing purposes, it is desirable (I would say mandatory) to track
} the flow of email across this interface.
How do you know they don't? Just because they don't give you the
info, doesn't mean they don't track it.
You can't get that info from Google. Go ahead and try. And Google
lacks the motivation and staff to follow up on every abuse complaint.
So basically, if you receive spam from gmail, you run into a brick wall
trying to do anything about it.
[...]
Nor, is there any need for Gmail to do so. Google is fully
responsible for anything emitted by the Gmail system. If you receive
spam from a Gmail user, report it to Google/Gmail.
What good would that do?
If Google fails to deal with it appropriately that would make Google
a spam friendly entity and a problem. You can then deal with them
on that basis.
Google cannot deal with every complaint appropriately; it simply lacks
the manpower.
There is no need for you to know who the ultimate enduser composing the
e-mail is.
I don't want to know who the ultimate end-user is. I just want to know
the IP address of the machine that injected the email into Google.
It's a valuable of information I can use in my filter.
-- David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
