Menu
▾
▴
fetchmail-users
|
From: Marco F. <mfi...@mc...> - 2006-09-27 17:54:42
|
Rob wrote: > > (I'll fix the certificates problem after I've managed to get > > in successfully with plain imap or pop3) > > They may be linked. In which way? My understanding is that, with those settings, secure connection should be tried but, if failing, unsecure one would be used without problems. That's why I wrote what I wrote? Where am I wrong here? > > (note: fetchmail is regularly working on other accounts) > > On this server? If so it points directly to a username/password > mismatch between the server and fetchmail. No, sorry. The remote server runs postfix + dovecot + squirrelmail just fine. Fetchmail runs on my _home_ linux PC: it works fine with other accounts on _other_ servers (all pop3) which I do not administer. Only on this box which I'm setting up myself there is this problem between the home fetchmail and the remote dovecot. I'll try the test and settings you suggested tonight at home and report. In the meantime any feedback (especially to my answers in this message) is greatly appreciated. Ciao, Marco |
|
From: Rob M. <rob...@gm...> - 2006-09-27 18:04:39
|
On 9/27/06, Marco Fioretti <mfi...@mc...> wrote:
>
> In which way? My understanding is that, with those settings, secure
> connection should be tried but, if failing, unsecure one would be used
> without problems. That's why I wrote what I wrote? Where am I wrong here?
I have exactly zero experience of dovecot, so couldn't tell you. Some
POP/IMAP servers however default to requiring SSL for unsecure auth
methods.
> No, sorry. The remote server runs postfix + dovecot + squirrelmail just fine.
> Fetchmail runs on my _home_ linux PC: it works fine with other accounts on _other_
> servers (all pop3) which I do not administer. Only on this box which I'm setting
> up myself there is this problem between the home fetchmail and the remote dovecot.
>
> I'll try the test and settings you suggested tonight at home and report. In the
> meantime any feedback (especially to my answers in this message) is greatly appreciated.
Well, one quick test would be to use any other IMAP/POP client (from
the home linux PC) against the remote server to confirm that the
username/password are correct.
(Note that using squirrelmail doesn't necessarily test the same
connection methods, squirrelmail may be configured to use the loopback
interface, which may have different, eg lower, security settings).
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: M. F. <mfi...@mc...> - 2006-09-30 17:41:30
|
On Wed, Sep 27, 2006 17:04:05 PM +0100, Rob MacGregor (rob...@gm...) wrote: > Well, one quick test would be to use any other IMAP/POP client (from > the home linux PC) against the remote server to confirm that the > username/password are correct. Being too clever for my own good, I have the home computer in such a state, thanks to a lot of experiments, that I cannot install other clients without a lot of work (my fault, yes). However, I have the password stored in the browser, so I don't have to type it every time I check email with squirrelmail. I have looked at what firefox transmits thanks to the live http headers extension. The same password which, sent to squirrelmail via the form, works, doesn't work if I copy it (correcting urlencoding, of course) into the fetchmail script... What else could it be? > (Note that using squirrelmail doesn't necessarily test the same > connection methods, of course, but the password should be the same, shouldn't it? TIA, Marco -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ The biggest problem with communication is the illusion that it has occurred read on Slashdot |
|
From: Rob M. <rob...@gm...> - 2006-09-30 18:39:10
|
On 9/30/06, M. Fioretti <mfi...@mc...> wrote:
> Being too clever for my own good, I have the home computer in such a
> state, thanks to a lot of experiments, that I cannot install other
> clients without a lot of work (my fault, yes). However, I have the
> password stored in the browser, so I don't have to type it every time
> I check email with squirrelmail. I have looked at what firefox
> transmits thanks to the live http headers extension.
>
> The same password which, sent to squirrelmail via the form, works,
> doesn't work if I copy it (correcting urlencoding, of course) into the
> fetchmail script...
>
> What else could it be?
Lots of things, not least being the authentication method used and the
configuration of dovecot.
I should point out that, given that your install of fetchmail works
against other remote servers the problem is almost certainly related
to the configuration of the dovecot server.
> of course, but the password should be the same, shouldn't it?
Yes, but my point is that dovecot does not necessarily accept the
authentication method that fetchmail is trying to use from a remote
host (or even a local one).
I would advise you do the following:
1) Increase the logging level on the dovecot server. That will tell
you why the connection is failing.
2) Install fetchmail locally on the dovecot server. Try doing a mail
check both against localhost and it's external IP.
3) Try any other remote client from the linux box.
At the very least you need to do (1). Until you do that we don't know
why the dovecot server isn't accepting the connections.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2006-09-30 21:31:26
|
"M. Fioretti" <mfi...@mc...> writes: > What else could it be? > >> (Note that using squirrelmail doesn't necessarily test the same >> connection methods, > > of course, but the password should be the same, shouldn't it? That depends on Dovecot configuration and is outside the scope of the fetchmail lists. Anyways, see <http://www.fetchmail.info/fetchmail-FAQ.html#K6> -- Matthias Andree |
|
From: M. F. <mfi...@mc...> - 2006-09-30 22:15:09
|
On Sat, Sep 30, 2006 21:30:52 PM +0200, Matthias Andree (mat...@gm...) wrote: > > of course, but the password should be the same, shouldn't it? > > That depends on Dovecot configuration and is outside the scope of the > fetchmail lists. > Anyways, see <http://www.fetchmail.info/fetchmail-FAQ.html#K6> just tried. sslproto ssl23 doesn't change anything. In any case, I had already signalled the problem both here and on the dovecot list, since I didn't know where to start from and, for all I know, I could have made errors on both sides. Still not sure that that is not the case... Ciao, Marco -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ Needs are a function of what other people have. |
|
From: M. F. <mfi...@mc...> - 2006-09-30 21:58:16
|
On Sat, Sep 30, 2006 17:38:37 PM +0100, Rob MacGregor (rob...@gm...) wrote: > Yes, but my point is that dovecot does not necessarily accept the > authentication method that fetchmail is trying to use from a remote > host (or even a local one). > > I would advise you do the following: > > 1) Increase the logging level on the dovecot server. That will tell > you why the connection is failing. Done, see result below. Comments are welcome. THanks a lot also for suggesting this: > 2) Install fetchmail locally on the dovecot server. Try doing a > mail check both against localhost and it's external IP. I'll do it tomorrow, if still needed (must really leave the keyboard now). Here is the log: Sep 30 15:04:19 fm dovecot: Dovecot v1.0.rc7 starting up Sep 30 15:04:22 fm dovecot: auth(default): passwd-file /etc/dovecot_user_file: Read 1 users Sep 30 15:05:05 fm dovecot: auth(default): client in: AUTH 1 PLAIN service=IMAPsecured lip=::ffff:SERVER_IP_HERE rip=::ffff:CLient_IP_HERE resp=LONG_STRING_HERE VDBB Sep 30 15:05:05 fm dovecot: auth(default): passwd-file(user_name,::ffff:CLIENT_IP_HERE): unknown user Sep 30 15:05:07 fm dovecot: auth(default): client out: FAIL 1 user=user_name Sep 30 15:05:07 fm dovecot: imap-login: Aborted login: user=<user_name>, method=PLAIN, rip=::ffff:CLIENT_IP_HERE, lip=::ffff:SERVER_IP_HERE, TLS TIA, Marco |
|
From: Rob M. <rob...@gm...> - 2006-09-30 22:33:49
|
On 9/30/06, M. Fioretti <mfi...@mc...> wrote:
> Here is the log:
>
> Sep 30 15:04:19 fm dovecot: Dovecot v1.0.rc7 starting up
> Sep 30 15:04:22 fm dovecot: auth(default): passwd-file /etc/dovecot_user_file: Read 1 users
> Sep 30 15:05:05 fm dovecot: auth(default): client in: AUTH 1 PLAIN service=IMAPsecured lip=::ffff:SERVER_IP_HERE rip=::ffff:CLient_IP_HERE resp=LONG_STRING_HERE VDBB
> Sep 30 15:05:05 fm dovecot: auth(default): passwd-file(user_name,::ffff:CLIENT_IP_HERE): unknown user
> Sep 30 15:05:07 fm dovecot: auth(default): client out: FAIL 1 user=user_name
> Sep 30 15:05:07 fm dovecot: imap-login: Aborted login: user=<user_name>, method=PLAIN, rip=::ffff:CLIENT_IP_HERE, lip=::ffff:SERVER_IP_HERE, TLS
Now, repeat with squirrelmail - I suspect you'll ffind either that
squirrelmail isn't using PLAIN, or is but not using TLS. Worth
checking that you've allowed PLAIN in the auth methods for dovecot.
Alternatively, you're authenticating this with SASL and you need to
set the correct domain for authentication.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Michelle K. <lin...@fr...> - 2006-10-02 13:48:00
|
Am 2006-09-30 17:48:49, schrieb M. Fioretti:
> Being too clever for my own good, I have the home computer in such a
> state, thanks to a lot of experiments, that I cannot install other
> clients without a lot of work (my fault, yes). However, I have the
???
I see you are using mutt 1.5.9 so why not try
imaps://you...@se...d
imap://you...@se...d
pop3://you...@se...d
Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
|
|
From: M. F. <mfi...@mc...> - 2006-11-15 19:43:30
|
(sorry everybody for the very late answer, comments below) The problem was that I *could* talk to a dovecot server via webmail but not with fetchmail. no matter which options I passed to it, it always failed as "unknown user or wrong password), even if the password and user name used by procmail were the SAME I used via webmail. On Sun, Oct 01, 2006 23:23:05 PM +0200, Michelle Konzack (lin...@fr...) wrote: > Am 2006-09-30 17:48:49, schrieb M. Fioretti: > > > Being too clever for my own good, I have the home computer in such > > a state, thanks to a lot of experiments, that I cannot install > > other clients without a lot of work (my fault, yes). However, I > > have the > > ??? > > I see you are using mutt 1.5.9 so why not try > > imaps://you...@se...d (me blushing...) because I was sure, in that moment, mutt couldn't do it. Please don't ask why I thought so, let's just say I wasn't sleeping well in those weeks... Anyway: after a few trials with mutt, which worked just fine, I had an inspiration (for lack of a better word): I opened fetchmailrc, canceled ALL the fetchmail "recipe" for downloading the messages and rewrote it from scratch, just as it was before. After that, believe it or not, everything worked. The only way I can explain this is that some weird, non printing character got mixed in the password and /or username strings someway. I hope this helps others to avoid the same waste of time I had :-( Ciao and thanks for your support, Marco Fioretti -- The best way to make everybody love Free Standards and Free Software: http://digifreedom.net/node/73 |
|
From: Matthias A. <mat...@gm...> - 2006-11-16 23:33:05
|
"M. Fioretti" <mfi...@mc...> writes: > Anyway: after a few trials with mutt, which worked just fine, I had an > inspiration (for lack of a better word): I opened fetchmailrc, > canceled ALL the fetchmail "recipe" for downloading the messages and > rewrote it from scratch, just as it was before. After that, believe it > or not, everything worked. > > The only way I can explain this is that some weird, non printing > character got mixed in the password and /or username strings someway. Perhaps. Some "cat" implementations (such as GNU) support options to print nonprinting characters escaped, else "od -An -tc .fetchmailrc" should reveal control characters, and less can also uncover control characters. Oh the wonders of escape sequences and non-printing characters... -- Matthias Andree |
×
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