On 2014-01-30 20:16, RBEmerson wrote:
>
> robin_listas;2620609 Wrote:
>> I find it easier checking with fetchmail.
> Fetchmail brings in the mail waiting in my mail host, and deposits it in
> /var/spool/mail with each user having a file with pending mail in it.
Forget that, it does not matter. You use fetchmail to pull in mail from
outside, but you can also use another fetchmail instance to pull email
from inside. I would create a new user on that server machine (I’ll call
the machine with dovecot “server”), and try fetching email using that
user. With the option “keep” in fetchmail you can run multiple tests.
And with “fetchlimit” you also make those runs short, no need to
download the entire queue.
So yes, you would have the same configuration as now with the “system”
fetchmail placing mail on “/var/spool/mail with each user having a
file with pending mail in it”, as you say.
Another fetchmail, running for a different, local user, could do
something else, for testing. (It would actually put email on
/var/spool/mail/newuser).
>>> BTW, in the conf file, option -location = mbox:/var/spool/mai-l, I
>>> tried mbox and maildir. Neither helped the “no mail waiting” issue.>
>>
>> I use:
>>
>>>
> Code:
> --------------------
> > >
> > mail_location = mbox:~/Mail:INBOX=/var/mail/%u
> >
> --------------------
>>>
>>
>> which covers both “/var/mail/user” in mbox (the default) and “~/Mail”
>> directories on users homes.
> Does dovecot’s -mail_location = mbox:~/Mail:INBOX=/var/mail/%u- resolve
> to looking for a directory or a file?
A file. The mbox file. Actually, the file would be “/var/mail/username”.
But also all files under the directory “/home/username/Mail/”.
Typically, you have on “/var/mail/username” the INBOX folder. Linux mail
client programs (MUA) pick the email from there and put it on
“/home/username/Mail/”. That’s a typical configuration.
For example, I run procmail filters that automatically
distribute emails from the inbox into different folders
on home. Dovecot is configured to see both places.
In your case, I think that the second place would be empty; but
connecting via IMAP while testing things, the imap folders would be
created there.
Imap can be disabled. Or, you can simply block it on the
firewall, so that internally you can test dovecot configuration
with it enabled.
That’s one of the possible configurations. On a server, the main storage
(not the inbox) could be placed on a different directory than “homes”.
It is mainly irrelevant where it is.
>
> Here’s the current set of mail queues in /var/spool/mail:
>
> Code:
> --------------------
>
> samwise /home/system> gotmail
> total 244
> 8799880 drwxrwxrwt 3 root 4096 Jan 29 22:59 .
> 8677459 drwxr-xr-x 14 root 4096 Jan 26 21:19 …
> 8800712 -rw-rw---- 1 users 163727 Jan 30 13:40 chris
> 8800713 -rw------- 1 users 19298 Jan 15 20:16 gunter
> 9064422 drwxrwxrwx 3 users 4096 Jan 29 22:59 .imap
> 8800830 -rw------- 1 users 0 Jan 29 22:59 inbox
> 8800714 -rw------- 1 users 30860 Jan 30 13:43 pavilion
> 8800715 -rw------- 1 users 9505 Jan 30 13:43 system
> 8800716 -rw------- 1 users 5869 Jan 30 13:39 wxsys
>
> --------------------
> (.imap and inbox were added by dovecot)
Notice that “/var/spool/mail” is by default a symlink to “/var/mail”.
The “.inbox” and “.imap” files have probably appeared because you did
not define a location for imap folders. With my suggested config it does
not happen.
I’ll answer here parts from the other thread.
On 2014-01-30 20:06, RBEmerson wrote:
> Went there did that, except /var/spool/mail/%u to match what exists
> already, from qpopper and fetchmail.
Both locations are the same, there is a symlink. Or there should be.
>> /etc/dovecot/conf.d/10-auth.conf
>>
>>>
> Code:
> --------------------
> > >
> > #CER
> > # I used “disable_plaintext_auth = no” initially for use with imapsync.
> > # later I used --ssl1 on imapsync and opening imaps on firewall
> >
> --------------------
>
> Er, no imap here - is this needed?
No. It is just a comment on my config files, a note to myself.
The relevant point for you is that plain text auth is disabled by
default, which means that if the ssl certificates do not work, you can
not connect. So the “no” above temporarily disables this, so that you
can work out the storages first.
> Summarizing, no change to signing in (passwords in the plain work, not
> thing else does), no change to finding mail. I used fetchmail -k to
> bring down the current mail queue, including mail sent from outside, to
> system@pinefields.com. The mail is in system’s queue, but TB doesn’t
> find it, which it did with qpopper.
>
> How does dovecot tie to port 110? I don’t see it with xinetd - which
> still shows pop, pop2, and pop3 with links to the old qpopper-based
> programs.
You have to disable the xinetd parts for qpopper, it could confuse
things. Dovecot is a daemon running full time, it does not show on xinetd.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
