Re: [Dovecot] change inbox dotlock name
Le 9 mai 2013 à 16:28, Chris Saldanha a écrit : Axel Luttgens axelluttg...@swing.be wrote: But I fear I don't understand your problem description. Could you elaborate? Hi Axel, The issue is that the procmail port on FreeBSD doesn't acquire a dotlock when it's the default lock file (/var/mail/username.lock). It prints that it's bypassing the dotlock and just does a lockf() lock after. Hello Chris, I don't know very much about procmail (nor about you setup) but I guess just changing the dotlock file's name would anyway be quite an ugly kludge. Doesn't procmail provide a more detailed message about that dotlock bypass (possibly with increased verbosity)? On the other, should dotlocking really be problematic on FreeBSD, and assuming only procmail and Dovecot access the mailboxes (mbox format, I guess), perhaps could you configure both of them to use lockf only? Axel
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/9/2013 11:05 AM, Charles Marcus wrote: This would be awesome, as we deal with a lot of large attachments, and when people are working from home, it can take many many seconds (even a minute or so for very large attachments depending on their internet connection speed) to send, and then it has to do it all over again to save to sent. Charles have you looked into Thunderbird Filelink? https://support.mozillamessaging.com/en-US/kb/filelink-large-attachments You can use a 3rd party service or your own WebDAV server. Keeps large attachments out of mailbox storage, doesn't save them to Sent Items, moves the file over the wire only once. -- Stan
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
Hey Stephan, On 05/09/2013 11:23 PM, Stephan Bosch wrote: It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. But the main goal for this project is to implement an SMTP submission server with full support for the LEMONADE profile (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it doesn't queue anything; once the client sees a success reply for the message submission, it is already accepted in the actual MTA queue. I have one remark and one question: Remark: Don't forget XCLIENT / XFORWARD support to help the real MTA understand who it's really talking to. Question: Will the new SMTP submission code somehow solve the robustness issues with sieve doing SMTP submission? We talked about it last November. Subject was [Dovecot] Sieve puts incoming message into inbox on any problem with submission_host. Regards Christian smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 2013-05-10 4:41 AM, Stan Hoeppner s...@hardwarefreak.com wrote: On 5/9/2013 11:05 AM, Charles Marcus wrote: This would be awesome, as we deal with a lot of large attachments, and when people are working from home, it can take many many seconds (even a minute or so for very large attachments depending on their internet connection speed) to send, and then it has to do it all over again to save to sent. Charles have you looked into Thunderbird Filelink? https://support.mozillamessaging.com/en-US/kb/filelink-large-attachments You can use a 3rd party service or your own WebDAV server. Keeps large attachments out of mailbox storage, doesn't save them to Sent Items, moves the file over the wire only once. Hi Stan, Thanks for the idea, and yes, I'm aware of filelink. While the idea is nice, it wouldn't fulfill our needs. Our data must be kept private, and while there is the WebDAV extension, its functionality is very basic (files with the same name are overwritten silently, no support for expiring links, etc). But anyway, I don't much like the idea of totally separating attachments from emails, it just feels off to me. Thanks, Charles
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
Am 10.05.2013 12:42, schrieb Charles Marcus: On 2013-05-10 4:41 AM, Stan Hoeppner s...@hardwarefreak.com wrote: On 5/9/2013 11:05 AM, Charles Marcus wrote: This would be awesome, as we deal with a lot of large attachments, and when people are working from home, it can take many many seconds (even a minute or so for very large attachments depending on their internet connection speed) to send, and then it has to do it all over again to save to sent. Charles have you looked into Thunderbird Filelink? https://support.mozillamessaging.com/en-US/kb/filelink-large-attachments You can use a 3rd party service or your own WebDAV server. Keeps large attachments out of mailbox storage, doesn't save them to Sent Items, moves the file over the wire only once. Hi Stan, Thanks for the idea, and yes, I'm aware of filelink. While the idea is nice, it wouldn't fulfill our needs. Our data must be kept private, and while there is the WebDAV extension, its functionality is very basic (files with the same name are overwritten silently, no support for expiring links, etc). But anyway, I don't much like the idea of totally separating attachments from emails, it just feels off to me. Thanks, Charles just a little off topic but may for interest to sombody https://github.com/fincluster/owncloud_mail_attachments Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/10/2013 12:12 PM, Christian Rohmann wrote: Hey Stephan, On 05/09/2013 11:23 PM, Stephan Bosch wrote: It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. But the main goal for this project is to implement an SMTP submission server with full support for the LEMONADE profile (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it doesn't queue anything; once the client sees a success reply for the message submission, it is already accepted in the actual MTA queue. I have one remark and one question: Remark: Don't forget XCLIENT / XFORWARD support to help the real MTA understand who it's really talking to. XCLIENT is already implemented. But, afaik, this is only supported by Postfix. I also noticed a problem with XCLIENT LOGIN=user. Even when that is specified, Postfix doesn't allow relaying for a client authenticated through Dovecot submission. I am still not sure what I am messing up there (I did configure smtp_recipient_restrictions correctly I believe). What is XFORWARD good for? It looks very similar, but focused on dealing with mail filter intermediaries. I don't think this applies here. Question: Will the new SMTP submission code somehow solve the robustness issues with sieve doing SMTP submission? We talked about it last November. Subject was [Dovecot] Sieve puts incoming message into inbox on any problem with submission_host. Probably. I'll keep that in mind when implementing the new SMTP client in lib-smtp. It will also require some changes in the LDA/LMTP handling of temporary delivery failures. This is also a good occasion to finish Sieve ereject support. Regards, Stephan.
[Dovecot] Expunge mailbox from script
Hello, I would like to expunge all mail of a mailbox from a script. What's a good tool to do that? With regards, Paul van der Vlis. -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl/
[Dovecot] Any way to let dovecot block pop3 attempts?
Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. Thanks steve campbell
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
* Stephan Bosch step...@rename-it.nl: On 5/10/2013 12:12 PM, Christian Rohmann wrote: Hey Stephan, On 05/09/2013 11:23 PM, Stephan Bosch wrote: It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. But the main goal for this project is to implement an SMTP submission server with full support for the LEMONADE profile (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it doesn't queue anything; once the client sees a success reply for the message submission, it is already accepted in the actual MTA queue. I have one remark and one question: Remark: Don't forget XCLIENT / XFORWARD support to help the real MTA understand who it's really talking to. XCLIENT is already implemented. But, afaik, this is only supported by Postfix. I also noticed a problem with XCLIENT LOGIN=user. Even when that is specified, Postfix doesn't allow relaying for a client authenticated through Dovecot submission. I am still not sure what I am messing up there (I did configure smtp_recipient_restrictions correctly I believe). What is XFORWARD good for? It looks very similar, but focused on dealing with mail filter intermediaries. I don't think this applies here. It forwards the META data for logging purposes and is useful to create consistent logging. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] search and UTF-8 normalization forms (NFD)
Hello Timo, On Thu, 02 May 2013, Timo Sirainen wrote: IMAP requires using i;unicode-casemap by default, as specified by RFC 5051. Then again, others could be supported as well, and it's not really a requirement that the search can't handle more flexible searches.. Anyway, that's what Dovecot currently has implemented, and I guess it doesn't do what you want it to do. But there is a partial solution for this: http://dovecot.org/patches/2.1/icu-1.2.tar.gz It probably does what you want, but it only works with fts-lucene. I'm trying to test it with the 2.2.1 installation, but have a problem doing so: after seemingly smooth compilation and installation, I get May 10 14:15:18 host dovecot: imap: Error: Module is for different ABI version 2.2.1 (we have 2.2.ABIv0(2.2.1)): /usr/lib/dovecot/modules/lib20_icu_plugin.so May 10 14:15:18 host dovecot: imap: Fatal: Couldn't load required plugins Any idea? Greetings, Lutz
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/10/2013 2:20 PM, Patrick Ben Koetter wrote: * Stephan Bosch step...@rename-it.nl: What is XFORWARD good for? It looks very similar, but focused on dealing with mail filter intermediaries. I don't think this applies here. It forwards the META data for logging purposes and is useful to create consistent logging. I understood as much from: http://www.postfix.org/XFORWARD_README.html But I don't quite understand how this is different from XCLIENT, apart from the SOURCE and IDENT items perhaps. Regards, Stephan.
[Dovecot] SMTP front-end Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
Stephan, On Fri, 10 May 2013, Stephan Bosch wrote: On 5/10/2013 12:12 PM, Christian Rohmann wrote: Hey Stephan, On 05/09/2013 11:23 PM, Stephan Bosch wrote: It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. But the main goal for this project is to implement an SMTP submission server with full support for the LEMONADE profile (https://tools.ietf.org/html/rfc4550). It acts as a proxy server, so it doesn't queue anything; once the client sees a success reply for the message submission, it is already accepted in the actual MTA queue. I have one remark and one question: Remark: Don't forget XCLIENT / XFORWARD support to help the real MTA understand who it's really talking to. XCLIENT is already implemented. But, afaik, this is only supported by Postfix. Exim has the -bs command line option. From spec: -bs This option causes Exim to accept one or more messages by reading SMTP commands on the standard input, and producing SMTP replies on the standard output. SMTP policy controls, as defined in ACLs (see chapter 42) are applied. Some user agents use this interface as a way of passing locally-generated messages to the MTA. In this usage, if the caller of Exim is trusted, or untrusted_set_sender is set, the senders of messages are taken from the SMTP MAIL commands. Otherwise the content of these commands is ignored and the sender is set up as the calling user. Unqualified addresses are automatically qualified using qualify_domain and qualify_recipient, as appropriate, unless the -bnq option is used. The -bs option is also used to run Exim from inetd, as an alternative to using a listening daemon. Exim can distinguish the two cases by checking whether the standard input is a TCP/IP socket. When Exim is called from inetd, the source of the mail is assumed to be remote, and the comments above concerning senders and qualification do not apply. In this situation, Exim behaves in exactly the same way as it does when receiving a message via the listening daemon. Could you implement this interface to a backend server, too? Thanks for your work, regards, Lutz
[Dovecot] Problem with LDA reject message
Hi to all, i have a problem with LDA when users are quota-full. My setup is Vpopmail + dovecot + lda; if i send a messagge internally to a user with quota full i receive correctly a messagge but in the header ( i attacch a snip) From - Fri May 10 14:42:27 2013 X-Mozilla-Status: 0001 X-Mozilla-Status2: X-Mozilla-Keys: Return-Path: @mail.cgilfe.it i receive this strange Return-Path. I the messagge is sent outside other servers reply with this messagge: Subject: failure notice Hi. This is the qmail-send program at mail.cgilfe.it. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. roberta.lu...@filcams.cgil.it: Connected to 80.207.169.234 but sender was rejected. Remote host said: 501 Address Syntax Error in @mail.cgilfe.it this is my .qmail-default file: |/var/qmail/bin/preline -f /usr/local/libexec/dovecot/dovecot-lda -d $EXT@$USER | /home/vpopmail/bin/vdelivermail bounce-no-mailbox Thanks in advance. -- *Davide Marchi* *T*eorema *F*errara *Srl* Via Spronello, 7 - Ferrara - 44121 Tel. *0532783161* Fax. *0532783368* E-m@il: *davide.mar...@mail.cgilfe.it* Skype: *davide.marchi73* Web: *http://www.cgilfe.it* *CONFIDENZIALITA'* *Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in questo messaggio sono riservate ed a uso esclusivo del destinatario/dei destinatari. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene gentilmente comunicazione.* *Per favore, pensa all'ambiente. Stampa questa email solo se necessario.*
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On Friday 10 May 2013 08:17:50 Steve Campbell wrote: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. Hi Steve, We've been using Fail2Ban on our mail proxies for a while without any problem. It may be what you're looking for. Regards, Gilles.
Re: [Dovecot] SMTP front-end Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/10/2013 2:43 PM, Lutz Preßler wrote: Stephan, On Fri, 10 May 2013, Stephan Bosch wrote: Exim has the -bs command line option. From spec: Could you implement this interface to a backend server, too? As long as it talks SMTP, it shouldn't be that difficult to facilitate this. But, what exactly is the benefit of this over a normal TCP connection? Regards, Stephan.
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
* Stephan Bosch step...@rename-it.nl: On 5/10/2013 2:20 PM, Patrick Ben Koetter wrote: * Stephan Bosch step...@rename-it.nl: What is XFORWARD good for? It looks very similar, but focused on dealing with mail filter intermediaries. I don't think this applies here. It forwards the META data for logging purposes and is useful to create consistent logging. I understood as much from: http://www.postfix.org/XFORWARD_README.html But I don't quite understand how this is different from XCLIENT, apart from the SOURCE and IDENT items perhaps. XCLIENT impersonates a client and the SMTP server will act as if the XCLIENT was the real client, e.g. it will apply ACLs and other policies to the XCLIENT personality. XFORWARD will not alter the SMTP server behaviour. The client and message data from XFORWARD will only be used for logging purposes. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On 5/10/2013 8:54 AM, Gilles Chauvin wrote: On Friday 10 May 2013 08:17:50 Steve Campbell wrote: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. Hi Steve, We've been using Fail2Ban on our mail proxies for a while without any problem. It may be what you're looking for. Regards, Gilles. Thanks, But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though. I was hoping there was a file for pop and imap in dovecot similar to the smtp access file in sendmail (which is what I use, BTW) steve
Re: [Dovecot] search and UTF-8 normalization forms (NFD)
Am 02.05.2013 17:53, schrieb Timo Sirainen:
On 25.4.2013, at 16.39, Lutz Preßler lutz.press...@sernet.de wrote:
on a system with dovecot 2.2 I've got a mailbox containing multiple mails
from a person called Krüger, but From: header encoded differently.
Some are encoded in UTF-8 normalization form decomposed (as used by Mac OSX),
that is u and umlaut accent as sperate combined codepoints
instead of one ü:
From: =?utf-8?Q?replaced_Kru=CC=88ger?= krueger@some.domain
Searching within roundcube webmail for krüger as sender
missis this mails.
Roundcube sends (dovecot rawlog):
A0003 UID THREAD REFS UTF-8 ALL HEADER FROM {7+}krüger
Is this supposed to work? Haven't done any more debugging
(other search variants) or read RFCs. As a user I would expect
Unicode equivalence rules be applied (see
http://en.wikipedia.org/wiki/Unicode_equivalence)
IMAP requires using i;unicode-casemap by default, as specified by RFC 5051.
Then again, others could be supported as well, and it's not really a
requirement that the search can't handle more flexible searches.. Anyway,
that's what Dovecot currently has implemented, and I guess it doesn't do what
you want it to do. But there is a partial solution for this:
http://dovecot.org/patches/2.1/icu-1.2.tar.gz
It probably does what you want, but it only works with fts-lucene.
Could you elaborate a bit why you think i;unicode-casemap does not
handle this case?
Is it only applied to the query, but not the header, or vice versa?
It seems to me that Step 2 should map both inputs to LATIN CAPITAL
LETTER U + COMBINING DIAERESIS.
Regards,
Florian
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On Friday 10 May 2013 09:17:28 Steve Campbell wrote: But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though. I was hoping there was a file for pop and imap in dovecot similar to the smtp access file in sendmail (which is what I use, BTW) Yes, Fail2Ban uses iptables. I don't think there is another way (using Dovecot itself) to block a remote host since Fail2Ban is documented on Dovecot' wiki: http://wiki2.dovecot.org/HowTo/Fail2Ban (it looks like one of the best way to achieve this). Gilles. -- = Gilles CHAUVIN Administrateur systèmes Pôle Systèmes Direction de l'informatique des systèmes d'information Université de ROUEN Bat.16-IRESE-B-Place Émile Blondel 76821 MONT-SAINT-AIGNAN CÉDEX Accès: http://goo.gl/cYgtX Tél: 02.35.14.82.92 Fax: 02.35.14.64.64 Accueil DSI: 02.35.14.61.00 Mail fonc: syst...@univ-rouen.fr Mail pers: gilles.chau...@univ-rouen.fr =
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/10/2013 3:02 PM, Patrick Ben Koetter wrote: * Stephan Bosch step...@rename-it.nl: But I don't quite understand how this is different from XCLIENT, apart from the SOURCE and IDENT items perhaps. XCLIENT impersonates a client and the SMTP server will act as if the XCLIENT was the real client, e.g. it will apply ACLs and other policies to the XCLIENT personality. XFORWARD will not alter the SMTP server behaviour. The client and message data from XFORWARD will only be used for logging purposes. Ah. One question: what should I do when the server allows both of these? Or is that impossible? Regards, Stephan.
[Dovecot] SMTP Submission/Proxy server - WAS Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 2013-05-09 5:23 PM, Stephan Bosch step...@rename-it.nl wrote: On 5/9/2013 6:05 PM, Charles Marcus wrote: On 2013-05-09 10:35 AM, Stephan Bosch step...@rename-it.nl wrote: Currently, I'm building an SMTP submission proxy server. Can you elaborate on this? It basically acts as a front-end to your normal MTA. First of all, it provides a convenient way to add SMTP AUTH support to any MTA. Excellent, thanks Stephan. Just to make sure I understand this correctly, basically, this means that if someone needs to provide SASL *client* capability on a postfix+dovecot system - ie, so that postfix can relay certain emails to certain destinations through an alternate relay server that requires SASL based SMTP AUTH - they would no longer need cyrus-sasl to accomplish this? ... and auto-save-to-sent, avoiding the overhead of the 'Copy to Sent' behavior we are currently forced to use where a message is first uploaded when it is sent, then again when it is saved to the sent folder? Depends a bit on what you have in mind. The LEMONADE profile has a forward-without-download scheme for this, using the SMTP BURL extension (https://tools.ietf.org/html/rfc4468) and IMAP CATENATE (https://tools.ietf.org/html/rfc4469) and URLAUTH (https://tools.ietf.org/html/rfc4467). Using CATENATE, the client can combine existing message parts with new text to compose a new message. Using SMTP BURL and IMAP URLAUTH, the SMTP server can access that message directly from the IMAP server without the need for the client to download it first. Some more direct approach is also possible, e.g. let the submission server store the message in the Sent folder implicitly (as Google apparently does). This has a few problems though, mainly that the mail client will have to be configured correctly not to store an additional copy of its own. Unfortunately, there is no standardized method of signalling this from server to client. Google probably filters out the duplicates, we don't really know. Also, which folder does the user use as Sent folder? We could use the IMAP SPECIAL-USE (https://www.ietf.org/rfc/rfc6154.txt) extension to find out. Anyway, adding support for implicitly storing sent messages in the \Sent folder should be easy enough, but it is not a fool-proof solution. Timo was discussing this a while back on the SMTP mailinglist, but people there weren't too enthusiastic about standardizing a feature like this so far. Ok, I agree the main problem would be the possibility of duplicate messages, but I would think with the powerful filtering capabilities of sieve, it should be possible (not sure how easy though) to hard code a filter to watch for and filter/remove/delete any duplicate that the MUA uploads. The LEMONADE profile is rather elaborate and not many clients or servers support it yet. I'm hoping that by providing a chicken, more eggs will follow soon. I like that dovecot is willing to take a chance on being first to support these kinds of enhanced services, but I will say, it is very important that any support for said enhancements be rock-solid. To provide some sort of solution for the short term, I guess I'll just add an optional auto-save-to-sent feature. Sounds great to me, but... In my opinion, because of the ubiquitous nature of MUAs saving messages to a sent folder, having a reliable and low-impact method for automatically filtering/removing/deleting these duplicates out should be a requirement before this feature is considered ready. It will be a big and immediate problem for any installation that chooses to enable this feature, as virtually all MUAs will be configured to save sent messages to a/the sent folder. It will also be an ongoing problem for all installations (existing and new alike), as users add their accounts to new computers, phones, tablets and other devices/MUAs, totally ignoring the instructions from their providers that they no longer need to enable this feature. In fact... after thinking about this some more, I wonder... Would there be some reasonably reliable way to detect when an MUA is uploading/saving messages to the Sent folder, and if so, could the LEMONADE protocol be leveraged to create/send a 'notification' email to that user based on some kind of system template (hard coded? customizable?), informing them that there is no need to do this, and even including a link to a dovecot wiki page explaining how to disable the 'Save copy to Sent folder' feature in common MUAs? Then it would be up to individual SysAdmins to keep the wiki updated with sections for any clients they become aware of that aren't already on the page. Maybe future enhancements could even (try to) detect the MUA client (is this possible to do reliably?), and a direct link to the section of the wiki for that specific client could be provided? Another thing that I know that google is really good at is automatically filtering (I guess they're
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On 05/10/13 08:17 AM, Steve Campbell wrote: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. How about TCP wrappers? http://wiki2.dovecot.org/LoginProcess - Login access check sockets - TCP wrappers support
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On 5/10/2013 6:17 AM, Steve Campbell wrote: But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though. I was hoping there was a file for pop and imap in dovecot similar to the smtp access file in sendmail (which is what I use, BTW) I run both - a border firewall and iptables on individual systems. The border firewall allows or denies traffic to specific systems; for instance, web traffic can go to web servers, but web traffic destined for mail servers is dropped. Local servers also have basic rules like this (mail servers drop all web traffic), but they also have more specific rules, such as the fail2ban abuse detection rules. This is called the belt and suspenders approach to security, and is a good idea. With your current method, if a hacker gains access to one system, they can launch attacks at other systems on the same network which they would not be able to do from outside the network. Belt and suspends mitigates much of that. Just having local iptables, but no border firewall means that a hacker that gains access to a system can disable iptables and use the system to launch attacks at other systems, use the system as a malware repository that is accessed on non-standard ports, etc. Belt and suspenders mitigates this also. If you are able, you should consider running iptables locally on each system. This would then let you run fail2ban, also. FWIW, I also run an invisible IDS at the border and local IDS's that are not so invisible, but that is beyond the scope of your comment. Dem
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On 5/10/2013 8:36 AM, Gilles Chauvin wrote: On Friday 10 May 2013 09:17:28 Steve Campbell wrote: But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though. I was hoping there was a file for pop and imap in dovecot similar to the smtp access file in sendmail (which is what I use, BTW) Yes, Fail2Ban uses iptables. I don't think there is another way (using Dovecot itself) to block a remote host since Fail2Ban is documented on Dovecot' wiki: http://wiki2.dovecot.org/HowTo/Fail2Ban (it looks like one of the best way to achieve this). Gilles. Although Fail2Ban uses iptables by default, it's pretty easy to define a different action, such as the old fashioned but still effective null route the offending IP, or if you build dovecot with tcp wrapper support, Fail2Ban can add the IP to hosts.deny. Of course, you can block with null routes or hosts.deny manually, but better to let the computer do the work. -- Noel Jones
[Dovecot] Remove Return-Path in lda rejection message
Is it possible to remove return-path in dovecot lda rejection? -- *Davide Marchi* *T*eorema *F*errara *Srl* Via Spronello, 7 - Ferrara - 44121 Tel. *0532783161* Fax. *0532783368* E-m@il: *davide.mar...@mail.cgilfe.it* Skype: *davide.marchi73* Web: *http://www.cgilfe.it* *CONFIDENZIALITA'* *Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in questo messaggio sono riservate ed a uso esclusivo del destinatario/dei destinatari. Qualora il messaggio in parola Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo e a non inoltrarlo a terzi, dandocene gentilmente comunicazione.* *Per favore, pensa all'ambiente. Stampa questa email solo se necessario.*
Re: [Dovecot] SMTP Submission/Proxy server - WAS Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 5/10/2013 4:02 PM, Charles Marcus wrote: On 2013-05-09 5:23 PM, Stephan Bosch step...@rename-it.nl wrote: First of all, it provides a convenient way to add SMTP AUTH support to any MTA. Just to make sure I understand this correctly, basically, this means that if someone needs to provide SASL *client* capability on a postfix+dovecot system - ie, so that postfix can relay certain emails to certain destinations through an alternate relay server that requires SASL based SMTP AUTH - they would no longer need cyrus-sasl to accomplish this? Ehhh.. no :) It implements the server-side SMTP AUTH, so that your MTA doesn't have to any more. So the client will authenticate to Dovecot rather than to the regular MTA/MSA. But, again, this is a rather trivial matter and not the main reason for building this proxy. The LEMONADE profile is rather elaborate and not many clients or servers support it yet. I'm hoping that by providing a chicken, more eggs will follow soon. I like that dovecot is willing to take a chance on being first to support these kinds of enhanced services, but I will say, it is very important that any support for said enhancements be rock-solid. What do you mean exactly? To provide some sort of solution for the short term, I guess I'll just add an optional auto-save-to-sent feature. Sounds great to me, but... In my opinion, because of the ubiquitous nature of MUAs saving messages to a sent folder, having a reliable and low-impact method for automatically filtering/removing/deleting these duplicates out should be a requirement before this feature is considered ready. It will be a big and immediate problem for any installation that chooses to enable this feature, as virtually all MUAs will be configured to save sent messages to a/the sent folder. It will also be an ongoing problem for all installations (existing and new alike), as users add their accounts to new computers, phones, tablets and other devices/MUAs, totally ignoring the instructions from their providers that they no longer need to enable this feature. Yes, I agree. In fact... after thinking about this some more, I wonder... Would there be some reasonably reliable way to detect when an MUA is uploading/saving messages to the Sent folder, Hmm, not sure. Do MUAs normally generate the Message-ID header, or is that created by the server? That could be one way to detect the duplicates in the Sent folder. and if so, could the LEMONADE protocol be leveraged to create/send a 'notification' email to that user based on some kind of system template (hard coded? customizable?), informing them that there is no need to do this, and even including a link to a dovecot wiki page explaining how to disable the 'Save copy to Sent folder' feature in common MUAs? Then it would be up to individual SysAdmins to keep the wiki updated with sections for any clients they become aware of that aren't already on the page. Maybe future enhancements could even (try to) detect the MUA client (is this possible to do reliably?), and a direct link to the section of the wiki for that specific client could be provided? Relying on user action doesn't sound like a very appealing solution to me. :) Another thing that I know that google is really good at is automatically filtering (I guess they're deleting?) any and all duplicate emails. I have noticed this when copying a message store from one IMAP server to a gmail account. I had cases where the number of messages in certain folders wasn't the same, and upon investigation, noticed that the original/source in fact had some duplicate messages in certain folders. That is entirely possible. So, maybe you could 'kill two birds with one stone' so to speak. and whatever is done to address the duplicate Sent messages could also be leveraged to address duplicate messages in general? Although I guess it is not the same problem, so maybe not... You mean something like this? http://hg.rename-it.nl/dovecot-2.2-pigeonhole/raw-file/tip/doc/rfc/spec-bosch-sieve-duplicate.txt When the submission service has direct access to the user's mail storage, that is trivial to implement. However, if the submission service is unprivileged, that will be a little more difficult. Are you talking about the difference between dovecot accessing mails with one system user, vs accessing mails with the individual users userID? No, I'd like to be able to run SMTP submission without any direct filesystem access privileges, with e.g. one submission process handing submissions for many clients/users at the same time. For accessing the URLAUTHs there is already a support service in current Dovecot. Something similar could be devised for storing messages to Sent folders in that case. Regards, Stephan.
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
Did you have a look at this? http://wiki2.dovecot.org/Authentication/RestrictAccess On 5/10/2013 5:17 AM, Steve Campbell wrote: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. Thanks steve campbell
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On 5/10/2013 10:05 AM, Oscar del Rio wrote: On 05/10/13 08:17 AM, Steve Campbell wrote: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. How about TCP wrappers? http://wiki2.dovecot.org/LoginProcess - Login access check sockets - TCP wrappers support I use Centos and the default dovecot RPM. I seem to recall there was a way to determine if dovecot was built with --with-libwrap. Can anyone shed light on how to determine this, please? Thanks steve
Re: [Dovecot] Expunge mailbox from script
Have a look here: http://wiki2.dovecot.org/Tools/Doveadm/Expunge On 5/10/2013 5:00 AM, Paul van der Vlis wrote: Hello, I would like to expunge all mail of a mailbox from a script. What's a good tool to do that? With regards, Paul van der Vlis.
Re: [Dovecot] SMTP Submission/Proxy server - WAS Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
On 2013-05-10 10:37 AM, Stephan Bosch step...@rename-it.nl wrote: On 5/10/2013 4:02 PM, Charles Marcus wrote: On 2013-05-09 5:23 PM, Stephan Bosch step...@rename-it.nl wrote: First of all, it provides a convenient way to add SMTP AUTH support to any MTA. Just to make sure I understand this correctly, basically, this means that if someone needs to provide SASL *client* capability on a postfix+dovecot system - ie, so that postfix can relay certain emails to certain destinations through an alternate relay server that requires SASL based SMTP AUTH - they would no longer need cyrus-sasl to accomplish this? Ehhh.. no :) It implements the server-side SMTP AUTH, so that your MTA doesn't have to any more. So the client will authenticate to Dovecot rather than to the regular MTA/MSA. But, again, this is a rather trivial matter and not the main reason for building this proxy. Ok... so, will this make it easier to add client side sasl support to dovecots dovecot-sasl implementation to eliminate the need for postfix+dovecot systems to continue to rely on cyrus-sasl for MTA client side sasl support? The LEMONADE profile is rather elaborate and not many clients or servers support it yet. I'm hoping that by providing a chicken, more eggs will follow soon. I like that dovecot is willing to take a chance on being first to support these kinds of enhanced services, but I will say, it is very important that any support for said enhancements be rock-solid. What do you mean exactly? Sorry - was referring mainly to my later comments about how to implement the Save-To-Sent folder stuff... Would there be some reasonably reliable way to detect when an MUA is uploading/saving messages to the Sent folder, Hmm, not sure. Do MUAs normally generate the Message-ID header, or is that created by the server? That could be one way to detect the duplicates in the Sent folder. Sorry, I have no idea... but... Maybe this feature could simply require the use of the dovecot submission server, so all you'd have to do is figure out how to best let the submission server handle it. Maybe have it add a custom ID header that is later removed? Or maybe even not removed? and if so, could the LEMONADE protocol be leveraged to create/send a 'notification' email to that user based on some kind of system template (hard coded? customizable?), informing them that there is no need to do this, and even including a link to a dovecot wiki page explaining how to disable the 'Save copy to Sent folder' feature in common MUAs? Then it would be up to individual SysAdmins to keep the wiki updated with sections for any clients they become aware of that aren't already on the page. Maybe future enhancements could even (try to) detect the MUA client (is this possible to do reliably?), and a direct link to the section of the wiki for that specific client could be provided? Relying on user action doesn't sound like a very appealing solution to me. :) Nor me, but the fact is, since MUAs are configured by end users, and there is no way dovecot can change an MUAs account settings (to disable Save-To-Sent), what choice do we have? That is why I suggested some way to automatically inform users about this. Another (maybe better) option would be the SysAdmin could define a specific email address to handle these notifications, and it would be on them to get their users' MUAs configured correctly. I'd still like to see the option to inform users directly though - again, if this is even possible. Another thing that I know that google is really good at is automatically filtering (I guess they're deleting?) any and all duplicate emails. I have noticed this when copying a message store from one IMAP server to a gmail account. I had cases where the number of messages in certain folders wasn't the same, and upon investigation, noticed that the original/source in fact had some duplicate messages in certain folders. That is entirely possible. So, maybe you could 'kill two birds with one stone' so to speak. and whatever is done to address the duplicate Sent messages could also be leveraged to address duplicate messages in general? Although I guess it is not the same problem, so maybe not... You mean something like this? http://hg.rename-it.nl/dovecot-2.2-pigeonhole/raw-file/tip/doc/rfc/spec-bosch-sieve-duplicate.txt Lol! I see you're way ahead of me... ;) Thanks again Stephan. -- Best regards, Charles
Re: [Dovecot] SMTP Submission/Proxy server - WAS Re: Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
Am 10.05.2013 17:17, schrieb Charles Marcus:
On 2013-05-10 10:37 AM, Stephan Bosch step...@rename-it.nl wrote:
Ehhh.. no :) It implements the server-side SMTP AUTH, so that your MTA
doesn't have to any more. So the client
will authenticate to Dovecot rather than to the regular MTA/MSA. But, again,
this is a rather trivial matter and
not the main reason for building this proxy.
Ok... so, will this make it easier to add client side sasl support to
dovecots dovecot-sasl implementation to
eliminate the need for postfix+dovecot systems to continue to rely on
cyrus-sasl for MTA client side sasl support?
[root@srv-rhsoft:~]$ postconf -n | grep dovecot
smtpd_sasl_type = dovecot
dovecot.conf:
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group= postfix
}
}
and any dovecot user works the same way and with the same
auth-mechs with postfix - in use here since 2009
___
any in this case means rally any like also below to get rid
of problems with legacy client-configs of a old server which
supported % instead of @, now both works equal as username
auth_username_translation =
%@AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
signature.asc
Description: OpenPGP digital signature
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
On 5/10/2013 10:53 AM, Michael Wessel wrote: Did you have a look at this? http://wiki2.dovecot.org/Authentication/RestrictAccess On 5/10/2013 5:17 AM, Steve Campbell wrote: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. Thanks steve campbell The reason I'm asking about all of this is that a particular IP address is attempting to connect to our pop server, and it's trying every possible common user name (I think this is call a dictionary attack). I can't restrict access to a particular IP subnet because our users access their email from all over the place. So this suggestion seems to not be a solution, as I see it. Thanks though. If I have to, I'll just go put this IP on the firewall, but I don't have remote access (for security), so it's a little more effort than accessing the pop server. steve
[Dovecot] Dovecot 2.2.1 subscribtion status in LIST
Hi there, I am using Evolution to connect to dovecot imap server. Today the server was upgraded to 2.2.1 from 2.1.9, and there is problem with evolution being unable to subscribe to INBOX. This is from dovecot 2.1.9: a002 list * return (subscribed) * LIST (\Subscribed) . Sent Items * LIST (\Subscribed) . Junk E-mail * LIST (\Subscribed) . Trash * LIST (\Subscribed) . Archive * LIST (\Subscribed) . Drafts * LIST (\Subscribed) . INBOX--- And this is from 2.2.1: a002 list * return (subscribed) * LIST (\Subscribed) . Sent Items * LIST (\Subscribed) . Junk E-mail * LIST (\Subscribed) . Trash * LIST (\Subscribed) . Archive * LIST (\Subscribed) . Drafts * LIST () . INBOX --- a002 OK List completed. a002 lsub * * LSUB () . Drafts * LSUB () . Sent Items * LSUB () . Archive * LSUB () . Trash * LSUB () . INBOX --- * LSUB () . Junk E-mail a002 OK Lsub completed. In 2.2.1 LIST does not show INBOX as subscribed, which looks to confuse evolution. INBOX is actually subscribed: cat path-to-maildir/subscriptions Drafts Sent Items Archive Trash INBOX Junk E-mail
[Dovecot] 2.2.x autobuilds: Debian Stable now Wheezy, which pool for 2.2.x?
List, good evening, just installed a new Debian Stable (Wheezy). The Debian Stable repositories now include Dovecot 2.1.7 as standard. I haven't installed that because I wanted to try 2.2.x on this new clean install but unsure which 'pool' to use in the xi.rename-it.nl repository of autobuilds. http://xi.rename-it.nl/debian/pool/ Wheezy became Stable on May 5, just a few days ago. I'm not sure whether to still follow the advice in the wiki for obtaining 2.2.x for Wheezy, which (understandably, because the new Debian Stable release has been so very recent) continues to refer to Wheezy as 'testing'. http://wiki2.dovecot.org/PrebuiltBinaries#Automatically_Built_Packages Presumably, the packages in the 'testing' autobuild system pick up Debian's 'testing' pool libraries (or assume them to exist) and these may no longer be the ones needed for Wheezy because Wheezy is 'Stable', in Debian-speak. Does anyone know, for sure, which autobuild pool to now use for 2.2.x for Wheezy? http://xi.rename-it.nl/debian/pool/stable-auto/ or http://xi.rename-it.nl/debian/pool/testing-auto/ 2.2.x in 'stable-auto' doesn't seem to have changed since before Wheezy was released, whereas 2.2.x has changed in 'testing-auto', and I'm not sure what to make of that. Stephan does suggest that queries be directly written to him, but I posted here because I thought I might not be the only person who was unsure. I'd be grateful for any advice, regards, Ron
Re: [Dovecot] 2.2.x autobuilds: Debian Stable now Wheezy, which pool for 2.2.x?
On 5/10/2013 7:42 PM, Ron Leach wrote: List, good evening, just installed a new Debian Stable (Wheezy). The Debian Stable repositories now include Dovecot 2.1.7 as standard. I haven't installed that because I wanted to try 2.2.x on this new clean install but unsure which 'pool' to use in the xi.rename-it.nl repository of autobuilds. http://xi.rename-it.nl/debian/pool/ Wheezy became Stable on May 5, just a few days ago. I'm not sure whether to still follow the advice in the wiki for obtaining 2.2.x for Wheezy, which (understandably, because the new Debian Stable release has been so very recent) continues to refer to Wheezy as 'testing'. http://wiki2.dovecot.org/PrebuiltBinaries#Automatically_Built_Packages Presumably, the packages in the 'testing' autobuild system pick up Debian's 'testing' pool libraries (or assume them to exist) and these may no longer be the ones needed for Wheezy because Wheezy is 'Stable', in Debian-speak. Does anyone know, for sure, which autobuild pool to now use for 2.2.x for Wheezy? http://xi.rename-it.nl/debian/pool/stable-auto/ or http://xi.rename-it.nl/debian/pool/testing-auto/ 2.2.x in 'stable-auto' doesn't seem to have changed since before Wheezy was released, whereas 2.2.x has changed in 'testing-auto', and I'm not sure what to make of that. Stephan does suggest that queries be directly written to him, but I posted here because I thought I might not be the only person who was unsure. Oh, I didn't notice the release of Wheezy as the new stable. I'll give this a look. Use testing-auto for now. Regards, Stephan.
Re: [Dovecot] 2.2.x autobuilds: Debian Stable now Wheezy, which pool for 2.2.x?
On 5/10/2013 7:42 PM, Ron Leach wrote: List, good evening, just installed a new Debian Stable (Wheezy). The Debian Stable repositories now include Dovecot 2.1.7 as standard. I haven't installed that because I wanted to try 2.2.x on this new clean install but unsure which 'pool' to use in the xi.rename-it.nl repository of autobuilds. http://xi.rename-it.nl/debian/pool/ Wheezy became Stable on May 5, just a few days ago. I'm not sure whether to still follow the advice in the wiki for obtaining 2.2.x for Wheezy, which (understandably, because the new Debian Stable release has been so very recent) continues to refer to Wheezy as 'testing'. http://wiki2.dovecot.org/PrebuiltBinaries#Automatically_Built_Packages Presumably, the packages in the 'testing' autobuild system pick up Debian's 'testing' pool libraries (or assume them to exist) and these may no longer be the ones needed for Wheezy because Wheezy is 'Stable', in Debian-speak. Does anyone know, for sure, which autobuild pool to now use for 2.2.x for Wheezy? http://xi.rename-it.nl/debian/pool/stable-auto/ or http://xi.rename-it.nl/debian/pool/testing-auto/ 2.2.x in 'stable-auto' doesn't seem to have changed since before Wheezy was released, whereas 2.2.x has changed in 'testing-auto', and I'm not sure what to make of that. Stephan does suggest that queries be directly written to him, but I posted here because I thought I might not be the only person who was unsure. I'd be grateful for any advice, Hmm, the slave builder is down due to some issues with the Xen server. This means that testing-auto i386 (the master) will be the only release updated for the moment. I hope this still installs on stable, otherwise you'll have to wait a little longer. Regards, Stephan.
Re: [Dovecot] 2.2.x autobuilds: Debian Stable now Wheezy, which pool for 2.2.x?
On 10/05/2013 19:24, Stephan Bosch wrote: This means that testing-auto i386 (the master) will be the only release updated for the moment. I hope this still installs on stable, otherwise you'll have to wait a little longer. I'd clean-installed the amd64 version of Wheezy. I'd prefer to wait for the other builds, because running the i386 version will probably trigger a series of additional dependencies that ultimately won't be needed. And I'm genuinely happy to wait because I've still to work out various new bits of configuration to make the best use of 2.2 (we're running 1.x at the moment). And thank you, very much, for the quick reply. Ron
Re: [Dovecot] Released Pigeonhole v0.4.0 for Dovecot v2.2.1.
* Stephan Bosch step...@rename-it.nl: On 5/10/2013 3:02 PM, Patrick Ben Koetter wrote: * Stephan Bosch step...@rename-it.nl: But I don't quite understand how this is different from XCLIENT, apart from the SOURCE and IDENT items perhaps. XCLIENT impersonates a client and the SMTP server will act as if the XCLIENT was the real client, e.g. it will apply ACLs and other policies to the XCLIENT personality. XFORWARD will not alter the SMTP server behaviour. The client and message data from XFORWARD will only be used for logging purposes. Ah. One question: what should I do when the server allows both of these? Or is that impossible? It is possible to offer both capabilities and I think the goal defines if you should impersonate another client or merely forward client meta data. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Remove Return-Path in lda rejection message
At 4PM +0200 on 10/05/13 you (Davide) wrote: Is it possible to remove return-path in dovecot lda rejection? Can you explain a bit more what you mean? A message should always end up with exactly one Return-Path header, which is put in by the final (delivering) MTA. This is not something sieve has any control over: the rejection message sieve submits for delivery should not have a Return-Path header at all, since that information is (at that point) carried in the SMTP envelope. (In the case of a reject message, since this is an MDN, the SMTP FROM should be the null address .) Ben
