Gnus + Gmail + IMAP

[Alexander Shukaev]

Hey Everyone,

Just started to move away from using Gmail through the web interface to
Emacs Gnus. I follow Emacs Wiki to achieve this. Here is the
configuration so far:

(setq user-mail-address "*@gmail.com"
user-full-name "*")

(setq gnus-select-method '(nnimap "gmail"
(nnimap-address "imap.gmail.com")
(nnimap-server-port "imaps")
(nnimap-stream ssl)
(nnimap-authinfo-file "~/.authinfo")))

(setq smtpmail-smtp-service 587
gnus-ignored-newsgroups "^to\\.\\|^[0-9. ]+\\(
\\|$\\)\\|^[\"]\"[#'()]")

and

machine imap.gmail.com login *@gmail.com password * port imaps
machine smtp.gmail.com login *@gmail.com password * port 587

When I issue 'M-x gnus RET' I keep getting:

Opening connection to imap.gmail.com via tls...
Unable to open server nnimap+gmail due to: Unknown service: 993
nnimap (gmail) open error: ''. Continue? (y or n) n
Couldn't open server on gmail
Warning: Unable to open server nnimap+gmail due to: Unknown service: 993

...

Opening nnimap server on gmail...
Server nnimap+gmail previously determined to be down; not retrying
Opening nnimap server on gmail...failed:
Checking new news...
Reading active file from gmail via nnimap...
Opening nnimap server on gmail...
Server nnimap+gmail previously determined to be down; not retrying
Opening nnimap server on gmail...failed:
Reading active file via nndraft...done
Checking new news...done
No news is good news
Warning: Opening nnimap server on gmail...failed: ; Server nnimap+gmail
previously determined to be down; not retrying; Opening nnimap server on
gmail...failed: ; Server nnimap+gmail previously determined to be down; not
retrying; Unable to open server nnimap+gmail due to: Unknown service: 993

Does anybody have an idea what could go wrong? Thank you.

Regards,
Alexander

[Jorge A. Alfaro-Murillo]

Alexander Shukaev writes:

> Just started to move away from using Gmail through the web
> interface to Emacs Gnus. I follow Emacs Wiki to achieve this.

Many times emacs wiki has very old information. You can use what
is on the gnus manual:

(setq gnus-select-method '(nnimap "imap.gmail.com"))
(setq smtpmail-default-smtp-server "smtp.gmail.com")

and in ~/.authinfo:

machine imap.gmail.com login <username> password <password> port
imap
machine smtp.gmail.com login <username> password <password> port
587

That should be enough to get and send mail.

--
Jorge.

[Alexander Shukaev]

​Thanks, Jorge,​ but unfortunately I have the same problem.

[Alexander Shukaev]

Alright, so as soon as I added

(setq gnus-select-method '(nnimap "imap.gmail.com"
(nnimap-server-port 993)))

Notice the explicit port 993 (i.e. "imap", "imaps", etc. don't work).
Probably on Windows, one has to add

imaps 993/tcp # IMAP over SSL
imaps 993/udp

to 'c:/WINDOWS/system32/drivers/etc/services'?

Anyway, now I'm getting

Opening connection to imap.gmail.com via tls...

nnimap (imap.gmail.com) open error: 'NO (ALERT) Please log in via your web
browser: https://support.google.com/mail/accounts/answer/78754 (Failure)'.

Continue? (y or n) n

What is that supposed to mean? A problem with credentials?

Kind regards,
Alexander

[Alexander Shukaev]

On Mon, Jun 29, 2015 at 10:26 PM, Alexander Shukaev <haro...@gmail.com>
wrote:

​P.S.: I also got an e-mail from Google:

​
> Hi Alexander,


> We recently blocked a sign-in attempt to your Google Account [
> ​*
> @gmail.com].


​Huh?​

[Ian Zimmerman]

On 2015-06-29 21:25 +0200, Alexander Shukaev wrote:

> Just started to move away from using Gmail through the web interface
> to Emacs Gnus. I follow Emacs Wiki to achieve this.

I don't know if this is your problem, but Gmail won't allow you to use
an IMAP client without jumping through extra hoops. See for example:

http://www.ghacks.net/2014/07/21/gmail-starts-block-less-secure-apps-enable-access/

If you really want to degoogle, I recommend setting up your own
mailserver :-P

--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.

[Jorge A. Alfaro-Murillo]

Ian Zimmerman writes:

> On 2015-06-29 21:25 +0200, Alexander Shukaev wrote:
>
>> Just started to move away from using Gmail through the web
>> interface to Emacs Gnus. I follow Emacs Wiki to achieve this.
>
> I don't know if this is your problem, but Gmail won't allow you
> to use an IMAP client without jumping through extra hoops. See
> for example:
>
> http://www.ghacks.net/2014/07/21/gmail-starts-block-less-secure-apps-enable-access/
>
> If you really want to degoogle, I recommend setting up your own
> mailserver :-P

I use gmail in gnus without a problem. The only thing that I had
to do is to set up an application-specific password
(https://security.google.com/settings/security/apppasswords) but
that is because I use 2-step verification.

--
Jorge.

[Vaidheeswaran C]

If you are on a modern Gnus you can try doing

B

while in the "groups" buffer and use nnimap as the backend. Gnus will
do all the right things for you -- setup authinfo etc etc -- for
recieving of mails.

It will do nothing for your send side. You need to configure smtp
server separately.

Only thing the above interface MUST do (but doens't do right now) is
to "custom save" your user mail address and user name for use in later
sessions. (This is a bug which should be addressed by maintainers).

----------------------------------------------------------------

B runs the command gnus-group-browse-foreign-server (found in
gnus-group-mode-map), which is an interactive compiled Lisp function
in 'gnus-group.el'.

It is bound to B, <menu-bar> <Gnus> <Browse foreign server...>.

(gnus-group-browse-foreign-server METHOD)

Browse a foreign news server.
If called interactively, this function will ask for a select method
(nntp, nnspool, etc.) and a server address (e.g., nntp.some.where).
If not, METHOD should be a list where the first element is the method
and the second element is the address.

[back]






On Tuesday 30 June 2015 12:21 AM, Alexander Shukaev wrote:
> Hey Everyone,

>
> Just started to move away from using Gmail through the web interface to

> Emacs Gnus. I follow Emacs Wiki to achieve this. Here is the
> configuration so far:
>
> (setq user-mail-address "*@gmail.com"
> user-full-name "*")
>
> (setq gnus-select-method '(nnimap "gmail"
> (nnimap-address "imap.gmail.com")
> (nnimap-server-port "imaps")
> (nnimap-stream ssl)
> (nnimap-authinfo-file "~/.authinfo")))
>
> (setq smtpmail-smtp-service 587
> gnus-ignored-newsgroups "^to\\.\\|^[0-9. ]+\\(
> \\|$\\)\\|^[\"]\"[#'()]")
>
> and
>
> machine imap.gmail.com login *@gmail.com password * port imaps
> machine smtp.gmail.com login *@gmail.com password * port 587
>

> When I issue 'M-x gnus RET' I keep getting:

>
> Opening connection to imap.gmail.com via tls...

[Alexander Shukaev]

On Mon, Jun 29, 2015 at 10:59 PM, Ian Zimmerman <i...@buug.org> wrote:

> On 2015-06-29 21:25 +0200, Alexander Shukaev wrote:
>

> > Just started to move away from using Gmail through the web interface
> > to Emacs Gnus. I follow Emacs Wiki to achieve this.
>

> I don't know if this is your problem, but Gmail won't allow you to use
> an IMAP client without jumping through extra hoops. See for example:
>
>
> http://www.ghacks.net/2014/07/21/gmail-starts-block-less-secure-apps-enable-access/

​Hey Ian,

The link appears to be broken. ​

​

>
> If you really want to degoogle, I recommend setting up your own
> mailserver :-P
>
​

That's exactly what I want to do in the future perspective. However, I
have never done this before and I have no idea what software/hardware to
take for this (private home e-mail server). Ideally, I would like to ask
for help on this topic also on this Emacs mailing list because there are
seems to be tons of experts here with diverse background and experience who
might know how to set up all this. I've also read somewhere that it might
be challenging to maintain the server in such a way that it wouldn't end up
in the blacklists.

Concerning the problem: I've tried today again and I keep receiving

Opening connection to imap.gmail.com via tls...

nnimap (imap.gmail.com) open error: 'NO (ALERT) Please log in via your web

browser: https://support.google.com/mail/accounts/answer/78754 (Failure)'.

Continue? (y or n) n

Regards,
Alexander

[Alexander Shukaev]

>
> As mentioned by Jorge, if you have two step authentication enabled in
> googl;e, you need an appilt=cation password to use imap. Some info can
> be found at [1].
>

​I don't have 2-step authentication.​


> Concerning the blocking: I guess google blocked this attempt, because
> you tried to often in a time? Otherwise there are more hints in the
> email.
>

I also thought so yesterday, but trying it again today delivers again the
same error:

​​Opening connection to imap.gmail.com via tls...
nnimap (imap.gmail.com) open error: 'NO (ALERT) Please log in via your web
browser: https://support.google.com/mail/accounts/answer/78754 (Failure)'.
Continue? (y or n) n

> I am by the way using offlineimap to sync my gmail to a local dovecot
> imap server which I access from gnus. Works perfectly.
>

​I remember that a year ago (or so) I've tried using `mu4e' with
'offlineimap​' + Gmail and it also worked fine. That's why I'm confused
why it does not work now with Emacs built-ins.


> Cheers,
>
> Rainer
>

​Regards,
Alexander​


> Footnotes:
> [1] https://support.google.com/mail/answer/1173270?hl=en
>

[Alexander Shukaev]

​Sigh, that Gooooogle...

To bypass that error I had to [1] and [2].

I can now verify that the connection takes place, but there is still a
problem. It is now stuck on the splash screen of Gnus with the message:

Opening connection to imap.gmail.com...done

And in the process manager, I can only see that the memory consumption of
the Emacs process is consistently rising. Any ideas?

[1] https://www.google.com/accounts/DisplayUnlockCaptcha
​[2] https://www.google.com/settings/security/lesssecureapps

[Alberto Luaces]

Alexander Shukaev <haro...@gmail.com> writes:

> Concerning the problem: I've tried today again and I keep receiving
>

> Opening connection to imap.gmail.com via tls...
> nnimap (imap.gmail.com) open error: 'NO (ALERT) Please log in via your web
> browser: https://support.google.com/mail/accounts/answer/78754 (Failure)'.
> Continue? (y or n) n

You really should follow that link and read the "allow less secure apps
access" paragraph —the answer is just there.

--
Alberto

[Alexander Shukaev]

​As it turned out that is only part of the solution. Read my previous
post: you have to disable Captchas as well.​

[Alexander Shukaev]

​I have no idea what to do now. It logs me in but then it is simply stuck
at

Reading active file from imap.gmail.com via nnimap...​

[Jorge A. Alfaro-Murillo]

Alexander Shukaev writes:

> ​I have no idea what to do now.

Have you try to use
https://security.google.com/settings/security/apppasswords to do a
separate password just for emacs?

--
Jorge.

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 13:14:04 +0200
> From: Alexander Shukaev <haro...@gmail.com>

>
> I can now verify that the connection takes place, but there is still a
> problem. It is now stuck on the splash screen of Gnus with the message:
>
> Opening connection to imap.gmail.com...done
>
> And in the process manager, I can only see that the memory consumption of
> the Emacs process is consistently rising. Any ideas?

Are you sure it is stuck, and not just reading a lot of stuff? How
much time did you wait?

If you waited long enough, attach a debugger and tell us where Emacs
is looping, and what does it need that memory for. That should give
some clue to the nature of the problem.

[Alexander Shukaev]

​I've waited for say 30 minutes. I can't believe that it's that much stuff
to download. I've also tried with

(setq gnus-newsgroup-maximum-articles 1)

and the result is the same. To debug, would I need to build the debug
version of Emacs? Or you mean debug some Lisp function? If yes, then
which one? `gnus'? If you mean GDB, then again, what exactly should I
look for?

Regards,
Alexander​

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 17:57:48 +0200
> From: Alexander Shukaev <haro...@gmail.com>
> Cc: help-gnu-emacs <help-gn...@gnu.org>

>
> To debug, would I need to build the debug version of Emacs?

If your binary is not stripped (you can know by its size -- an
unstripped binary should be around 60 or 70 MB), then you already have
a debug version.

> If you mean GDB, then again, what exactly should I look for?

Start with the backtrace. That is (EMACS-PID is the process ID of
Emacs, you can see it in the Task manager or by running pslist):

gdb -p EMACS-PID
(gdb) source /path/to/.gdbinit
(gdb) thread 1
(gdb) bt

The .gdbinit file comes with the sources. If you don't have the
source tree that corresponds to your binary, you can download .gdbinit
from the Git repo:

http://git.savannah.gnu.org/cgit/emacs.git/tree/src/.gdbinit

Then look at the output of "bt".

Btw, it is best to post all that as a bug report.

[Alexander Shukaev]

My Emacs is only 25 MB, but I can rebuild it. Which build parameters do
you recommend?

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 18:28:29 +0200

> From: Alexander Shukaev <haro...@gmail.com>
> Cc: help-gnu-emacs <help-gn...@gnu.org>
>

> My Emacs is only 25 MB, but I can rebuild it. Which build parameters do you
> recommend?

CFLAGS='-O0 -gdwarf-4 -g3' ./configure ... --enable-checking='yes,glyphs'

(I assume your GCC is at least 4.8.x, so it should support -gdwarf-4.)
Replace "..." with whatever you usually put on the configure command
line, but omit any options that contradict with those I show
explicitly.

[Alexander Shukaev]

>
> CFLAGS='-O0 -gdwarf-4 -g3' ./configure ... --enable-checking='yes,glyphs'
>
> (I assume your GCC is at least 4.8.x, so it should support -gdwarf-4.)
> Replace "..." with whatever you usually put on the configure command
> line, but omit any options that contradict with those I show
> explicitly.
>
>

​I'm building 64-bit one, so DWARF is not available in this case. SEH
would be used instead.​

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 18:49:00 +0200

> From: Alexander Shukaev <haro...@gmail.com>
> Cc: help-gnu-emacs <help-gn...@gnu.org>
>

I think you are confusing between the debug info and the method used
to pass exceptions across shared libraries. The latter indeed cannot
use DWARF unwinders, but this issue is of no importance to us in this
context.

The DWARF debug info is certainly supported on x86_64. It's even the
default, but -gdwarf-4 makes GCC use more recent version of the DWARF
standard, that produces more elaborate debug information.

[Alexander Shukaev]

​So strange... I've just built with the parameters that you said and the
executable is only 27 MB. GDB also says:

Reading symbols from ...\bin\emacs.exe...(no debugging symbols
found)...done.​

Furthermore,

(gdb) source ../../../src/emacs/src/.gdbinit
../../../src/emacs/src/.gdbinit:19: Error in sourced command file:
No symbol table is loaded. Use the "file" command.

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 19:45:14 +0200

> From: Alexander Shukaev <haro...@gmail.com>
> Cc: help-gnu-emacs <help-gn...@gnu.org>
>

> ​So strange... I've just built with the parameters that you said and the
> executable is only 27 MB. GDB also says:
>
> Reading symbols from ...\bin\emacs.exe...(no debugging symbols found)...done.​

That "bin\" part means you installed the binary. I suspect that the
installation procedure strips the symbols. Use the emacs.exe in src/
directory, it should be unstripped.

[Alexander Shukaev]

God damn it. I don't know if you remember my post from yesterday where I
was talking which hooks to attach `minibuffer-line--update' to in order to
update minibuffer line on window and buffer switches properly. The
conclusion was

(add-hook 'buffer-list-update-hook #'minibuffer-line--update)
(add-hook 'window-configuration-change-hook #'minibuffer-line--update)

By examining the GDB output (which obviously repeats):

#1084 0x00000004001f0978 in run_hook_with_args (nargs=1, args=0x7a8d40,
funcall=0x4001f0434 <funcall_nil>) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2529
#1085 0x00000004001f04e2 in Frun_hook_with_args (nargs=1, args=0x7a8d40) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2390
#1086 0x00000004001f0a0a in run_hook (hook=-17119289912) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2543
#1087 0x00000004001f049c in Frun_hooks (nargs=1, args=0x7a8e88) at
C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2372

I've somehow recalled those hooks. It turns out that this one

(add-hook 'buffer-list-update-hook #'minibuffer-line--update)

is seems to be causing the infinite recursion and most importantly only in
the case of `M-x gnus RET' as I haven't experienced that before. What
could be the problem here, Eli?

P.S.: As soon as I commented this hook, my Gmail got synchronized
instantly, so that's not a Gmail issue anymore.

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 21:10:44 +0200

> From: Alexander Shukaev <haro...@gmail.com>
> Cc: help-gnu-emacs <help-gn...@gnu.org>
>

> God damn it. I don't know if you remember my post from yesterday where I was
> talking which hooks to attach `minibuffer-line--update' to in order to update
> minibuffer line on window and buffer switches properly. The conclusion was
>
> (add-hook 'buffer-list-update-hook #'minibuffer-line--update)
> (add-hook 'window-configuration-change-hook #'minibuffer-line--update)
>
> By examining the GDB output (which obviously repeats):
>
> #1084 0x00000004001f0978 in run_hook_with_args (nargs=1, args=0x7a8d40,
> funcall=0x4001f0434 <funcall_nil>) at
> C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2529
> #1085 0x00000004001f04e2 in Frun_hook_with_args (nargs=1, args=0x7a8d40) at
> C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2390
> #1086 0x00000004001f0a0a in run_hook (hook=-17119289912) at
> C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2543
> #1087 0x00000004001f049c in Frun_hooks (nargs=1, args=0x7a8e88) at
> C:/Users/Haroogan/Projects/GitHub/MINGW-packages/mingw-w64-emacs-git/src/emacs/src/eval.c:2372
>
> I've somehow recalled those hooks. It turns out that this one
>
> (add-hook 'buffer-list-update-hook #'minibuffer-line--update)
>
> is seems to be causing the infinite recursion and most importantly only in the
> case of `M-x gnus RET' as I haven't experienced that before.

Yes, the recursion is clearly visible in the Lisp backtrace.

> What could be the problem here, Eli?

I think this part of the Lisp backtrace should give you a clue:

"format-time-string" (0x8318d0)
"propertize" (0x831b18)
"let*" (0x831d68)
"eval" (0x831fc8)
"format-mode-line" (0x833810)
"minibuffer-line--update" (0x833e88)
"run-hooks" (0x833fc8)
"format-time-string" (0x8356a0)
"propertize" (0x8358e8)
"let*" (0x835b38)
"eval" (0x835d98)
"format-mode-line" (0x8375e0)
"minibuffer-line--update" (0x837c58)
"run-hooks" (0x837d98)
"utf-7-imap-post-read-conversion" (0x839ce8)
"decode-coding-string" (0x83a380)
"utf7-decode" (0x83a8d0)
"nnimap-get-groups" (0x83ae40)
"nnimap-request-newgroups" (0x83b3b0)
"gnus-request-newgroups" (0x83b920)
"gnus-ask-server-for-new-groups" (0x83be90)

Somehow, minibuffer-line--update calls format-mode-line, which calls
format-time-string, which again calls run-hooks, which again calls
minibuffer-line--update. Look into your hook and see how this can
happen.

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 23:04:09 +0300
> From: Eli Zaretskii <el...@gnu.org>

>
> Somehow, minibuffer-line--update calls format-mode-line, which calls
> format-time-string, which again calls run-hooks, which again calls
> minibuffer-line--update. Look into your hook and see how this can
> happen.

I think I know the answer: format-time-string uses a temporary buffer,
which is then killed when no longer needed. That call to kill-buffer
invokes your buffer-list-update-hook again, thus the infinite
recursion.

I think you need to modify your buffer-list-update-hook to ignore
temporary buffers, those whose names begin with a space.

[Alexander Shukaev]

​If that is the case, then why when I simply select some other window via
`select-window', which also runs the ​`​buffer-list-update-hook', which (1)
runs the `​format-time-string' for `minibuffer-line', (2) runs
`format-mode-line' for `minibuffer-line', the recursion does not happen?

I've also tried to run `​format-time-string' manually just now and it
didn't entail recursion on its own.

[Jude DaShiell]

Is it possible to get gmail with gnus without lowering security
protections on a gmail account? I sure couldn't do it with fetchmail.

On Tue, 30 Jun 2015, Eli Zaretskii wrote:

> Date: Tue, 30 Jun 2015 16:04:09
> From: Eli Zaretskii <el...@gnu.org>
> To: help-gn...@gnu.org
> Subject: Re: Gnus + Gmail + IMAP

> Somehow, minibuffer-line--update calls format-mode-line, which calls
> format-time-string, which again calls run-hooks, which again calls
> minibuffer-line--update. Look into your hook and see how this can
> happen.
>
>

--

[Jorge A. Alfaro-Murillo]

Jude DaShiell writes:

> Is it possible to get gmail with gnus without lowering security
> protections on a gmail account?

Why do you have to lower your security? Create an app specific
password in google for gnus only
(https://support.google.com/accounts/answer/185833?hl=en) , and
save it in your encrypted ~/.authinfo.gpg. Keep two step
verification for the rest
(https://support.google.com/accounts/answer/180744).

--
Jorge.

[Eli Zaretskii]

> Date: Tue, 30 Jun 2015 22:45:39 +0200

> From: Alexander Shukaev <haro...@gmail.com>
> Cc: help-gnu-emacs <help-gn...@gnu.org>
>

> I think I know the answer:
> ​​
> format-time-string uses a temporary buffer,
> which is then killed when no longer needed. That call to kill-buffer
> invokes your buffer-list-update-hook again, thus the infinite
> recursion.
>
> I think you need to modify your
> ​​
> buffer-list-update-hook to ignore
> temporary buffers, those whose names begin with a space.
>
>
>
> ​If that is the case, then why when I simply select some other window via
> `select-window', which also runs the ​`​buffer-list-update-hook', which (1) runs
> the `​format-time-string' for `minibuffer-line', (2) runs `format-mode-line' for
> `minibuffer-line', the recursion does not happen?

Are you sure format-time-string is run in that case?

And calling select-window runs a different hook, doesn't it?

Anyway, do I really have to explain everything? isn't it enough to
suggest a solution (assuming it is a solution)?

> I've also tried to run `​format-time-string' manually just now and it didn't
> entail recursion on its own.

That's expected, since format-time-string needs to run as part of your
hook, not interactively, otherwise the recursion won't happen.

[J. David Boyd]

Alexander Shukaev <haro...@gmail.com> writes:

> Hey Everyone,

>
> Just started to move away from using Gmail through the web interface to

> Emacs Gnus. I follow Emacs Wiki to achieve this. Here is the
> configuration so far:
>
> (setq user-mail-address "*@gmail.com"
> user-full-name "*")
>
> (setq gnus-select-method '(nnimap "gmail"
> (nnimap-address "imap.gmail.com")
> (nnimap-server-port "imaps")
> (nnimap-stream ssl)
> (nnimap-authinfo-file "~/.authinfo")))
>
> (setq smtpmail-smtp-service 587
> gnus-ignored-newsgroups "^to\\.\\|^[0-9. ]+\\(
> \\|$\\)\\|^[\"]\"[#'()]")
>
> and
>
> machine imap.gmail.com login *@gmail.com password * port imaps
> machine smtp.gmail.com login *@gmail.com password * port 587
>
> When I issue 'M-x gnus RET' I keep getting:
>

> Opening connection to imap.gmail.com via tls...

> Unable to open server nnimap+gmail due to: Unknown service: 993
> nnimap (gmail) open error: ''. Continue? (y or n) n
> Couldn't open server on gmail
> Warning: Unable to open server nnimap+gmail due to: Unknown service: 993
>
> ...
>
> Opening nnimap server on gmail...
> Server nnimap+gmail previously determined to be down; not retrying
> Opening nnimap server on gmail...failed:
> Checking new news...
> Reading active file from gmail via nnimap...
> Opening nnimap server on gmail...
> Server nnimap+gmail previously determined to be down; not retrying
> Opening nnimap server on gmail...failed:
> Reading active file via nndraft...done
> Checking new news...done
> No news is good news
> Warning: Opening nnimap server on gmail...failed: ; Server nnimap+gmail
> previously determined to be down; not retrying; Opening nnimap server on
> gmail...failed: ; Server nnimap+gmail previously determined to be down; not
> retrying; Unable to open server nnimap+gmail due to: Unknown service: 993
>
> Does anybody have an idea what could go wrong? Thank you.
>
> Regards,
> Alexander

Are you doing that is from work or home? Here at work, most ports other than
htm, ssh, and ftp are blocked incoming and outgoing. Sucks, but that's what
happens.

Dave in Hudson, FL

[Ruben Maher]

Alexander Shukaev <haro...@gmail.com> writes:
> (setq gnus-select-method '(nnimap "gmail"
> (nnimap-address "imap.gmail.com")
> (nnimap-server-port "imaps")
> (nnimap-stream ssl)
> (nnimap-authinfo-file "~/.authinfo")))

The first argument to nnimap should be the url of the server, try:

(setq gnus-select-method
'(nnimap "imap.gmail.com"

[Ian Zimmerman]

On 2015-07-08 05:47 +0930, Ruben Maher wrote:

> The first argument to nnimap should be the url of the server, try:
>
> (setq gnus-select-method
> '(nnimap "imap.gmail.com"
> (nnimap-address "imap.gmail.com")
> (nnimap-server-port "imaps")
> (nnimap-stream ssl)
> (nnimap-authinfo-file "~/.authinfo")))

I haven't used Gnus for a long time, but AFAICR the argument of any
server type other than nntp is ignored.

I think the OP is correct in assuming his problems are specific to
Gmail. I also have more conjectures regarding the problems, but others
have already jumped in with better understanding than mine, so I'll keep
quiet about that for now.

--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.