* nnimap ports and protocols @ 2010-09-30 22:55 Lars Magne Ingebrigtsen 2010-10-01 1:00 ` Daniel Pittman 2010-10-01 15:19 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-09-30 22:55 UTC (permalink / raw) To: ding In the absence of user-specified ports and protocols, would it make sense just to try the likely ones? That is, test (in order): 1) imaps 2) imap + starttls 3) imap -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-09-30 22:55 nnimap ports and protocols Lars Magne Ingebrigtsen @ 2010-10-01 1:00 ` Daniel Pittman 2010-10-01 13:43 ` Ted Zlatanov 2010-10-01 15:19 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 17+ messages in thread From: Daniel Pittman @ 2010-10-01 1:00 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > In the absence of user-specified ports and protocols, would it make sense > just to try the likely ones? You wouldn't be the first person to do it, but watch out for firewalls that eat the SYN packet silently: having Gnus hang for a significant timeout on the first connection attempt would suck. Doing that every time... Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 1:00 ` Daniel Pittman @ 2010-10-01 13:43 ` Ted Zlatanov 2010-10-01 14:52 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 13:43 UTC (permalink / raw) To: ding On Fri, 01 Oct 2010 11:00:13 +1000 Daniel Pittman <daniel@rimspace.net> wrote: DP> Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >> In the absence of user-specified ports and protocols, would it make sense >> just to try the likely ones? DP> You wouldn't be the first person to do it, but watch out for firewalls that DP> eat the SYN packet silently: having Gnus hang for a significant timeout on the DP> first connection attempt would suck. Doing that every time... The nnimap stream parameter should be a list the user can customize, attempted in order. The default can be what Lars listed. Then Gnus can ask the user if they want to customize the nnimap stream parameter when a connection fails. Ted ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 13:43 ` Ted Zlatanov @ 2010-10-01 14:52 ` Ted Zlatanov 0 siblings, 0 replies; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 14:52 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 1297 bytes --] On Fri, 01 Oct 2010 08:43:46 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: TZ> On Fri, 01 Oct 2010 11:00:13 +1000 Daniel Pittman <daniel@rimspace.net> wrote: DP> Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >>> In the absence of user-specified ports and protocols, would it make sense >>> just to try the likely ones? DP> You wouldn't be the first person to do it, but watch out for firewalls that DP> eat the SYN packet silently: having Gnus hang for a significant timeout on the DP> first connection attempt would suck. Doing that every time... TZ> The nnimap stream parameter should be a list the user can customize, TZ> attempted in order. The default can be what Lars listed. TZ> Then Gnus can ask the user if they want to customize the nnimap stream TZ> parameter when a connection fails. Attached is a patch that: 1) has FIXMEs all over 2) removes the dependency on nnimap-shell-program in favor of a more structured nnimap-stream 3) makes nnimap-stream an alist of (stream . helper) where the helper is currently only meaningful for the 'shell stream. I plan to use it for GnuTLS as well. 4) provides a default nnimap-stream that tries ssl, then network, then shell I'm sure this can be done better, but wanted to show how I thought streams should work for nnimap. Ted [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: nnimap-stream.patch --] [-- Type: text/x-diff, Size: 3921 bytes --] diff --git a/lisp/nnimap.el b/lisp/nnimap.el index 70aa573..89fcff2 100644 --- a/lisp/nnimap.el +++ b/lisp/nnimap.el @@ -54,10 +54,17 @@ If nnimap-stream is `ssl', this will default to `imaps'. If not, it will default to `imap'.") -(defvoo nnimap-stream 'ssl +(defvoo nnimap-stream '((ssl . "") + (network . "") + (shell . (if (boundp 'imap-shell-program) + (if (listp imap-shell-program) + (car imap-shell-program) + imap-shell-program) + "ssh %s imapd"))) "How nnimap will talk to the IMAP server. Values are `ssl', `network', `starttls' or `shell'.") +;; FIXME: remove this in favor of nnimap-stream parameters (defvoo nnimap-shell-program (if (boundp 'imap-shell-program) (if (listp imap-shell-program) (car imap-shell-program) @@ -245,12 +252,12 @@ textual parts.") (push (current-buffer) nnimap-process-buffers) (current-buffer))) -(defun nnimap-open-shell-stream (name buffer host port) +(defun nnimap-open-shell-stream (name buffer host port program) (let ((process-connection-type nil)) (start-process name buffer shell-file-name shell-command-switch (format-spec - nnimap-shell-program + program (format-spec-make ?s host ?p port))))) @@ -293,9 +300,13 @@ textual parts.") (let* ((coding-system-for-read 'binary) (coding-system-for-write 'binary) (port nil) + ;; FIXME: this should cycle through the streams and if one fails, offer to customize them + (stream-struct (or (car-safe nnimap-stream) '(starttls . ""))) + (stream (car stream-struct)) + (stream-helper (cdr stream-struct)) (ports (cond - ((eq nnimap-stream 'network) + ((eq stream 'network) (open-network-stream "*nnimap*" (current-buffer) nnimap-address (setq port @@ -304,19 +315,20 @@ textual parts.") "imap" "143")))) '("143" "imap")) - ((eq nnimap-stream 'shell) + ((eq stream 'shell) (nnimap-open-shell-stream "*nnimap*" (current-buffer) nnimap-address - (setq port (or nnimap-server-port "imap"))) + (setq port (or nnimap-server-port "imap")) + stream-helper) '("imap")) - ((eq nnimap-stream 'starttls) + ((eq stream 'starttls) (let ((tls-program (nnimap-extend-tls-programs))) (open-tls-stream "*nnimap*" (current-buffer) nnimap-address (setq port (or nnimap-server-port "imap")) 'starttls)) '("imap")) - ((eq nnimap-stream 'ssl) + ((eq stream 'ssl) (open-tls-stream "*nnimap*" (current-buffer) nnimap-address (setq port @@ -332,7 +344,7 @@ textual parts.") (memq (process-status (nnimap-process nnimap-object)) '(open run)))) (nnheader-report 'nnimap "Unable to contact %s:%s via %s" - nnimap-address port nnimap-stream) + nnimap-address port stream) (gnus-set-process-query-on-exit-flag (nnimap-process nnimap-object) nil) (if (not (setq connection-result (nnimap-wait-for-connection))) (nnheader-report 'nnimap @@ -352,9 +364,9 @@ textual parts.") (push (format "%s" nnimap-server-port) ports)) ;; If this is a STARTTLS-capable server, then sever the ;; connection and start a STARTTLS connection instead. - (when (and (eq nnimap-stream 'network) + (when (and (eq stream 'network) (member "STARTTLS" (nnimap-capabilities nnimap-object))) - (let ((nnimap-stream 'starttls)) + (let ((nnimap-stream '(starttls))) ; FIXME, should be handled with the right nnimap-stream to begin with (let ((tls-process (nnimap-open-connection buffer))) ;; If the STARTTLS connection was successful, we ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-09-30 22:55 nnimap ports and protocols Lars Magne Ingebrigtsen 2010-10-01 1:00 ` Daniel Pittman @ 2010-10-01 15:19 ` Lars Magne Ingebrigtsen 2010-10-01 15:29 ` Frank Schmitt 1 sibling, 1 reply; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-01 15:19 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > That is, test (in order): > > 1) imaps > 2) imap + starttls > 3) imap I started up Mail on my iMac for the first time, just to see what a modern MUA does. It first asked me for my address and my password. Then it tried doing... something based on that address -- I'm guessing it probed for pop3 and imap ports. Then it said it couldn't find anything, and asked me to choose an incoming mail server. It defaulted to pop3, but had three other choices: IMAP, Exchange 2007, and Exchange 2007 IMAP (!). Weird. Anyway, I chose IMAP, and it presented me with a new dialogue saying that the certificate was invalid, so it had contacted the imaps port. (Since the server in question doesn't have an open imap port.) I clicked "continue", and it presented me with an overview of everything, and under the "IMAP" section "ssl encryption" was ticked on. So I'm guessing it probed imaps and then imap, just like my clever plan. And then stored the result. Which reminds me. Stuff like this should be stored. If nnimap has determined that server X is an imaps server, or whatever, then it shouldn't have to probe every time Emacs is run. Does Emacs have any good mechanism for saving data like this? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 15:19 ` Lars Magne Ingebrigtsen @ 2010-10-01 15:29 ` Frank Schmitt 2010-10-01 15:34 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 17+ messages in thread From: Frank Schmitt @ 2010-10-01 15:29 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Which reminds me. Stuff like this should be stored. If nnimap has > determined that server X is an imaps server, or whatever, then it > shouldn't have to probe every time Emacs is run. > > Does Emacs have any good mechanism for saving data like this? I'd use the customize framework. This gives the added benefit of a ready GUI for manually tweaking the saved info. -- Have you ever considered how much text can fit in eighty columns? Given that a signature typically contains up to four lines of text, this space allows you to attach a tremendous amount of valuable information to your messages. Seize the opportunity and don't waste your signature on bullshit that nobody cares about. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 15:29 ` Frank Schmitt @ 2010-10-01 15:34 ` Lars Magne Ingebrigtsen 2010-10-01 15:46 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-01 15:34 UTC (permalink / raw) To: ding Frank Schmitt <ich@frank-schmitt.net> writes: > I'd use the customize framework. This gives the added benefit of a ready > GUI for manually tweaking the saved info. This data wouldn't be variables as such. It'd be, like "connecting to imap server foo is done on port bar using method zot". Does that work in the customize framework? I'm not sure how I would express that... Or to take a different example -- using tls.el to connect to a server. Then it would be nice if we'd tried gnutls-cli once, and saw it fail, and that openssl worked, that we could save that in some way. *scratches head* -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 15:34 ` Lars Magne Ingebrigtsen @ 2010-10-01 15:46 ` Ted Zlatanov 2010-10-01 16:25 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 15:46 UTC (permalink / raw) To: ding On Fri, 01 Oct 2010 17:34:07 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Frank Schmitt <ich@frank-schmitt.net> writes: >> I'd use the customize framework. This gives the added benefit of a ready >> GUI for manually tweaking the saved info. LMI> This data wouldn't be variables as such. It'd be, like "connecting to LMI> imap server foo is done on port bar using method zot". Does that work LMI> in the customize framework? I'm not sure how I would express that... LMI> Or to take a different example -- using tls.el to connect to a server. LMI> Then it would be nice if we'd tried gnutls-cli once, and saw it fail, LMI> and that openssl worked, that we could save that in some way. My example on extending nnimap-stream could handle this (posted earlier this morning in this thread). Another approach is to add a customizeable alist to control this preference. Yet another is to save a "nnimap-stream" token in the netrc file. Ted ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 15:46 ` Ted Zlatanov @ 2010-10-01 16:25 ` Lars Magne Ingebrigtsen 2010-10-01 16:45 ` Ted Zlatanov 2010-10-01 18:18 ` Sivaram Neelakantan 0 siblings, 2 replies; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-01 16:25 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > My example on extending nnimap-stream could handle this (posted earlier > this morning in this thread). Yes, that would work, but I find that variables that have complex syntaxes (and we have enough of them) are something users fiddle with and complain when they break, so if that could be avoided, it would be a plus. > Yet another is to save a "nnimap-stream" token in the netrc file. This is my current idea I had like five minutes ago, so it should be great. :-) To take nnimap-stream as the example: 1) we'd change the default to nil, signalling that we want Gnus to figure it out on its own. If it has a value, then the user has obviously chosen it, which makes the rest of the stuff irrelevant. 2) if it's nil, then we're in DWIM mode. We then call (nnimap-guess-connection-method server). It'd try the stuff we talked about earlier, and return its result. 3) this is saved in a new Gnus/Emacs file, called... er... ~/emacs.d/emacs-memoize, which would have a format like (nnimap connection-method ("imaps" ssl)) one per line, so that the user can edit it by hand, if necessary. The meaning here would be DOMAIN (so that many different packages can use the same mechanism), TOKEN (that has some meaning in that domain), and the VALUE. 4) nnimap would call this with the macro (gnus-memoize 'nnimap 'connection-method (nnimap-guess-connection-method server)) So it's like a normal memoizer, only it saves stuff to a file, too. Does this sound halfway sane? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 16:25 ` Lars Magne Ingebrigtsen @ 2010-10-01 16:45 ` Ted Zlatanov 2010-10-01 18:29 ` Lars Magne Ingebrigtsen 2010-10-01 18:18 ` Sivaram Neelakantan 1 sibling, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 16:45 UTC (permalink / raw) To: ding On Fri, 01 Oct 2010 18:25:42 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> My example on extending nnimap-stream could handle this (posted earlier >> this morning in this thread). LMI> Yes, that would work, but I find that variables that have complex LMI> syntaxes (and we have enough of them) are something users fiddle with LMI> and complain when they break, so if that could be avoided, it would be a LMI> plus. I see. That's reasonable. >> Yet another is to save a "nnimap-stream" token in the netrc file. LMI> This is my current idea I had like five minutes ago, so it should be LMI> great. :-) To take nnimap-stream as the example: LMI> 1) we'd change the default to nil, signalling that we want Gnus to LMI> figure it out on its own. If it has a value, then the user has LMI> obviously chosen it, which makes the rest of the stuff irrelevant. OK. LMI> 2) if it's nil, then we're in DWIM mode. We then call LMI> (nnimap-guess-connection-method server). It'd try the stuff we talked LMI> about earlier, and return its result. LMI> 3) this is saved in a new Gnus/Emacs file, called... er... LMI> ~/emacs.d/emacs-memoize, which would have a format like LMI> (nnimap connection-method ("imaps" ssl)) LMI> one per line, so that the user can edit it by hand, if necessary. The LMI> meaning here would be DOMAIN (so that many different packages can use LMI> the same mechanism), TOKEN (that has some meaning in that domain), and LMI> the VALUE. That seems like a reinvention of the customize facility. We can do a non-interactive customization of `gnus-connection-preferences' for instance and save the result. I think that's better. Also the connection preferences need to be keyed by server name/server address regex with t as the default. LMI> 4) nnimap would call this with the macro LMI> (gnus-memoize 'nnimap 'connection-method LMI> (nnimap-guess-connection-method server)) LMI> So it's like a normal memoizer, only it saves stuff to a file, too. LMI> Does this sound halfway sane? If Customize is inadequate, I would put this in .newsrc.eld, not in a special new file. And I would allow `gnus-connection-preferences' to be a function called with the server name. Ted ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 16:45 ` Ted Zlatanov @ 2010-10-01 18:29 ` Lars Magne Ingebrigtsen 2010-10-01 18:41 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-01 18:29 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > That seems like a reinvention of the customize facility. We can do a > non-interactive customization of `gnus-connection-preferences' for > instance and save the result. I think that's better. That's be a whopping long alist that wouldn't be very understandable to the customize interface. I think... > Also the connection preferences need to be keyed by server name/server > address regex with t as the default. No, it would just store what it decided to do for exactly that server. > If Customize is inadequate, I would put this in .newsrc.eld, not in a > special new file. And I would allow `gnus-connection-preferences' to be > a function called with the server name. It could be stored in the .newsrc.eld, but we'd then have to supply a mode to edit it, because the user will want to clear stuff out. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 18:29 ` Lars Magne Ingebrigtsen @ 2010-10-01 18:41 ` Ted Zlatanov 2010-10-01 18:47 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 18:41 UTC (permalink / raw) To: ding On Fri, 01 Oct 2010 20:29:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> If Customize is inadequate, I would put this in .newsrc.eld, not in a >> special new file. And I would allow `gnus-connection-preferences' to be >> a function called with the server name. LMI> It could be stored in the .newsrc.eld, but we'd then have to supply a LMI> mode to edit it, because the user will want to clear stuff out. That could be mapped in the Server buffer. We already have a standard way of editing forms in Gnus (server edit, topic/group parameter edit, etc.) so this is not a bad way, usability-wise. Ted ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 18:41 ` Ted Zlatanov @ 2010-10-01 18:47 ` Lars Magne Ingebrigtsen 2010-10-01 19:05 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-01 18:47 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > That could be mapped in the Server buffer. We already have a standard > way of editing forms in Gnus (server edit, topic/group parameter edit, > etc.) so this is not a bad way, usability-wise. Yeah, that's true. I think that's the way to go, then. What about questions from the tls layer about "do you want to accept this invalid certificate from the server?" and stuff? If that's to be stored in the server, then open-gnutls-stream should return both the stream and, er, something that says something about this. Perhaps a plist of properties, like :certificate :invalid-but-accepted or something. Or is that a more global thing? "I accept this certificate" sounds a bit more global... and it's user-generated, too. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 18:47 ` Lars Magne Ingebrigtsen @ 2010-10-01 19:05 ` Ted Zlatanov 2010-10-01 19:17 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 19:05 UTC (permalink / raw) To: ding On Fri, 01 Oct 2010 20:47:19 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> That could be mapped in the Server buffer. We already have a standard >> way of editing forms in Gnus (server edit, topic/group parameter edit, >> etc.) so this is not a bad way, usability-wise. LMI> Yeah, that's true. I think that's the way to go, then. LMI> What about questions from the tls layer about "do you want to accept LMI> this invalid certificate from the server?" and stuff? If that's to be LMI> stored in the server, then open-gnutls-stream should return both the LMI> stream and, er, something that says something about this. Perhaps a LMI> plist of properties, like :certificate :invalid-but-accepted or LMI> something. "don't worry about the rilly technical stuff" ;) The GnuTLS layer should handle all of that. Gnus should not know about certificate management; just like passwords or accepting SSH keys, that's completely irrelevant to reading mail. So I think Fgnutls_boot will need work and so on. It's not bad. I may use auth-source.el to store the accepted certificates in a netrc file or in the Secrets API. Ted ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 19:05 ` Ted Zlatanov @ 2010-10-01 19:17 ` Lars Magne Ingebrigtsen 2010-10-01 19:44 ` Ted Zlatanov 0 siblings, 1 reply; 17+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-01 19:17 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > The GnuTLS layer should handle all of that. Gnus should not know about > certificate management; just like passwords or accepting SSH keys, > that's completely irrelevant to reading mail. Yeah, but I was just wondering where the gnutls layer would stash information like that. We certainly don't want the user to be queried about the invalid certificate every time she connects to the IMAP server, so it needs to be saved somewhere. > So I think Fgnutls_boot will need work and so on. It's not bad. I may > use auth-source.el to store the accepted certificates in a netrc file or > in the Secrets API. The netrc file is for Humans, I think. Perhaps you can stash this in Customize? :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 19:17 ` Lars Magne Ingebrigtsen @ 2010-10-01 19:44 ` Ted Zlatanov 0 siblings, 0 replies; 17+ messages in thread From: Ted Zlatanov @ 2010-10-01 19:44 UTC (permalink / raw) To: ding On Fri, 01 Oct 2010 21:17:45 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> The GnuTLS layer should handle all of that. Gnus should not know about >> certificate management; just like passwords or accepting SSH keys, >> that's completely irrelevant to reading mail. LMI> Yeah, but I was just wondering where the gnutls layer would stash LMI> information like that. We certainly don't want the user to be queried LMI> about the invalid certificate every time she connects to the IMAP LMI> server, so it needs to be saved somewhere. >> So I think Fgnutls_boot will need work and so on. It's not bad. I may >> use auth-source.el to store the accepted certificates in a netrc file or >> in the Secrets API. LMI> The netrc file is for Humans, I think. Perhaps you can stash this in LMI> Customize? :-) Maybe. There's also the "trust file" concept which contains accepted certificate authorities as a bundle. Maybe I can create a trust file to contain accepted server certificates. GnuTLS doesn't allow multiple trust files so this may get complicated. I'll ask gnutls-devel. Ted ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: nnimap ports and protocols 2010-10-01 16:25 ` Lars Magne Ingebrigtsen 2010-10-01 16:45 ` Ted Zlatanov @ 2010-10-01 18:18 ` Sivaram Neelakantan 1 sibling, 0 replies; 17+ messages in thread From: Sivaram Neelakantan @ 2010-10-01 18:18 UTC (permalink / raw) To: ding On Fri, Oct 01 2010,Lars Magne Ingebrigtsen Lars Magne Ingebrigtsen wrote: [snipped 23 lines] > 3) this is saved in a new Gnus/Emacs file, called... er... > ~/emacs.d/emacs-memoize, which would have a format like > > (nnimap connection-method ("imaps" ssl)) > > one per line, so that the user can edit it by hand, if necessary. The > meaning here would be DOMAIN (so that many different packages can use > the same mechanism), TOKEN (that has some meaning in that domain), and > the VALUE. > > 4) nnimap would call this with the macro > (gnus-memoize 'nnimap 'connection-method > (nnimap-guess-connection-method server)) > > So it's like a normal memoizer, only it saves stuff to a file, too. > > Does this sound halfway sane? As long as a info message goes into the *Messages* buffer telling the user where it's trying to pick up the last used method/credentials from i.e. the file it read to guess the login method, the approach looks good. There's nothing quite maddening like "smart" choices made mysteriously and you don't know where to root around to fix it. :-) sivaram -- ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-10-01 19:44 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-09-30 22:55 nnimap ports and protocols Lars Magne Ingebrigtsen 2010-10-01 1:00 ` Daniel Pittman 2010-10-01 13:43 ` Ted Zlatanov 2010-10-01 14:52 ` Ted Zlatanov 2010-10-01 15:19 ` Lars Magne Ingebrigtsen 2010-10-01 15:29 ` Frank Schmitt 2010-10-01 15:34 ` Lars Magne Ingebrigtsen 2010-10-01 15:46 ` Ted Zlatanov 2010-10-01 16:25 ` Lars Magne Ingebrigtsen 2010-10-01 16:45 ` Ted Zlatanov 2010-10-01 18:29 ` Lars Magne Ingebrigtsen 2010-10-01 18:41 ` Ted Zlatanov 2010-10-01 18:47 ` Lars Magne Ingebrigtsen 2010-10-01 19:05 ` Ted Zlatanov 2010-10-01 19:17 ` Lars Magne Ingebrigtsen 2010-10-01 19:44 ` Ted Zlatanov 2010-10-01 18:18 ` Sivaram Neelakantan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).