Re: [Dovecot] A dovecot book ?
Am 03.03.2010 23:55, schrieb Curtis Maloney: On 03/04/10 09:10, Noel Butler wrote: There is only one authoritative source who should be writing it if a book is to be written and we all know who that author should be. I disagree. In the time I've been watching/using Dovecot (since the 0.99 series) Timo has had many cases of improving Dovecot [even if it's just a config option name] because of the points of view of other people. For many reasons, I thinks it would be better if someone else [preferably someone with a long history with Dovecot, of course] were to write the book, and Timo signed off on it. But for what version, as 1.x is in wide usage and will be for a long time, 2.0 is almost upon us, much of 1.x is not applicable to 2.x , so should Timo be writing 2 books? One excessively big book? Where is he to find time to write this whilst developing dovecot, and heaven forbid, enjoy the outside world with a real life :) Given a sizable portion of understanding Dovecot is understanding email in general, I wonder just how much of the book would bifurcate for covering the differing versions... -- Curtis Maloney Hi all I have never thought on so many comments to my question and i am surely surprised about the direction how this discussion went. I totally agree with the one of you who mentioned the online documentation and the wiki. I know that it exists and i used it for setting up my mail server, but ... as i said, i am old fashioned and i can better work with books. It's just a personal preferrence. Well, i also know that many developers are still working on dovecot, especially Timo and that always new features, configuration options and so on are added, but ... it's the same with other applications in the community (e.g. postfix, apache, OpenLDAP, samba ) and for all those applications books are available, and that was the reason, why i asked for a book. And to be honest. When i go thru the documentation part, most of the documents were not changed for at least 6 months. I am sure that between the writing and the publishing of a book new dovecot features will be introduced and not covered in the book. But everyone working with books knows that they can't be up to date, but they are a real good basis for me to start with the fundamentals and then add this information by new data from the web. And guys just to mention one big advantage of a book is, you can read it offline easily!! But there is one thing i want to mention at this point. Even if you agree with me about having a book or not. What i really like is the discussion about and the chance to do so, because dovecot is opensource. And for me this is in the end the result behind the idea of open source. Everyone has the chance to contribute, either by code, by suggestions, by comments . And that for me is more important than to have a book or not. Thank you all for your comments. Regards, -- Mit freundlichem Gruß Carsten Laun-De Lellis Dipl.-Ing. Elektrotechnik Certified Information Systems Auditor (CISA) Hauptstrasse 13 D-67705 Trippstadt Phone: +49 (6306) 992140 Mobile: +49 (151) 27530865 email: carsten.delel...@delellis.net
[Dovecot] Saving Sent Messages to Sent Folder
Hi Timo,
There was another thread (it has come up at least a few times in the
past few years I've been lurking) on the postfix list about having some
kind of automatic 'Save to Sent' option to avoid the users mail client
from having to upload messages twice (obviously the only ones of concern
are ones with large attachments) - once to send it, and once to save the
copy in the sent folder.
I know and understand that doing this is not generally the job of the
MTA, but hopefully most people can at least admit that there would be a
(potentially huge, in the case of any large company that deals with a
lot of large attachments in their email) savings in bandwidth (and user
frustration) if a way could be found to do this reliably and at little
to no 'cost' in terms of CPU/Disk IO, so I have a question about how
this might be done...
Given: Postfix can be configured to use the Dovecot LDA for delivering
mail incoming.
My question is simply, why wouldn't it be possible to create a Dovecot
LSA ('submission agent'), that could be defined in postfix's master.cf
file, which could then be configured to a) pipe the message to postfix,
and b) if message is successfully sent, save a copy to the users Sent
folder?
Obviously, there would be some caveats - ie, postfix and dovecot would
both have to be running on the same box (or at a minimum on the same
local network)...
Anyway, this is just something that really bugs me (and has for many,
many years) every time I send a message with a large attachment, and
have to watch it slowly process the message sending it, then again to
save it to the Sent folder, so Ijust wanted to get your take on if this
is even remotely feasible...
--
Best regards,
Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Mar 2010, Charles Marcus wrote: Given: Postfix can be configured to use the Dovecot LDA for delivering mail incoming. And that's all what's needed. Configure your postfix to honor subaddresses, IMHO, it's seperated by + in postfix, and pass it as argument of -m option to deliver. Configure your MUA to always BCC to me+s...@example.net This config has three advantages over the traditional one: 1) you transmit the message over the wire just once. 2) you know that, if to send the message failed, the message is not sent, in opposite to differ from upload to Sent via IMAP failed in the second stage. 3) the message in your Sent mailbox has the queueid. Debugging is much easier. One disadvantage: 1) If the message is accepted, but for what reason ever is discarded by the MTA, the data is lost. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS4+5L7+Vh58GPL/cAQLHsAgAw7MLxmporZp8siSRSqPBdb7t2cfvJPa7 dg2NNLJAuoo093897U0IT02W1iYhU7rjSPraWsFmOA4YZnyZK6WicEhi8Usmp8kz Yx66v9lHCPcZ6JRkneCVxPhBqiCBMucGo8JUjytQcA4I+QnQpFqInZuFyB3IyJhf /WVneTTQ390gkv653zaYilUZEmeq9ZnrV1Sged/1TSfGyjtLcCwU23gmb4I+kWG7 eaJdb/LyUmzn6d+JZaSB/WJO5kAQ9gxvgzIOeJwqt1MzGWZMW7NklfUEbJLlUdlM DHYTHPJrynkA8T93og2ddDknURg0BCP2YYlX72KGadq88F6qq5Nd4A== =QvyY -END PGP SIGNATURE-
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 8:32 AM, Charles Marcus wrote:
My question is simply, why wouldn't it be possible to create a Dovecot
LSA ('submission agent'), that could be defined in postfix's master.cf
file,
Oh - and by 'LSA', I didn't mean to suggest you should architect a
complete 'smtp listener'. I'm thinking more in terms of a 'proxy', where
your service would simply proxy the submission transaction while
retaining a copy of the email up until the point where it would be
needed to be saved to the users Sent folder - and if the send
transaction failed for any reason, the email copy is simply discarded.
--
Best regards,
Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Mar 2010, Charles Marcus wrote: Some MUAs have a server-side outbox. Store anything therein, and the server picks up the messages. To/CC/BCC is taken from the message headers. You can implement this: a) via a Dovecot plugin, that triggers some demon. b) cron job c) filesystem listener (inotify in Linux) Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS4+8Fr+Vh58GPL/cAQKI6Af/YTzxu/2TPcX98wDIDzZ7k5tXuQ0hCZuk xOkV5we/WB8CqcfsfqiRy1f+3E1+S/2X/nB4q/gZv9/Pfhv8SnqVM+DT3ogfGF0d El7V0O1flqNvnwROft6qWcfMsKWjDPVLy/ug6MY2H1N+askEdZTG1nNnn5uf42l0 STdfWZNL58/ePEEJWZXc2mM3gE500r65J+LLl9afI+gj513Y0T9gI2Al05roT1tA 15JVytU8GNNfLolwPDy07pzJ/6TakXYESg1/5YknATt5Z9OH9Iof6+pPH54Jy4sT Gfn1hdQMtYwakdfalzQ7bxbjxwccqP7SpeUJZORnYOtKga47sHs4eQ== =U+xj -END PGP SIGNATURE-
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 8:56 AM, Steffen Kaiser wrote: On Thu, 4 Mar 2010, Charles Marcus wrote: Some MUAs have a server-side outbox. Yes, but most clients don't directly support them. I'm talking about something that can be used in the enterprise, without requiring user intervention, aside from a *simple* configuration option (like simply unchecking 'Place a copy in' for Sent messages)... I know there are probably a lot of ways this *can* be done... but again, I'm talking something server side that will require the bare minimum with respect to client configuration (and also that most clients will support (I think most clients do support the option to *not* save a sent copy?)), as well as minimal server side configuration. Maybe this is a bad idea... but like I said, this is something that has really bothered me for a long time, and there simply *has* to be a sane way to make this problem go away... Anyway, thanks for the responses... at least your first suggestion is something I can for myself, but it isn't something I'd like to support in an enterprise - at least not unless/until Thunderbird gets full support for Group Polices (and that would only apply to Windows Domain based customers, and not all are). -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
On Thu, 2010-03-04 at 08:32 -0500, Charles Marcus wrote:
There was another thread (it has come up at least a few times in the
past few years I've been lurking) on the postfix list about having some
kind of automatic 'Save to Sent' option to avoid the users mail client
from having to upload messages twice (obviously the only ones of concern
are ones with large attachments) - once to send it, and once to save the
copy in the sent folder.
LEMONADE group solved this with IMAP URLAUTH (RFC 4467) and SMTP BURL
(RFC 4468) extensions. The idea is basically (copypasting from RFCs):
C: RCPT TO:r...@gryffindor.example.com
S: 250 2.1.5 r...@gryffindor.example.com OK.
C: BURL imap://ha...@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 250 2.5.0 Ok.
So after receiving BURL command, SMTP server connects to IMAP server and
fetches the message:
S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
C: a001 LOGIN submitserver secret
S: a001 OK submitserver logged in
C: a002 URLFETCH imap://j...@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038
S: * URLFETCH imap://j...@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038 {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
Now, the problem is of course that neither Dovecot nor Postfix support
these extensions. For Dovecot I was thinking about using METADATA
extension's storage for storing the URLAUTH stuff, but METADATA isn't
really implemented yet either.
signature.asc
Description: This is a digitally signed message part
[Dovecot] INBOX of a shared namespace appears to be always subscribed
In dovecot 1.2.10 I run into the following problem: Our users are entitled to share their personal mailboxes. This works. But if user A shares any of its mailboxes with user B, then dovecot always reports the INBOX of user A as subscribed by user B. No matter whether user B really subscribed the INBOX of A, or whether user A permitted user B the access to its INBOX. The problem is caused by the repeated call of LSUB. Starting with the second call LSUB always shows INBOX as subscribed. To reproduce: - telnet imap.xx.yy 143 1 LOGIN user password 2 LSUB shared/*= shows shared/UserB/folderXX 3 LSUB shared/*= shows shared/UserB/INBOX shared/UserB/folderXX 4 LSUB shared/*= shows shared/UserB/INBOX shared/UserB/folderXX Regards, Holger
Re: [Dovecot] Dovecot 2.0.beta3: mdbox mailbox crashes upon login
On Sun, 2010-02-28 at 20:49 +0100, Thomas Leuxner wrote: Am 28.02.2010 um 20:23 schrieb Timo Sirainen: On Sun, 2010-02-28 at 20:11 +0100, Thomas Leuxner wrote: Feb 28 14:43:02 spectre dovecot: imap(u...@domain): Panic: file mailbox-list-fs.c: line 170 (fs_list_get_path): assertion failed: (mailbox_list_is_valid_pattern(_list, name)) I guess this helps: http://hg.dovecot.org/dovecot-2.0/rev/64f6c458aaff Still crashes right away: What about: http://hg.dovecot.org/dovecot-2.0/rev/c691706eee06 If it still crashes, gdb backtrace would be nice. http://dovecot.org/bugreport.html signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot 2.0.beta3: mdbox mailbox crashes upon login
On Thu, Mar 04, 2010 at 04:52:56PM +0200, Timo Sirainen wrote: What about: http://hg.dovecot.org/dovecot-2.0/rev/c691706eee06 If it still crashes, gdb backtrace would be nice. http://dovecot.org/bugreport.html Haven't tested this one yet, but I think the problem vanished with: http://hg.dovecot.org/dovecot-2.0/rev/154f52b7a6fd Just wanted to monitor it for some time, but do consider it fixed now, apart from the ACL problem in another thread. Regards Thomas
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 9:32 AM, Timo Sirainen wrote: LEMONADE group solved this with IMAP URLAUTH (RFC 4467) and SMTP BURL (RFC 4468) extensions. The idea is basically (copypasting from RFCs): C: RCPT TO:r...@gryffindor.example.com S: 250 2.1.5 r...@gryffindor.example.com OK. C: BURL imap://ha...@gryffindor.example.com/outbox ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry :internal:91354a473744909de610943775f92038 LAST S: 250 2.5.0 Ok. So after receiving BURL command, SMTP server connects to IMAP server and fetches the message: But wouldn't this also require the MUA to support the concept of an 'Outbox'? TB3 currently has partial support for an Outbox, but only for 'sending messages in background', not for letting the *server* pick them up and handle it. Yes, support could be added, but I'd much prefer something purely server side that just works regardless of the MUA. Of course, the MUA would have to have a configurable option to *not* 'save a copy' of messages it sends on the server (I would think most do), and support would also have to be added for postfix, which I have no idea if Wietse would have any desire to do this (I lean toward not). The thread is progressing on the postfix list though, and it appears a working solution just might be achievable now through the use of sender_bcc_maps and sieve, if you are using postfix, dovecot and the dovecot LDA... I'll post here the result of that conversation to clarify if this can be done... -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Mar 2010, Charles Marcus wrote: Interesting, and yes, apparently this would suffice as a workaround for individual users, but imo the less configuring that needs to be done *in the client* the better - most importantly, there is less chance of problems from a user configuration error. I'd prefer to just uncheck the 'Save a copy' option, and let the save to sent happen totally on the server side. Configure postfix to add the BCC to all messages in the MSA or all authentificated or however you can identify your users apart others. 2) you know that, if to send the message failed, the message is not sent, in opposite to differ from upload to Sent via IMAP failed in the second stage. Sorry, I don't understand what you mean here (language problem most likely)... Traditionally the MUA first transmits the message first via SMTP to a MTA or MSA, then via IMAP into the Sent folder. If the first step succeeds, but the second does not, my users are worried that the message has not been sent and try again. The error message, however, states correctly that the message was sent successfully, but could not been uploaded into the sent folder. One disadvantage: 1) If the message is accepted, but for what reason ever is discarded by the MTA, the data is lost. Why would it be accepted then discarded? Anyway, in such a case the data is lost regardless, right? Because, traditionally, the message is transmitted via IMAP, too, it is in the Sent folder. Well, a MSA should not discard a message in the first place :-) Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS4/NGL+Vh58GPL/cAQI4WAf9Eha5u6sRNyyPdYl2IuJCwI0/vxDLpWvO KB6EO1YJZe3+mbb38i13twXaBOV0NM5gdemRQ80ptdFpJ/uVc62Tm7FkdpHpzfNI 9W9vLPbuPXr4XNvs8Hy0/LecrQ4U2Qp9kmQTCSEieZXMJPEq5CAGkX2Q1H67rmxH tEt7RuiMnaOF7DERW2wwyE7WPwO3yVFxChzkR6x56fBfkmoaRarxLSGXBh9SS1c3 GKf+9n3z0OUhhJ1pDPC4nPYU8SUBQx2fFBhLxUzntc+JtSzPPvGqs18HJ/UHhmdy Wl0rBTvFSiRGJO4XqJYd8rw2C5O/CwiUTGjv6dFBW3OuFbZ5pyX8JA== =Rbcg -END PGP SIGNATURE-
Re: [Dovecot] Saving Sent Messages to Sent Folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Mar 2010, Charles Marcus wrote: 'sending messages in background', not for letting the *server* pick them You could put that mailbox on the IMAP server, probably. There the server can pick them up. something purely server side that just works regardless of the MUA. Of That means: SMTP. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS4/NvL+Vh58GPL/cAQLGMggAhSuVoJnTosS46W1h+p4FB5vCQdsDytpe uSAJF+tzKizMDM9Z9V4WxPYzlU+2933M/HlV/75c8Ijzy08VJmMrthM7WzQo+fcI Oc3NjhtwU+f8uxOImgM/PK/XedfDKOOzYPg4VXoE/STwLiOI60AGq788INxyTyzZ lQRHxclKsvyzFMnRpJU3eZvkSTYjPmAmN3ZiUCiIpZz65unINc70bzvYeufQTPAy vEP8Xfud/LMigvIAY2bX9ddywTXVgVUOhSeuIcarA3/9de/oAGcjVLdc+jNwAuM3 U57Ss2GPghWdH2+LY0Peoyz7U9s7Ntr9UBDc29iotdkHlL/KsAuPJw== =D8MZ -END PGP SIGNATURE-
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 10:11 AM, Steffen Kaiser wrote: something purely server side that just works regardless of the MUA. Of That means: SMTP. Right - which is why I started this thread as exploring the possibility of some kind of 'submission proxy' service that would work with postfix's submission service. -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Mar 2010, Charles Marcus wrote: Anyway, thanks for the responses... at least your first suggestion is something I can for myself, but it isn't something I'd like to support in an enterprise - at least not unless/until Thunderbird gets full support for Group Polices (and that would only apply to Windows Domain based customers, and not all are). Are Thunderbirds prefs still plain text? Using the Login script I've added settings there (well, actually Mozilla Seamonky) once sometime ago. I just added a bunch of lines to the prefs at each login. IMHO, the last definition wins. And the quick launcher starts a bit later, so the changes do have effect in each session. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS4/O4b+Vh58GPL/cAQLTSAgAtY4o5Ubg8rnye+4WlFGzU76ewFUOD7Cg QfhBUbVE3ojLCAY/WJCO1G+/gTmG8g7XwN/kLvXsq2f5fzyjdQMF0oKFDe6zhClB wgqr1Fu9RgNowYpIQJexo5cXFKAe784pigph2I4nTjN1zwRvPxnzRJk7XTFTquBh BeKti9DB4WWswAZRaGGNXnI2pGkFd2P89ejaeeUH9NkETt45rprk7c6xjAWBVlC9 sLh9L6Rq3OTNtcyTXYHXBjdjiLdZdy+DeBNCBYcyM6YFMqxfFnxQK67oo4/FyhaI R6226hTiup7VEa+rrKSzxOTz4j+QV+s9aCekwq3qlZMcFIN0QzYxMQ== =Em5J -END PGP SIGNATURE-
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 10:09 AM, Steffen Kaiser wrote: Configure postfix to add the BCC to all messages in the MSA or all authentificated or however you can identify your users apart others. Right - this is what is being discussed now... 2) you know that, if to send the message failed, the message is not sent, in opposite to differ from upload to Sent via IMAP failed in the second stage. Sorry, I don't understand what you mean here (language problem most likely)... Traditionally the MUA first transmits the message first via SMTP to a MTA or MSA, then via IMAP into the Sent folder. If the first step succeeds, but the second does not, my users are worried that the message has not been sent and try again. The error message, however, states correctly that the message was sent successfully, but could not been uploaded into the sent folder. Ahh, got it... Right, and this is something that has always bugged me about TB (2, and now 3)... the error message is wrong. If it successfully sends the message, but has an error saving to the Sent folder, the error message says 'There was a problem *sending* your message...' - I keep forgetting to go open a bug report, but I'll do that now... thanks for the reminder... :) -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Mar 2010, Charles Marcus wrote: Right - which is why I started this thread as exploring the possibility of some kind of 'submission proxy' service that would work with postfix's submission service. I do as well. If I understand sender_bcc_maps correctly, you can configure my first suggestion straight forward. sender_bcc_maps: m...@example.comme+s...@example.com Then pass the detail to deliver's -m option, which is the default mailbox the message is filed in. Sieve could probably limit the detail to some selective ones, if you don't like the subaddressing feature in general. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS4/Qnr+Vh58GPL/cAQJP4Af9GkBVdsRvrvWYgggpk91T5b2i2BKwP3Lp zLH2tDsgeURkwP55veSyUkUh2PRT/JKTrWV1ft7742CMapp5uEVcpsCDznmCBl0d lQ+Mqws5ZMjtY+9c0fhH0unvWTvzh+NLioDZNE6qc+jK/EoVNx8JjGPPQi5r8F0K EsRHtyfP1ccl6vY89V14cCo2I8qY6NkNwgQA7YWd6mQzEXSpHEI1mLheH0kHWCpM aGxn/c6kMwzsR/gpHDanXLIIH2rNyeupsQPaWDfk3EwCVv+FeFppF/gxZ1sxT6yA duJqg+tu6GVaviDoz0xfqN77af3okK/D1GS/c2naZAj2k0VSswGJeA== =2L/G -END PGP SIGNATURE-
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 10:24 AM, Steffen Kaiser wrote: If I understand sender_bcc_maps correctly, you can configure my first suggestion straight forward. sender_bcc_maps: m...@example.comme+s...@example.com Then pass the detail to deliver's -m option, which is the default mailbox the message is filed in. Sieve could probably limit the detail to some selective ones, if you don't like the subaddressing feature in general. I do... :) The only remaining question is if: '-o sender_bcc_maps=hash:/etc/postfix/sender_bcc' Can be added only to the submission service in master.cf. Still waiting on a definitive answer (don't want to break my production postfix server testing this, and I don't have a test server up at the moment). -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 10:16 AM, Steffen Kaiser wrote: Anyway, thanks for the responses... at least your first suggestion is something I can for myself, but it isn't something I'd like to support in an enterprise - at least not unless/until Thunderbird gets full support for Group Polices (and that would only apply to Windows Domain based customers, and not all are). Are Thunderbirds prefs still plain text? Using the Login script I've added settings there (well, actually Mozilla Seamonky) once sometime ago. I just added a bunch of lines to the prefs at each login. IMHO, the last definition wins. And the quick launcher starts a bit later, so the changes do have effect in each session. Yes - and I do configure it like this, but users can still change them during that session - with mandatory GPO support, they wouldn't be able to. That's why I'd prefer this to be strictly server-side... and why I'm excited to learn that this may be achievable now, with some reasonably simple config changes... although this will be my first foray into the world of sieve, so will almost definitely be asking questions about that - and same for quotas... Time to get my dovecot test server reinstalled (I wiped it for other reasons) and start testing, because I want this to be working for when I convert my main client from Courier to dovecot. I've been trying to get them to do this for a long time, but now they have given me the go ahead to test a few accounts with big mail boxes to see firsthand the performance improvements. They send/receive a lot of messages with large attachments, so being able to disable 'save to sent' and have it 'just work' will be a huge plus. -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
On Thu, 2010-03-04 at 10:05 -0500, Charles Marcus wrote: On 2010-03-04 9:32 AM, Timo Sirainen wrote: LEMONADE group solved this with IMAP URLAUTH (RFC 4467) and SMTP BURL (RFC 4468) extensions. The idea is basically (copypasting from RFCs): C: RCPT TO:r...@gryffindor.example.com S: 250 2.1.5 r...@gryffindor.example.com OK. C: BURL imap://ha...@gryffindor.example.com/outbox ;uidvalidity=1078863300/;uid=25;urlauth=submit+harry :internal:91354a473744909de610943775f92038 LAST S: 250 2.5.0 Ok. So after receiving BURL command, SMTP server connects to IMAP server and fetches the message: But wouldn't this also require the MUA to support the concept of an 'Outbox'? MUA would have to support both of those URLAUTH and BURL extensions, so that it can register a temporary URL on the IMAP server, then connect to SMTP server and give that URL to BURL command (instead of sending the mail with DATA command). So from MUA's point of view it's basically the same as before: save to IMAP and after that send via SMTP. support would also have to be added for postfix, which I have no idea if Wietse would have any desire to do this (I lean toward not). Yeah, he probably isn't interested in adding IMAP client support for Postfix, although it could be pretty basic support. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 10:47 AM, Timo Sirainen wrote: MUA would have to support both of those URLAUTH and BURL extensions, so that it can register a temporary URL on the IMAP server, then connect to SMTP server and give that URL to BURL command (instead of sending the mail with DATA command). So from MUA's point of view it's basically the same as before: save to IMAP and after that send via SMTP. Ah, ok... well, honestly, this would probably be the 'ideal' solution, but I don't see it happening anytime soon, if ever... Yeah, he probably isn't interested in adding IMAP client support for Postfix, although it could be pretty basic support. No worries... apparently this is completely doable using postfix, dovecot, dovecot's LDA, and sieve... not quite as simple as just defining a new 'dovecot LSA proxy', but still doable. Last ditch effort/comment - maybe a 'dovecot LSA proxy' would be useful for more than just this? But you never answered as to whether or not such a thing is even remotely feasible, much less doable in the real world... ;) -- Best regards, Charles
Re: [Dovecot] Saving Sent Messages to Sent Folder
On 2010-03-04 11:44 AM, Charles Marcus wrote: No worries... apparently this is completely doable using postfix, dovecot, dovecot's LDA, and sieve... not quite as simple as just defining a new 'dovecot LSA proxy', but still doable. The downside to this is, anyone doing this will have to maintain explicit sender_bcc_maps (unless I get a positive response on the advisability of using a regex in the sender_bcc_maps to avoid the necessity). -- Best regards, Charles
Re: [Dovecot] Dovecot 2.0.beta3: mdbox mailbox crashes upon login
Am 04.03.2010 um 15:52 schrieb Timo Sirainen: What about: http://hg.dovecot.org/dovecot-2.0/rev/c691706eee06 If it still crashes, gdb backtrace would be nice. http://dovecot.org/bugreport.html Still running fine with this one applied. Regards Thomas
Re: [Dovecot] Saving Sent Messages to Sent Folder
On Thu, 2010-03-04 at 11:44 -0500, Charles Marcus wrote: Last ditch effort/comment - maybe a 'dovecot LSA proxy' would be useful for more than just this? But you never answered as to whether or not such a thing is even remotely feasible, much less doable in the real world... Sure everything is possible.. :) But it's not really something that I'm interested in developing. signature.asc Description: This is a digitally signed message part
[Dovecot] Mailing list's prefix
Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Mailing list's prefix
On 3/4/10 3:59 PM, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Only people who deserve to have them break. ;-) It's 2010. List-Id, already. -- Braden McDaniel bra...@endoframe.com
Re: [Dovecot] Mailing list's prefix
I would have preferred this be a private reply but I like to honor the sender's request re Reply-To:. I have a slight preference for keeping the [Dovecot] prefix in the Subject: header, as it makes it really obvious to me where a message in my inbox comes from. I have never liked to pre-sort incoming messages into separate folders. The fact that the prefix is relativelyh short also helps. H
Re: [Dovecot] Mailing list's prefix
Harlan Stenn wrote: I have a slight preference for keeping the [Dovecot] prefix in the Subject: header, as it makes it really obvious to me where a message in my inbox comes from. I have never liked to pre-sort incoming messages into separate folders. The fact that the prefix is relativelyh short also helps. A very simple procmail recipe can add those prefixes for you and you won't have to worry whether the list has them or not. -- W | It's not a bug - it's an undocumented feature. + Ashley M. Kirchner mailto:ash...@pcraft.com . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Imaging . 2901 55th Street http://www.pcraft.com . . .. Boulder, CO 80301, U.S.A.
Re: [Dovecot] Mailing list's prefix
On 2010-03-04 4:04 PM, Braden McDaniel wrote: On 3/4/10 3:59 PM, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Only people who deserve to have them break. ;-) It's 2010. List-Id, already. +1 -- Best regards, Charles
Re: [Dovecot] Mailing list's prefix
Quoting Harlan Stenn harlan.st...@pfcs.com: I would have preferred this be a private reply but I like to honor the sender's request re Reply-To:. I have a slight preference for keeping the [Dovecot] prefix in the Subject: header, as it makes it really obvious to me where a message in my inbox comes from. I have never liked to pre-sort incoming messages into separate folders. The fact that the prefix is relativelyh short also helps. H I think those of us who don't filter are benefited the most by having the prefix. I'm on a couple lists that aren't filtered, though not as high traffic. I don't read ALL email, and would prefer to delete non-relevant emails without opening the message. Without a prefix, I sometimes have a hard time telling if a problem is directed to me (personal/biz support) or a list when I delete in bulk via thin clients (iPhone, Horde). Rick
Re: [Dovecot] Mailing list's prefix
On 4 March 2010 22:04, Braden McDaniel bra...@endoframe.com wrote: On 3/4/10 3:59 PM, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Only people who deserve to have them break. ;-) It's 2010. List-Id, already. +1 -- B. Johannessen
Re: [Dovecot] Mailing list's prefix
On 3/4/10 10:59 PM +0200 Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Do you really need to ask? You'd definitely break a lot of filters. Don't let that stop you. :) FWIW I hate those prefixes. On 2/25/10 2:10 PM -0700 Ashley M. Kirchner wrote: A very simple procmail recipe can add those prefixes for you or remove them. -frank
Re: [Dovecot] Mailing list's prefix
Quoting Timo Sirainen t...@iki.fi: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. List-Id has been mentioned as the replacement mechanism by some, but the main issue is that it is not immediately viewable (at least with any rationally configured MUA) to the user. Obviously, filtering by List-Id is the preferred method, since it has the canonical mailing list definition. However, List-Id filtering does not work in all situations. For example, a common situation (at least for me) is someone who replies directly to your message from a list instead of to the list address. This will most likely cause that message to end up in your INBOX rather than being filtered into the appropriate mailing list mailbox. Having the list name in the Subject can be useful to visually filter these incoming messages in your INBOX, rather than potentially deleting/marking as spam since often times you may not recognize the sender. FWIW, use of brackets in this manner is sort of a pseudo-standard, insomuch as it is an acceptable component of Subject lines with respect to threading/sorting pursuant to RFC 5256. michael
Re: [Dovecot] Mailing list's prefix
Frank Cusack wrote: On 2/25/10 2:10 PM -0700 Ashley M. Kirchner wrote: A very simple procmail recipe can add those prefixes for you or remove them. Agreed, though I was focusing on those who have a preference to keeping them. :) -- W | It's not a bug - it's an undocumented feature. + Ashley M. Kirchner mailto:ash...@pcraft.com . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Imaging . 2901 55th Street http://www.pcraft.com . . .. Boulder, CO 80301, U.S.A.
Re: [Dovecot] Mailing list's prefix
It's a shame that this isn't a per-user option. mailman already enforces adding the prefix if it isn't present so there's no reason for it to be a global option. Looks like this feature request has been open for 5 years. :( http://sourceforge.net/tracker/?func=detailatid=350103aid=1104433group_id=103
Re: [Dovecot] [dovecot]
Quoting Ashley M. Kirchner ash...@pcraft.com:
Frank Cusack wrote:
On 2/25/10 2:10 PM -0700 Ashley M. Kirchner wrote:
A very simple procmail recipe can add those prefixes for you
or remove them.
Agreed, though I was focusing on those who have a preference to
keeping them. :)
Yeah.. procmail filter to modify the subject would satisfy me.
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [dovecot] $MATCH
}
Rick
Re: [Dovecot] [dovecot]
On 2010-03-04 15:27:20 -0600, Rick Romero wrote:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [dovecot] $MATCH
}
and with an LDA that speaks only sieve?
how do you do it there?
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
Re: [Dovecot] plugin Again
On 3.3.2010, at 21.30, Alex Baule wrote: But i got some questions about the stream-pos, stream-skip and position of the message and pointer to buffer. 1. Data is read to buffer, and stream-buffer points to it, stream-skip = 0 and stream-pos = number of bytes available in the buffer. 2. i_stream_skip() and i_stream_seek() can go forward by simply increasing stream-skip. So stream-buffer + stream-skip always points to the data that i_stream_get_data() returns. 3. Actual seek() implementation typically resets the stream by changing the offset and setting skip=pos=0. 4. read() can internally do whatever it wants, as long as the result is consistent. So for example with istream-file the buffer points to a larger buffer and it tries to avoid memmove()ing data, so it tries to add data at the end of the buffer and just increase stream-pos. But it can't always do that, so it then memmove()s the data and sets skip=0. The buffer from istream-concat is 4096, i read 4096 from get_stream_data, but the result of this read is minor , lets say 4080, but the next read must be from 4096. The send to client must be 4080, to send the correctly data decrypted. My Question is, what the variable used in istream-concat, to send the data to client ? I need to update the stream-pos with my data length ?? I'm not really sure what you're asking here.. i_stream_read() for blocking streams must always read and return at least one byte. There's no guarantees that it ever returns more than one byte at a time. So if you need to read more, keep calling i_stream_read() until it has read as much data as you wanted (i_stream_read_data() does basically that). istream-concat actually doesn't define buffer's size. It gets the max buffer size from the parent input streams. But it's still just the max. buffer size, nothing guarantees that reads can read that much data at a time.
Re: [Dovecot] [dovecot] - filters
Quoting Marcus Rueckert da...@opensu.se:
On 2010-03-04 15:27:20 -0600, Rick Romero wrote:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
and with an LDA that speaks only sieve?
how do you do it there?
This is better for procmail (doesn't change Subject if [Dovecot]
already there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
* !^Subject:.*\[Dovecot\]
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [Dovecot] $MATCH
}
}
I don't know enough about Sieve to give an example..
what you want is:
1. List-Id head contains Dovecot Mailing List
2. Subject does not contain [Dovecot]
3. Pass email to formail to modify Subject ( built in Sieve equivalent?)
HTH
Rick
Re: [Dovecot] Mailing list's prefix
On Thu, 04 Mar 2010 22:59:59 +0200 Timo Sirainen t...@iki.fi articulated: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Personally, I filter on the List-Id, so it doesn't make any difference to me. I guess losing the prefix might be a good idea though. -- Jerry ges...@yahoo.com |=== |=== |=== |=== | Life sucks, but death doesn't put out at all. Thomas J. Kopp signature.asc Description: PGP signature
Re: [Dovecot] Mailing list's prefix
On 2010-03-04 22:59:59 +0200, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. personally i like the prefixes. especially to sort off list replies when looking through the inbox. so -1 from me on removing. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: [Dovecot] Mailing list's prefix
On Thu, 04 Mar 2010 22:59:59 +0200 Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Removal gives 10 chars more for the subject. Remove it. --Frank Elsner
Re: [Dovecot] Mailing list's prefix
On 03/04/2010 03:59 PM, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. I vote to keep it. Although I filter on List-Id, occasionally my filters break and I end up receiving a bunch of list messages in my INBOX. When this happens, the first thing I do after fixing my filters is search for mailing list tags in subjects (because practically every mail client on earth supports doing so) and move those messages into the right place. One of the features I miss from claws-mail, now that I'm using Thunderbird again, is the ability to remove text matching an arbitrary regexp from all messages in a folder. I used to remove the [Dovecot] prefix using this, but since it was only hidden from view I still had the benefit of being able to search for it. -- Ben Winslow r...@bluecherry.net
Re: [Dovecot] [dovecot] - filters
On 4-Mar-10, at 4:36 PM, Rick Romero wrote:
Quoting Marcus Rueckert da...@opensu.se:
On 2010-03-04 15:27:20 -0600, Rick Romero wrote:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
and with an LDA that speaks only sieve?
how do you do it there?
This is better for procmail (doesn't change Subject if [Dovecot]
already there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
* !^Subject:.*\[Dovecot\]
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [Dovecot] $MATCH
}
}
I don't know enough about Sieve to give an example..
what you want is:
1. List-Id head contains Dovecot Mailing List
2. Subject does not contain [Dovecot]
3. Pass email to formail to modify Subject ( built in Sieve
equivalent?)
HTH
Rick
So what happen if I had this promail recipe and I reply to list?
If the subject line is Dovecot Mailing List, will it become Re:
Dovecot Mailing List or Re: [Dovecot] Mailing List? (I think it's
the latter case)
If it's the latter one, I vote to keep the prefix now.
The prefix helps visual eye filtering, works for people (including me)
who keep all new email to inbox rather than direct them to other
folder before reading them.
I vote to keep the prefix even it's the first scenario, but I'm not
strong into must keep prefix in both cases.
Joseph
Re: [Dovecot] Mailing list's prefix
On Thu, Mar 04, 2010 at 10:59:59PM +0200, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. -1 on removal. I use mutt and I do not presort into folders; however I do have macros to limit display to various lists I am on so I can go through messages and threads as I have time to do so. Removal of the prefix would be truly annoying. John -- The price we pay for money is paid in liberty. -- Robert Louis Stevenson (1850-1894), novelist, essayist, and poet pgpwnJKdvOGBV.pgp Description: PGP signature
Re: [Dovecot] Mailing list's prefix
On 04.03.10 21:59, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? I'd strongly prefer you removing the prefix. One can assume that most list members use a Dovecot server backend. Simply add a sieve rule to filter by the List-Id header, and you're done. -R
Re: [Dovecot] [dovecot] - filters
Rick Romero wrote:
Quoting Marcus Rueckert da...@opensu.se:
On 2010-03-04 15:27:20 -0600, Rick Romero wrote:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
and with an LDA that speaks only sieve?
how do you do it there?
This is better for procmail (doesn't change Subject if [Dovecot] already
there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
* !^Subject:.*\[Dovecot\]
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [Dovecot] $MATCH
}
}
I don't know enough about Sieve to give an example..
what you want is:
1. List-Id head contains Dovecot Mailing List
2. Subject does not contain [Dovecot]
3. Pass email to formail to modify Subject ( built in Sieve equivalent?)
if header :contains List-Id dovecot.dovecot.org {
fileinto Dovecot;
stop;
}
I just removed my Subject based filter and put this in so +1.
\\||/
Rod
--
HTH
Rick
Re: [Dovecot] Mailing list's prefix
On Thu, 4 Mar 2010, Rick Romero wrote: Quoting Harlan Stenn harlan.st...@pfcs.com: I would have preferred this be a private reply but I like to honor the sender's request re Reply-To:. I have a slight preference for keeping the [Dovecot] prefix in the Subject: header, as it makes it really obvious to me where a message in my inbox comes from. I have never liked to pre-sort incoming messages into separate folders. The fact that the prefix is relativelyh short also helps. H I think those of us who don't filter are benefited the most by having the prefix. I'm on a couple lists that aren't filtered, though not as high traffic. I don't read ALL email, and would prefer to delete non-relevant emails without opening the message. Without a prefix, I sometimes have a hard time telling if a problem is directed to me (personal/biz support) or a list when I delete in bulk via thin clients (iPhone, Horde). +1 I let lower traffic lists land in my inbox. I eat my own dogfood as well as far as mail is concerned, and we don't let users configure procmail (at some point they'll get basic sieve support). I also find myself checking email quite often on my phone, and seeing the listname in the subject is very helpful. Charles Rick
Re: [Dovecot] Mailing list's prefix
On 4.3.2010, at 22.59, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Well, it's beginning to sound like there are non-filtering reasons why the prefix can be good. So I guess it's better to keep things the way they are now :)
Re: [Dovecot] Mailing list's prefix
On 2010-03-04 4:55 PM, Ben Winslow wrote: Although I filter on List-Id, occasionally my filters break and I end up receiving a bunch of list messages in my INBOX. When this happens, the first thing I do after fixing my filters is search for mailing list tags in subjects (because practically every mail client on earth supports doing so) and move those messages into the right place. Why do that manually? Just re-run the filter on the Inbox... -- Best regards, Charles
Re: [Dovecot] Mailing list's prefix
On 2010-03-04 5:24 PM, John R. Dennison wrote: I use mutt and I do not presort into folders; however I do have macros to limit display to various lists I am on so I can go through messages and threads as I have time to do so. So change the macros to filter based on list-id rather than something in the subject... Better than insisting the rest of us suffer... ;) -- Best regards, Charles
Re: [Dovecot] [dovecot] - filters
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
This is better for procmail (doesn't change Subject if [Dovecot]
already there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
The first one is not a filter, and we don't wanna wait for it either.
And all this unnecessary cascading of recipes, to get an AND, which is
default with multiple conditions... See, that's why people perceive
procmail syntax as hard to understand. ;)
# Force-inject [Dovecot] Subject tagging, just because I insist on the
# list traffic hitting my Inbox, and am unwilling to filter it.
:0 fw
* ^List-Id: .*Dovecot Mailing List
* ! ^Subject: .*\[Dovecot\]
* ^Subject: \/.*
| formail -I Subject: [Dovecot] ${MATCH}
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] [dovecot] - filters
Quoting Joseph Yee j...@ca.afilias.info:
On 4-Mar-10, at 4:36 PM, Rick Romero wrote:
Quoting Marcus Rueckert da...@opensu.se:
On 2010-03-04 15:27:20 -0600, Rick Romero wrote:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
and with an LDA that speaks only sieve?
how do you do it there?
This is better for procmail (doesn't change Subject if [Dovecot]
already there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
* !^Subject:.*\[Dovecot\]
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [Dovecot] $MATCH
}
}
I don't know enough about Sieve to give an example..
what you want is:
1. List-Id head contains Dovecot Mailing List
2. Subject does not contain [Dovecot]
3. Pass email to formail to modify Subject ( built in Sieve equivalent?)
HTH
Rick
So what happen if I had this promail recipe and I reply to list?
If the subject line is Dovecot Mailing List, will it become Re:
Dovecot Mailing List or Re: [Dovecot] Mailing List? (I think
it's the latter case)
If it's the latter one, I vote to keep the prefix now.
The prefix helps visual eye filtering, works for people (including
me) who keep all new email to inbox rather than direct them to other
folder before reading them.
I vote to keep the prefix even it's the first scenario, but I'm not
strong into must keep prefix in both cases.
The procmail recipe would mark a reply as:
[Dovecot] Re: Mailing List
UNLESS you replied to it. Then your MUA would prepend the [Dovecot]
with Re: just like it does now.
So it wouldn't be exactly the same. You'd have to figure out how to
insert text... It's just getting bigger and uglier - though I'm sure
some expert could trim it... also untested...
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0 fhw
* !^Subject:.*\[Dovecot\]
{
:0 fhw
* ^Subject: Re:\/.*
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: Re: [Dovecot] $MATCH
}
:0 fhw
* !^Subject: Re:\/.*
{
:0 fhw
* ^Subject:\/.*
| formail -I Subject: [Dovecot] $MATCH
}
}
}
Re: [Dovecot] Limit login attempts per connection?
On 10-03-03 23:01:58, Stan Hoeppner wrote: Tony Nelson put forth on 3/3/2010 2:39 PM: Dovecot allows a large number of login attempts per connection. I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay, but I can't find anything in /etc/dovecot.conf or by googling. How do I do it? Do I need to patch the source? dovecot-1.1.10-1.x86_64 on CentOS 5.4 Can you tell us more about these unwanted login attempts? Are you merely trying to stop Chinese et al hacker woodpeckering on your IMAP/POP port(s) or something else? Crackers, yes. They're just the sort one doesn't want getting in to one's system, and the fewer tries they get the better. But the reason is not important. Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/
Re: [Dovecot] Limit login attempts per connection?
On 10-03-04 00:51:40, to...@tuxteam.de wrote: On Wed, Mar 03, 2010 at 03:39:28PM -0500, Tony Nelson wrote: Dovecot allows a large number of login attempts per connection. I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay, If the firewall is the one to do the job, I'd recommend an external application like fail2ban. It watches the logs and bans IP addresses with too many failures -- the nice thing is that it's able to cover all applications listening on external ports. You can define patterns in log files to which it has to react (but it comes with a good set of pre-defined patterns -- at least on popular GNU/Linux distros). I already have something that works with any program secure enough not to allow unlimited login attempts. Using fail2ban might work if I configure it enough to sever existing connections. but I can't find anything in /etc/dovecot.conf or by googling. How do I do it? Do I need to patch the source? I don't know about such a setting (but I don't know everything about Dovecot either!). Anyway, then it'd still the Dovecot process dealing with the rouge login attempts -- it seems better to keep them at the firewall level with the approach above. Yes, and I'm going to use the firewall -- once I can get Dovecot to limit the number of login attempts per connection. Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/
Re: [Dovecot] [dovecot] - filters
Quoting Karsten Bräckelmann guent...@rudersport.de:
I'm by no means a procmail expert, but this seems to work (though
[Dovecot] gets put before the Re:)
This is better for procmail (doesn't change Subject if [Dovecot]
already there)
:0 fhw
* ^List-Id:.*Dovecot Mailing List
{
:0
The first one is not a filter, and we don't wanna wait for it either.
And all this unnecessary cascading of recipes, to get an AND, which is
default with multiple conditions... See, that's why people perceive
procmail syntax as hard to understand. ;)
# Force-inject [Dovecot] Subject tagging, just because I insist on the
# list traffic hitting my Inbox, and am unwilling to filter it.
:0 fw
* ^List-Id: .*Dovecot Mailing List
* ! ^Subject: .*\[Dovecot\]
* ^Subject: \/.*
* ! ^Subject: Re:\/.*
| formail -I Subject: [Dovecot] ${MATCH}
Added partial Re: adjuster - Use a 2nd recipe for the Subject: Re: [Dovecot] ?
THANK YOU! :)
Rick
Re: [Dovecot] Mailing list's prefix
On Fri, 2010-03-05 at 00:45 +0200, Timo Sirainen wrote:
On 4.3.2010, at 22.59, Timo Sirainen wrote:
Do you think I'd break a lot of people's filters if I removed the
prefix? :) Anyone strongly for/against removing it? It seems kind of
annoying to me whenever I happen to think about it.
Well, it's beginning to sound like there are non-filtering reasons why
the prefix can be good. So I guess it's better to keep things the way
they are now :)
I don't recall any, other than plain refusal to use a dedicated folder,
rather than dumping it all into the Inbox...
Anyway, here's a procmail recipe to *remove* the unnecessary Subject
tagging. Enjoy!
:0
* ^List-Post: mailto:dovecot@dovecot.org
{
:0 fw
| sed 1,/^$/ { /^Subject:/ s/\[Dovecot\] // }
:0 :
DELIVERY_LOCATION_GOES_HERE
}
Caveat: Copy-n-paste, modified from a more complex recipe handling
multiple lists. Not tested. Use on your own risk. ;)
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] [dovecot] - filters
On Thu, 2010-03-04 at 17:46 -0600, Rick Romero wrote:
Quoting Karsten Bräckelmann guent...@rudersport.de:
# Force-inject [Dovecot] Subject tagging, just because I insist on the
# list traffic hitting my Inbox, and am unwilling to filter it.
:0 fw
* ^List-Id: .*Dovecot Mailing List
* ! ^Subject: .*\[Dovecot\]
* ^Subject: \/.*
* ! ^Subject: Re:\/.*
Corrected quoting, I did not write that last line.
I don't think it does what you intend anyway, unless you want to prevent
the Subject tagging, if the Subject begins with a Re: marker. Also, I've
never used the \/ match buffer in a negated condition, but my gut
feeling is that it will make the original intent fail.
| formail -I Subject: [Dovecot] ${MATCH}
Added partial Re: adjuster - Use a 2nd recipe for the Subject: Re: [Dovecot] ?
THANK YOU! :)
You're welcome. :)
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] [dovecot] - filters
Quoting Karsten Bräckelmann guent...@rudersport.de: On Thu, 2010-03-04 at 17:46 -0600, Rick Romero wrote: Quoting Karsten Bräckelmann guent...@rudersport.de: # Force-inject [Dovecot] Subject tagging, just because I insist on the # list traffic hitting my Inbox, and am unwilling to filter it. :0 fw * ^List-Id: .*Dovecot Mailing List * ! ^Subject: .*\[Dovecot\] * ^Subject: \/.* * ! ^Subject: Re:\/.* Corrected quoting, I did not write that last line. I don't think it does what you intend anyway, unless you want to prevent the Subject tagging, if the Subject begins with a Re: marker. Also, I've never used the \/ match buffer in a negated condition, but my gut feeling is that it will make the original intent fail. Oh, I thought the backslash was escaping the / .. I was just going by an example I had - even though now that I think about it, that really makes no sense. \o/ In any case, yes, I want to skip Matching replies, because otherwise you won't match how the system prepends [Dovecot] now. For example. Subject: This is a test is replied to and becomes: Subject: Re: This is a test I would think those of us who prefer to have the prefix would want: Subject: Re: [Dovecot] This is a test and not Subject: [Dovecot] Re: This is a test Now, If I replied to the second one, it would become Subject: Re: [Dovecot] Re: This is a test and that would really hose things up. Of course, were I to do that, YOUR threading might get all hosed up because all of a Sudden there's a subject change. Yes, I know there's a header for threading, but I'm not sure what MUA's respect it. So I think 2 recipes are required - 1. Marks 'original' not prefixed Subjects - prefix is '[Dovecot]' 2. Marks replied not prefixed Subjects - prefix is 'Re: [Dovecot]' So like: :0 fw * ^List-Id: .*Dovecot Mailing List * ! ^Subject: .*\[Dovecot\] * ! ^Subject: Re:.* * ^Subject: \/.* :0 fw * ^List-Id: .*Dovecot Mailing List * ! ^Subject: .*\[Dovecot\] * ^Subject: Re:.* I assume $MATCH would be the last conditional. I think overall - whether we add or remove the prefix via local filter, someone is going to have issues with it :) Rick
Re: [Dovecot] [dovecot] - filters
On 3/4/10 7:07 PM -0600 Rick Romero wrote: For example. Subject: This is a test is replied to and becomes: Subject: Re: This is a test Unless you use a mailer which uses something besides Re:, say Aw: -frank
Re: [Dovecot] Limit login attempts per connection?
On 3/4/10 6:42 PM -0500 Tony Nelson wrote: Looking at the source, I see that there are no options. It tarpits a bit, but currently has no limit on the number of attempts. I'll see what I can do. I think it's a brilliant idea. After one login attempt, all others on the same connection should fail. -frank
Re: [Dovecot] [dovecot] - filters
On Thu, 2010-03-04 at 19:07 -0600, Rick Romero wrote:
Oh, I thought the backslash was escaping the / .. I was just going by
an example I had - even though now that I think about it, that really
makes no sense. \o/
In any case, yes, I want to skip Matching replies, because otherwise
you won't match how the system prepends [Dovecot] now.
The system (mailman) prepends the tag, if there is none. Period.
You simply cannot make that work exactly the same on your end. Because
it is the mailing list software, that does it currently -- before
sending out the mail. Exactly the same for everyone. If *you* will do
it, it will break the exact moment someone else does it on his end, too.
But does not use the exact same recipe as you do...
Of course, if you happen to send a mail without the tag, but starting
Re:, mailman will in fact inject the tag before the Re:...
Subject: Re: This is a test
Re: RE: Re[4]: Re: Fwd: Antw: Re: Real Subject hidden over here
I've seen it all. And even more variants.
I would think those of us who prefer to have the prefix would want:
Subject: Re: [Dovecot] This is a test
and not
Subject: [Dovecot] Re: This is a test
You will get both. The first one is an example replying, after adding
the tag. The second is an example in your Inbox *shudder* [1] of someone
not adding the stupid tag on his client side end, but you adding it.
Now, If I replied to the second one, it would become
Subject: Re: [Dovecot] Re: This is a test
You are free to modify the Subject and get rid of one of those.
You are free to reply to the list, and not Cc me personally. I do read
the list, you know...
and that would really hose things up. Of course, were I to do that,
YOUR threading might get all hosed up because all of a Sudden there's
a subject change. Yes, I know there's a header for threading, but I'm
not sure what MUA's respect it.
ANY even half-decent MUA does respect these headers. References and
In-Reply-To. My threading will not be messed up, even if you change the
Subject entirely.
Of course, my threading is being messed up by someone actually replying,
but not realizing that deleting the entire body and subject will not
generate a fresh message, but still is a reply -- but this is an
entirely unrelated story. ;)
So I think 2 recipes are required -
1. Marks 'original' not prefixed Subjects - prefix is '[Dovecot]'
2. Marks replied not prefixed Subjects - prefix is 'Re: [Dovecot]'
IMHO, none is required. This whole concept of Subject tagging is utterly
broken and useless. There are headers for that your MDA or MUA can use
for filtering, sorting or any other kind of logic the user requires,
just because he doesn't filter into dedicated folders.
I assume $MATCH would be the last conditional.
Now you lost me. $MATCH is the content you previously captured with the
\/ start matching here. It is not a condition.
I think overall - whether we add or remove the prefix via local
filter, someone is going to have issues with it :)
True. There's always someone who will complain.
[1] Yes, I am strictly against keeping ML bulk in your Inbox, just
because your retarded MUA (which hardly is worth that name) on your
phone can't handle folders.
This is an IMAP server list. Do filter server side. No excuse.
--
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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] Limit login attempts per connection?
On 10-03-04 20:22:15, Frank Cusack wrote:
On 3/4/10 6:42 PM -0500 Tony Nelson wrote:
Looking at the source, I see that there are no options. It tarpits
a bit, but currently has no limit on the number of attempts. I'll
see what I can do.
I think it's a brilliant idea. After one login attempt, all others
on the same connection should fail.
A fan! Anyway, there should at least be a choice. Not that I've coded
a choice, just a dumb patch -- see attachment. It's a bit of a
compromise, with a hard-coded limit of 4 attempts. Maybe I'll lower it
to 2.
--
TonyN.:' mailto:tonynel...@georgeanelson.com
' http://www.georgeanelson.com/
--- dovecot-1.2.10/src/pop3-login/client-authenticate.c.limitauth 2010-01-24 18:14:17.0 -0500
+++ dovecot-1.2.10/src/pop3-login/client-authenticate.c 2010-03-04 23:08:07.0 -0500
@@ -21,6 +21,7 @@
#define POP3_SERVICE_NAME pop3
#define AUTH_FAILURE_DELAY_INCREASE_MSECS 5000
+#define AUTH_ATTEMPT_LIMIT 3
const char *capability_string = POP3_CAPABILITY_REPLY;
@@ -244,8 +245,12 @@
case SASL_SERVER_REPLY_AUTH_FAILED:
case SASL_SERVER_REPLY_AUTH_ABORTED:
if (args != NULL) {
- if (client_handle_args(client, args, FALSE, nodelay))
+ if (client_handle_args(client, args, FALSE, nodelay)) {
+/*GAN 04Mar10 restrict auth attempts */
+if (client-common.auth_attempts AUTH_ATTEMPT_LIMIT)
+client_destroy(client, Too many auth attempts.);
break;
+}
}
if (reply == SASL_SERVER_REPLY_AUTH_ABORTED)
@@ -256,8 +261,12 @@
msg = t_strconcat(-ERR , data, NULL);
client_send_line(client, msg);
- if (!client-destroyed)
+ if (!client-destroyed) {
+/*GAN 04Mar10 restrict auth attempts */
+if (client-common.auth_attempts AUTH_ATTEMPT_LIMIT)
+client_destroy(client, Too many auth attempts.);
client_auth_failed(client, nodelay);
+}
break;
case SASL_SERVER_REPLY_MASTER_FAILED:
if (data == NULL)
Re: [Dovecot] Mailing list's prefix
* Timo Sirainen t...@iki.fi: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. -1 I don't need any [tag] for filtering, that's what plus'd addresses or List-Id headers are for. My _brain_ relies on a [tag], especially if I want to continue an interesting discussion, which has a poor Subject:, off list/in private. 99,9% of the few spams I receive are in English, so I'm pretty fast when it comes to deleting English messages with non-obvious Subject: headers. The [tag] helps a lot with that. Stefan
Re: [Dovecot] Mailing list's prefix
On Fri, Mar 05, 2010 at 12:45:45AM +0200, Timo Sirainen wrote: On 4.3.2010, at 22.59, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Well, it's beginning to sound like there are non-filtering reasons why the prefix can be good. So I guess it's better to keep things the way they are now :) Hrm. I guess I'm too late for the voting, then. I use tagged addresses (envelope recipient) to control routing into folders. I would like to see the prefix go away. (I know it doesn't look like it, because I use this same address as posting address on numerous mailing lists. But I generally set it NOMAIL after subscribing, and I read through a different address.) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dovecot] Mailing list's prefix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010-03-05 07:49, Karsten Bräckelmann wrote: On Fri, 2010-03-05 at 00:45 +0200, Timo Sirainen wrote: On 4.3.2010, at 22.59, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. Well, it's beginning to sound like there are non-filtering reasons why the prefix can be good. So I guess it's better to keep things the way they are now :) I don't recall any, other than plain refusal to use a dedicated folder, rather than dumping it all into the Inbox... IMO, Michael M. Slusarz had a valid reason: [...] a common situation (at least for me) is someone who replies directly to your message from a list instead of to the list address. This will most likely cause that message to end up in your INBOX rather than being filtered into the appropriate mailing list mailbox. Having the list name in the Subject can be useful to visually filter these incoming messages in your INBOX, rather than potentially deleting/marking as spam since often times you may not recognize the sender. I'm ok with both ways, but given that there is a considerable amount of opposition, I think Timo's decision to keep it as it is will work best. Patrick. - -- STAR Software (Shanghai) Co., Ltd.http://www.star-group.net/ Phone:+86 (21) 3462 7688 x 826 Fax: +86 (21) 3462 7779 PGP key E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkuQnlIACgkQ7yMg/OiDoAXXZwCffZWVAYq4sYp8LIaCsaOtL/Bc /n8AniFyZx68KfWAgrdUGGST/97UGsW3 =pG8R -END PGP SIGNATURE-
Re: [Dovecot] Mailing list's prefix
On Thu, 2010-03-04 at 22:43 +0100, Marcus Rueckert wrote: On 2010-03-04 22:59:59 +0200, Timo Sirainen wrote: Do you think I'd break a lot of people's filters if I removed the prefix? :) Anyone strongly for/against removing it? It seems kind of annoying to me whenever I happen to think about it. personally i like the prefixes. especially to sort off list replies when looking through the inbox. so -1 from me on removing. darix -1 for me too, best to keep things the way they are Timo, basically all lists i'm on use tags and I think its good practise to keep. of the myriad of lists im' on and have been on for many many years, only nanog and bind lists dont use tags. lastly, as they say, if it aint borked, dont fux it :) attachment: stock_smiley-1.png
