Re: [Dovecot] Detect client application
Yah, thanks! I see HTTP can detect the OS but seems IMAP is new. So there is no way actually -- Regards, Thu NGUYEN > On Fri, 2009-10-16 at 23:17 +0700, Thu NGUYEN wrote: >> Do you have any way to detect the client which is connecting to our IMAP >> server? > > Not in any reliable way. >
Re: [Dovecot] Detect client application
I use the Messaging application on mobile device (which use to check sms also). What I want is open port 143/993 for checking email via IMAP but only allow mobile device to check it. User can configure on their Outlook/Thunderbird... to check mail also but I want to deny this case. -- Regards, Thu NGUYEN > Does the 'mobile device' have an application that supports imap/pop3 > ?, or are you talking about to access via webmail ? > 2009/10/16 Thu NGUYEN : >> >> Hello, >> >> Do you have any way to detect the client which is connecting to our IMAP >> server? >> >> I actually have an mail server which use dovecot but I just want to >> allow >> mobile device access to this server to get email, not desktop as >> Outlook, >> Thunderbird ... >> >> Thanks for your advice. >> >> -- >> Regards, >> Thu NGUYEN >> >> >> >> >
Re: [Dovecot] Wish-list: X-Delivered-To headers generated by dovecot-deliver
On Sat, 2009-10-17 at 23:57 +0200, Andrzej Adam Filip wrote:
> Karsten Bräckelmann wrote:
> > On Sat, 2009-10-17 at 22:41 +0200, Andrzej Adam Filip wrote:
> >> a) *clearly* mark POP/IMAP account fetched by fetchmail
> >>[with fetchmail using directly dovecot-deliver in --mda option]
> >
> > Would the fetchmail tracepolls option not do? It generates a header
> > like this, including local and remote account info.
> >
> > Received: from mail.example.net [192.0.0.1] by local-server with POP3
> >(fetchmail-6.3.4 polling mail.example.net account user) for
> > (single-drop); Sat, 17 Oct 2009 22:42:27 +0200
> > (CEST)
>
> Is there an easy way to use such "tracepoll Received:" in
> 1) sieve scripts?
Dunno.
> 2) procmail scripts?
That's exactly why I originally tracked down the fetchmail tracepolls
option. :)
Easy? Sure, multi-line headers are re-flowed with procmail, so it's a
"single-line" RE for matching. But since we're talking about procmail,
any answer regarding "easy" depends on whom you ask... ;)
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] Wish-list: X-Delivered-To headers generated by dovecot-deliver [a]
Karsten Bräckelmann wrote: > On Sat, 2009-10-17 at 22:41 +0200, Andrzej Adam Filip wrote: >> a) *clearly* mark POP/IMAP account fetched by fetchmail >>[with fetchmail using directly dovecot-deliver in --mda option] > > Would the fetchmail tracepolls option not do? It generates a header > like this, including local and remote account info. > > Received: from mail.example.net [192.0.0.1] by local-server with POP3 >(fetchmail-6.3.4 polling mail.example.net account user) for > (single-drop); Sat, 17 Oct 2009 22:42:27 +0200 > (CEST) Is there an easy way to use such "tracepoll Received:" in 1) sieve scripts? 2) procmail scripts? -- [pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu "I suppose you expect me to talk." "No, Mr. Bond. I expect you to die." -- Goldfinger
Re: [Dovecot] antispam-plugin 1.2 and trailing carriage-returns
*nudge* Anyone? Since Timo seems to be on a list processing spree
lately, here's hoping. :)
On Tue, 2009-09-01 at 22:20 +0200, Karsten Bräckelmann wrote:
> Guys,
>
> Dovecot 1.0.15 [1], just built the latest antispam-plugin 1.2 (tarball)
> for testing, mailtrain backend for SA integration. Both built from
> custom spec files.
>
> The mail that is being trained is different than its respective source
> in the mbox file. The trained one shows added, trailing carriage-return
> chars for all headers, which are not in the headers in the mbox file.
>
> This breaks sa-learn -- both these variations are different, and SA
> would learn *both* when run against each one separately.
>
> How comes? Any insight? How could I fix this, other than wrapping the
> sa-learn inside another shell script and have sed strip off the noise?
> This becomes more of an issue, once I switch from sa-learn to the
> lightning-fast spamc training variant.
>
> TIA
>
> guenther
>
>
> [1] Yes, I know, sorry. Don't want to change everything at the same
> time, and the target system I'm experimenting for runs that version,
> too.
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] Wish-list: X-Delivered-To headers generated by dovecot-deliver
On Sat, 2009-10-17 at 22:41 +0200, Andrzej Adam Filip wrote:
> a) *clearly* mark POP/IMAP account fetched by fetchmail
>[with fetchmail using directly dovecot-deliver in --mda option]
Would the fetchmail tracepolls option not do? It generates a header like
this, including local and remote account info.
Received: from mail.example.net [192.0.0.1] by local-server with POP3
(fetchmail-6.3.4 polling mail.example.net account user) for
(single-drop); Sat, 17 Oct 2009 22:42:27 +0200 (CEST)
--
char *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Dovecot] Wish-list: X-Delivered-To headers generated by dovecot-deliver
Would it be sensible/"cost effective" to make dovecot-deliver generated X-Delivered-To header(s) based on command line parameter(s)? [after striping such existing headers, before consulting sieve] I need it to: a) *clearly* mark POP/IMAP account fetched by fetchmail [with fetchmail using directly dovecot-deliver in --mda option] b) cleanly implement "shared mailboxes" with MTA such as sendmail that can be easily forced to generate "one header per one recipient" [AFAIK] -- [pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann
Re: [Dovecot] Convert to DBox
On 09/30/2009 04:28 AM Jeff Grossman wrote: > I am thinking of trying out dbox format. I am currently using maildir. > Is it possible for me to switch just one user account to dbox while > keeping all of my other users on maildir? If so, how would I go about > doing that? > > Here is a copy of my dovecot -n: > > # 1.2.5: /usr/local/etc/dovecot.conf > # OS: Linux 2.6.30-1-amd64 x86_64 Debian squeeze/sid ext3 > base_dir: /var/run/dovecot/ > protocols: imap imaps pop3 pop3s > ssl_cert_file: /etc/ssl/certs/stikman-godaddy.crt > ssl_key_file: /etc/ssl/private/stikman-godaddy.key > disable_plaintext_auth: no > login_dir: /var/run/dovecot//login > login_executable(default): /usr/local/libexec/dovecot/imap-login > login_executable(imap): /usr/local/libexec/dovecot/imap-login > login_executable(pop3): /usr/local/libexec/dovecot/pop3-login > mail_location: maildir:/home/vmail/%u > mail_executable(default): /usr/local/libexec/dovecot/imap > mail_executable(imap): /usr/local/libexec/dovecot/imap > mail_executable(pop3): /usr/local/libexec/dovecot/pop3 > mail_plugin_dir(default): /usr/local/lib/dovecot/imap > mail_plugin_dir(imap): /usr/local/lib/dovecot/imap > mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 > lda: >postmaster_address: postmas...@stikman.com >mail_plugins: cmusieve >sendmail_path: /usr/sbin/sendmail >auth_socket_path: /var/run/dovecot/auth-master > auth default: >mechanisms: plain login >username_format: %Lu >passdb: > driver: pam >userdb: > driver: passwd > args: uid=vmail gid=vmail home=/home/vmail/%u >socket: > type: listen > master: >path: /var/run/dovecot/auth-master >mode: 384 >user: vmail >group: vmail > plugin: >sieve: sieve > > Thanks, > Jeff You are using pam for authentication. Are your users only 'mail users'? When your users are only 'mail users' throw one of them out of /etc/passwd. In the next step create an additional passwd like file¹ and add the previously dropped user. Finally configure multiple authentication databases² in your dovecot.conf Regards, Pascal -- 1 = http://wiki.dovecot.org/AuthDatabase/PasswdFile 2 = http://wiki.dovecot.org/Authentication/MultipleDatabases -- The trapper recommends today: cafebabe.0929...@localdomain.org
Re: [Dovecot] deliver and stale NFS file handles
Timo Sirainen schrieb: > On Fri, 2009-10-16 at 14:25 +0200, Leon Meßner wrote: >> Oct 16 00:10:42 mail3 dovecot: deliver(user): >> write_full(/home/r/user/.temp.backupmail.22774.d17050a07b2108e8) >> failed: Stale NFS file handle >> >> It nearly never happens with text/plain mails but _very_ >> often when mails have attachments of some different type. This is inside >> a 7.2-RELEASE-p2 FreeBSD jail. The NFS export is mounted from the >> machine that is running the jail. Locking with lockf works. > > It happens with mails that are larger than 128 kB. Then Dovecot creates > a .temp.* file and unlink()s it and tries to keep using it as a > temporary file. I thought this would have worked with all NFS clients, > since at least Linux then renames the file to .nfs.* file and deletes it > automatically.. > > Can you try what happens if you do in your FreeBSD on NFS system: > > touch foo > tail -f foo& > rm -f foo > fg > > Does it complain about stale NFS handle? Yes, it does complain: "tail: (null): Stale NFS file handle" I tried the same on /tmp, which is based on UFS, and it worked. Do you think this is a new FreeBSD bug? And if so, are you going to report it? MfG Christoph signature.asc Description: OpenPGP digital signature
