Menu
▾
▴
fetchmail-users
|
From: Charles L. <cha...@gm...> - 2005-08-14 15:16:22
Attachments:
gmail-pop-howto.html
|
Hello. I wrote a web page fragment entitled "Configuring your incoming email client: fetchmail" with the intent of submitting it for inclusion on the Gmail Help Center's POP section at <http://mail.google.com/support/bin/topic.py?topic=194>. The Gmail Help Center currently lacks such an item and fetchmail configuration can be more involved than that of other email clients, especially when OpenSSL configuration is taken into full account. So far, I have simply been brushed off by the "Gmail Team" <gma...@go...> with a generic scripted answer stating that I wouldn't receive a direct human response, at the point when I hadn't even yet submitted my HTML code. This situation might change (as this is a typical level-1 response from a help-desk), but in the mean time, would you be interested in this content? The idea would be to turn it into a "How can I use fetchmail with Gmail's POP3 servers?" fetchmail FAQ answer. I am attaching my original "gmail-pop-howto.html" file to this email message for your consideration. Thanks. |
|
From: Michelle K. <lin...@fr...> - 2005-08-14 15:34:01
Attachments:
signature.pgp
|
The HTML code is broken! Am 2005-08-14 09:16:19, schrieb Charles Levert: > Hello. > > I wrote a web page fragment entitled > "Configuring your incoming email client: fetchmail" > with the intent of submitting it for inclusion > on the Gmail Help Center's POP section at > <http://mail.google.com/support/bin/topic.py?topic=194>. > > The Gmail Help Center currently lacks such an > item and fetchmail configuration can be more > involved than that of other email clients, > especially when OpenSSL configuration is taken > into full account. > > So far, I have simply been brushed off by the > "Gmail Team" <gma...@go...> with a > generic scripted answer stating that I wouldn't > receive a direct human response, at the point > when I hadn't even yet submitted my HTML code. > > This situation might change (as this is a > typical level-1 response from a help-desk), > but in the mean time, would you be interested > in this content? > > The idea would be to turn it into a > "How can I use fetchmail with Gmail's POP3 servers?" > fetchmail FAQ answer. > > I am attaching my original "gmail-pop-howto.html" > file to this email message for your > consideration. > > Thanks. > File "/tmp/gmail-pop-howto.html", line 228, column 0: CDATA terminal not found ------------------------- END OF REPLYED MESSAGE ------------------------- ****************************************************************** * Do not Cc: me, because I am on THIS list, if I write here * * Keine Cc: am mich, bin auf DIESER Liste wenn ich hier schreibe * ****************************************************************** Hello, Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com) |
|
From: Charles L. <cha...@gm...> - 2005-08-14 16:14:12
|
* On Sunday 2005-08-14 at 15:33:58 +0200, Michelle Konzack wrote:
> The HTML code is broken!
First, let's make sure that the file has not
been damaged in transit:
sh$ md5sum gmail-pop-howto.html
f0939d677611ad7579d6d02af9c9fe08 gmail-pop-howto.html
sh$ sha1sum gmail-pop-howto.html
a22910f102afaf001bfbf7a61a7f3ab136fdfd4a gmail-pop-howto.html
I tested the file with W3C's Markup Validation
Service at <http://validator.w3.org/> and got
"This Page Is Valid HTML 4.01 Strict!" as
a response.
I also tested its embedded style sheet
with W3C's CSS Validation Service at
<http://jigsaw.w3.org/css-validator/> and got
"No error or warning found" as a response.
> > File "/tmp/gmail-pop-howto.html", line 228, column 0: CDATA terminal not found
The original file only has 227 lines.
What is the tool you are using that generates
this error?
Could it be this tool that's broken?
Are you using its latest version?
|
|
From: Michelle K. <lin...@fr...> - 2005-08-14 18:31:14
Attachments:
signature.pgp
|
Hi Charles,
Am 2005-08-14 10:14:10, schrieb Charles Levert:
> * On Sunday 2005-08-14 at 15:33:58 +0200, Michelle Konzack wrote:
> > The HTML code is broken!
>
> First, let's make sure that the file has not
> been damaged in transit:
You have send it broken...
> > > File "/tmp/gmail-pop-howto.html", line 228, column 0: CDATA terminal not found
>
> The original file only has 227 lines.
> What is the tool you are using that generates
> this error?
> Could it be this tool that's broken?
> Are you using its latest version?
Yes and your file seems to be:
------------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"
><html lang="en"
><head
><meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"
><title
>Configuring your incoming email client: fetchmail</title
><link rel="author" rev="made" title="Charles Levert"
href="mailto:cha...@gm..."
><style type="text/css"
> body {
color: black;
background-color: white;
}
h1, h2, h3, h4, h5, h6 {
font-family: sans-serif;
color: #006;
}
h1 { text-align: center }
a:link, a:visited { color: blue }
a:active { color: red }
a:hover { background-color: #FF9 }
p, li { font-family: serif }
pre {
margin-left: 3em;
padding: 5px;
font: smaller monospace;
color: #036;
background-color: #CCC;
}
tt, code, samp, kbd, var { color: #036 }</style
></head
><body
><h1
>Configuring your incoming email client: fetchmail</h1
><ol
><li
><p
><a href="http://gmail.google.com/support/bin/answer.py?answer=13273"
>Enable POP in your Gmail account.</a
></p
></li
><li
><p
------------------------------------------------------------------------
which is definitivly broken. Many Webbrowser claims about it.
Better you update your HTML generator.
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/88452356 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: Charles L. <cha...@gm...> - 2005-08-14 23:44:33
|
* On Sunday 2005-08-14 at 18:31:13 +0200, Michelle Konzack wrote:
>
> You have send it broken...
Ok. If it wasn't damaged, then we know it's
not the MUAs or the mail transport system.
> > What is the tool you are using that generates
> > this error?
> > Could it be this tool that's broken?
> > Are you using its latest version?
>
> Yes
But what's the name and specific version of this
tool from which you quoted an error message?
I'd like to be able to duplicate this myself.
> and your file seems to be:
[...]
> which is definitivly broken.
The initial segment you quoted here is indeed
intact compared to the original.
I see nothing that's so obviously broken about
it, whether from an SGML or from an HTML point
of view.
> Many Webbrowser claims about it.
I have tested the following browsers and
they have no problem with it: Firefox 1.0.6,
Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1.
If the problem is at the SGML level, can you
pinpoint a specific SGML production that is not
respected by this code?
<http://www.w3.org/MarkUp/SGML/productions.html>
<ftp://ftp.ifi.uio.no/pub/SGML/productions>
Otherwise, if it's at the HTML level, can you
pinpoint something specific in the DTD (or in
the specification itself) that is not respected
by this code?
<http://www.w3.org/TR/html4/strict.dtd>
<http://www.w3.org/TR/html4/>
> Better you update your HTML generator.
This is handwritten.
Then successfully validated as I described using
online tools.
So I'd like to understand precisely what I am
doing wrong at the standards level, since I am
doing it manually entirely myself.
|
|
From: Ray W. <ray...@in...> - 2005-08-16 08:34:42
|
On Sun, Aug 14, 2005 at 05:44:31PM -0400, Charles Levert wrote: > * On Sunday 2005-08-14 at 18:31:13 +0200, Michelle Konzack wrote: > > > > You have send it broken... > > Ok. If it wasn't damaged, then we know it's > not the MUAs or the mail transport system. > > > > > What is the tool you are using that generates > > > this error? > > > Could it be this tool that's broken? > > > Are you using its latest version? > > > > Yes > > But what's the name and specific version of this > tool from which you quoted an error message? > I'd like to be able to duplicate this myself. > > > > and your file seems to be: > [...] > > which is definitivly broken. > > The initial segment you quoted here is indeed > intact compared to the original. > > I see nothing that's so obviously broken about > it, whether from an SGML or from an HTML point > of view. > > > > Many Webbrowser claims about it. > > I have tested the following browsers and > they have no problem with it: Firefox 1.0.6, > Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1. > > With Konqueror 3.2.3 and Opera 7.5.4 and Mozilla 1.7.5 and Galeon 1.3.18 if I attempt to enlarge the text sufficiently that the text in the shaded regions is legible,the text continues out the right side of the window instead of wrapping or triggering a horizontal scroll bar.This may not be classified as officially broken but is not viable for me. Ray Warren |
|
From: Charles L. <cha...@gm...> - 2005-08-16 10:07:07
|
* On Tuesday 2005-08-16 at 01:34:37 -0500, Ray Warren wrote: > On Sun, Aug 14, 2005 at 05:44:31PM -0400, Charles Levert wrote: > > > I have tested the following browsers and > > they have no problem with it: Firefox 1.0.6, > > Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1. > > With Konqueror 3.2.3 and Opera 7.5.4 and Mozilla 1.7.5 and Galeon 1.3.18 > if I attempt to enlarge the text sufficiently that the text in the > shaded regions is legible,the text continues out the right side of the > window instead of wrapping or triggering a horizontal scroll bar. Wrapping? No! Avoiding it is the whole point of <pre>. It does trigger a horizontal scroll bar, but for the whole page. I have now added a "overflow: auto" for <pre> in the style sheet. My Gecko-based browsers have no problem picking up on it thus triggering a per-<pre> scrollbar when needed, but my older Konqueror doesn't (not with "auto" nor with "scroll"). Can you tell me if your more recent Konqueror is more standard-compliant than mine? Also, is Opera (which I don't have)? <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > This may not be classified as officially broken Indeed, this has nothing to do with SGML or HTML being broken. It has to do with design. > but is not viable for me. As long as you can somehow view the content (i.e., the page at least loads), then this discussion becomes more irrelevant, as all this will have to be retrofitted at some point to match the design used for fetchmail's FAQ anyway. Feedback on the actual content is more relevant for now and would be much appreciated. Thanks. |
|
From: Ray W. <ray...@in...> - 2005-08-17 11:03:43
|
On Tue, Aug 16, 2005 at 04:07:01AM -0400, Charles Levert wrote: > * On Tuesday 2005-08-16 at 01:34:37 -0500, Ray Warren wrote: > > On Sun, Aug 14, 2005 at 05:44:31PM -0400, Charles Levert wrote: > > > > > I have tested the following browsers and > > > they have no problem with it: Firefox 1.0.6, > > > Konqueror 3.1.4, links 0.4.2, and w3m 0.4.1. > > > > With Konqueror 3.2.3 and Opera 7.5.4 and Mozilla 1.7.5 and Galeon 1.3.18 > > if I attempt to enlarge the text sufficiently that the text in the > > shaded regions is legible,the text continues out the right side of the > > window instead of wrapping or triggering a horizontal scroll bar. > > Wrapping? No! > Avoiding it is the whole point of <pre>. > > It does trigger a horizontal scroll bar, but > for the whole page. > > I have now added a "overflow: auto" for <pre> in > the style sheet. My Gecko-based browsers have > no problem picking up on it thus triggering a > per-<pre> scrollbar when needed, but my older > Konqueror doesn't (not with "auto" nor with > "scroll"). > > Can you tell me if your more recent Konqueror > is more standard-compliant than mine? Also, > is Opera (which I don't have)? You can get a copy without a cash outlay if you can deal with a thin advertising bar at the top.It is rated as being very standard compliant. > > <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> This link is not working for me tonight but a horizontal scrollbar would alleviate my biggest problem. > > > This may not be classified as officially broken > > Indeed, this has nothing to do with SGML or HTML > being broken. It has to do with design. > > > > but is not viable for me. > > As long as you can somehow view the content > (i.e., the page at least loads), then this The problem is that at least part of the content is not available.It disappeared off the right side of the window. > > Feedback on the actual content is more relevant > for now and would be much appreciated. True, and if I can read the content I will comment on how useful/relevant it is for me. Thanks. |
|
From: Charles L. <cha...@gm...> - 2005-08-20 01:15:48
|
* On Wednesday 2005-08-17 at 04:03:41 -0500, Ray Warren wrote: > On Tue, Aug 16, 2005 at 04:07:01AM -0400, Charles Levert wrote: > > > Can you tell me if your more recent Konqueror > > is more standard-compliant than mine? Also, > > is Opera (which I don't have)? > > You can get a copy without a cash outlay if you can deal with a thin > advertising bar at the top.It is rated as being very standard compliant. I downloaded Opera 8.02 and it gets this right; my question was specific to this very issue, not about standard compliance in general. Can you still tell me about Konqueror 3.2.3, with respect to this very issue? > > > > <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > > This link is not working for me tonight but a horizontal scrollbar would > alleviate my biggest problem. Very strange. This is on the public internet. The site has not reported any down time in quite a while. > > As long as you can somehow view the content > > (i.e., the page at least loads), then this > > The problem is that at least part of the content is not available.It > disappeared off the right side of the window. You mentioned having tried Mozilla and Opera. These have no problem displaying the whole content with a horizontal scrollbar for the whole page. This very much qualifies as "available", albeit with a minor annoyance, which you can fix by adding overflow: auto; to the pre {} block of the embedded style sheet. Should I post a patch for this one-liner? Should I repost the whole document with just this change? |
|
From: Ray W. <ray...@in...> - 2005-08-20 06:17:10
|
On Fri, Aug 19, 2005 at 07:15:40PM -0400, Charles Levert wrote: > * On Wednesday 2005-08-17 at 04:03:41 -0500, Ray Warren wrote: > > On Tue, Aug 16, 2005 at 04:07:01AM -0400, Charles Levert wrote: > > > > > Can you tell me if your more recent Konqueror > > > is more standard-compliant than mine? Also, > > > is Opera (which I don't have)? > > > > You can get a copy without a cash outlay if you can deal with a thin > > advertising bar at the top.It is rated as being very standard compliant. > > I downloaded Opera 8.02 and it gets this right; > my question was specific to this very issue, > not about standard compliance in general. Possibly I was not clear in describing where the problem showed up.It was not the initial display,but after i zoomed in to enlarge the text enough that I could read it. > > Can you still tell me about Konqueror 3.2.3, > with respect to this very issue? > > > > > > > > <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > > > > This link is not working for me tonight but a horizontal scrollbar would > > alleviate my biggest problem. > > Very strange. This is on the public internet. > The site has not reported any down time in quite a while. I tried again a few minutes ago and the scroll bar that popped up when I zoomed in did allow me to view the entire line at a size I could read > > > > As long as you can somehow view the content > > > (i.e., the page at least loads), then this > > > > The problem is that at least part of the content is not available.It > > disappeared off the right side of the window. > > You mentioned having tried Mozilla and Opera. > These have no problem displaying the whole content > with a horizontal scrollbar for the whole page. I have never had a horizontal scroll bar for the whole page on any of the three browsers,and still do not. > This very much qualifies as "available", > albeit with a minor annoyance, > which you can fix by adding > > overflow: auto; > > to the pre {} block of the embedded style sheet. > > Should I post a patch for this one-liner? > Should I repost the whole document with just this change? The change you have already made is adequate for me to view the document, and it looks interesting,it will be later this weekend before I have time to study it. Ray Warren |
|
From: Jakob H. <jh...@pl...> - 2005-08-15 00:37:46
|
Charles Levert wrote: > I wrote a web page fragment entitled > "Configuring your incoming email client: fetchmail" > with the intent of submitting it for inclusion > on the Gmail Help Center's POP section at > <http://mail.google.com/support/bin/topic.py?topic=194>. Nice done (though I didn't check the exact details). And I didn't see any broken HTML, maybe Michelle received a broken mail. Anyway, would have been better to put the file on some web server and post the link here. But what is so special about gmail that it needs its own documentation? The SSL stuff is really helpful, I had some problems setting this up properly, but not only with gmail. btw, AFAIK fingerprint is only useful if the cert is not signed by a CA. The downside is that is has to be changed if the cert changes (e.g. expired). |
|
From: Charles L. <cha...@gm...> - 2005-08-15 03:14:45
|
* On Monday 2005-08-15 at 00:34:08 +0200, Jakob Hirsch wrote: > > And I didn't see any broken HTML, > maybe Michelle received a broken mail. Maybe it's my peculiar (but still valid) SGML/HTML coding/formatting style that throws some tools off. > Anyway, would have been better to put the file > on some web server and post the link here. I have uploaded it here: <http://download.gna.org/hpr/fetchmail/FAQ/gmail-pop-howto.html> > But what is so special about gmail that it needs its own documentation? Remember, this is the original document I wrote with the Gmail Help Center in mind. I am willing to evolve it for the fetchmail FAQ. Change the Gmail-specific details (such as the URL for Thawte's root certificate bundle) and it can become generic. Although, it could be nice to document how to figure out who the server certificate issuer is in the first place, and to list a few URLs for the most important CAs (such as Thawte and Entrust). > The SSL stuff is really helpful, I had some problems setting this up > properly, but not only with gmail. This is something (configuration of the fetchmail/OpenSSL combination) I had not seen documented in one place anywhere before. This was a big part of my motivation to write this. For instance, my system comes with a /usr/share/ssl/certs/ca-bundle.crt file with all the root certificates one could want, but fetchmail/OpenSSL is unable to use it in this form (i.e., all in a single file). I had to figure out from various sources that: -- you need the root certificate installed alone in its own file for fetchmail's sslcertck to be able to pick it up and do its checking-job; -- you have to run c_rehash to generates the symlinks, because those are the only file names that will be looked up; -- each of these files needs to have a ".pem" extension for c_rehash to pick it up in the first place (".txt" or ".cer" won't do). > btw, AFAIK fingerprint is only useful if the cert is not signed by a CA. That's why I used the word "mitigated", as opposed to a stronger word such as "necessary". It still has some useful value in this case; see below. > The downside is that is has to be changed if the cert changes (e.g. > expired). Without CRL verification, the following scenario is possible. Remember that this is about security, so you either attempt to provide it fully or you don't. -- The old server certificate, which forever remains properly signed by its issuer CA, is revocated (and so is included in the CRL) because its associated private key was compromised. -- The legitimate server starts using a new non-compromised server certificate. -- A man-in-the-middle attacker with the compromised private key pretends to be this server. I.e., it seems from our point-of-view that it has either the IP address or maybe just the domain name of the legitimate server. -- This attacker provides the old server certificate at SSL connection establishment. This server certificate's common name (CN) matches the domain name. This server certificate still is properly signed by its issuer CA (forever). -- We didn't configure fetchmail to verify the server certificate's MD5 signature. -- Fetchmail, as SSL client, cannot do CRL verification and so then fully accepts this form of authentication by the fake server pretending to be the legitimate one. Fetchmail then proceeds to feed (i.e., reveal to) this rogue server the client authentication information using POP3's USER and PASS commands, within the SSL connection. Checking the MD5 signature will at least alert us that the server certificate has changed if we succeed in connecting at least once to the legitimate server after this change. We will still be an unaware victim if (or, as long as) we are _systematically_ man-in-the-middled with the above scenario every single time after the change. The pop.gmail.com server certificate does point to the CRL's URI: <http://crl.thawte.com/ThawteServerCA.crl> In this case, it's a 99978-octet file that is updated every day and that has a sliding 28-day validity period. Fetchmail/OpenSSL doesn't but should download it _after_ the server certificate has been validated (so we know that this URI is dependable) and check the validity of the CRL itself (signature and time period) and the absence of the server certificate in it. Having fetchmail cache the CRL somewhere in /var or in a user-specified directory would also be a possibility. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X