Re: [Dovecot] Getting started with sieve and conversion from procmail
On Tue, 2011-11-15 at 19:00 -0500, Alex wrote:
DELIVER=/usr/libexec/dovecot/deliver
:0 fhW
| $DELIVER -m xspamtest
Do you really want the pipe to be a (f)ilter? What do you expect deliver
to pass back? And you're feeding deliver the mail (h)eaders only,
dropping the body.
--
char *t=\10pse\0r\0dtu\0.@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] Getting started with sieve and conversion from procmail
On Wed, 2011-11-16 at 20:42 -0500, Alex wrote:
[...]
Unrelated to other dovecot specific questions...
Is there an index file that dovecot-lda updates for imap?
Yes. Which would be the advantage of using dovecot deliver, directly or
called from procmail.
Can I just eliminate it entirely and just have procmail do all the
delivery?
Yes, you can.
In fact, that's what I usually still use. Procmail can just do much more
than sieve. And procmail doesn't scare me as much as sieve. But then
again, I like Perl... And I've never yet encountered a problem with
dovecot IMAP updating indexes on the fly -- which it does, unless
deliver does it incrementally.
However, wasn't your original question about converting procmail recipes
to sieve? (Yes, it was.) So what would hold you back of just not
converting?
--
char *t=\10pse\0r\0dtu\0.@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] Is this really a user agent issue?
On Wed, 2010-12-22 at 09:34 -0500, Phil Howard wrote:
2010/12/21 Karsten Bräckelmann guent...@rudersport.de:
Creating the new mail folder is entirely on the IMAP server side. The
MUA (Evolution in your stated case) is irrelevant. If the creation of
the new folder fails, it is a server side problem.
However, once a new folder has been created (server side, mind you),
Evolution won't know about that folder until it is restarted. Probably
the same with other MUAs, too. In the worst case, restarting Evo twice
should show the new folder.
(That is assuming you are not limiting your MUA to subscribed folders
only, or, as IIRC is the default, deliver auto-subscribes the user to
the just created folder.)
Then I would call this a user agent issue.
You snipped the part of your OP where you stated that dovecot deliver
fails creating a mail folder. This is NOT an MUA issue.
If IMAP provides a way for
the user agent to discover the folder already exists, then the user
agent should do this, at least if an error is encountered when trying
to create it. Evolution clearly does not (or doesn't act on knowing
if it does). Other user agents, I don't know. But it is simple
logic:
There is a way for the MUA to discover folders existing, LIST. Existing
on the IMAP server, mind you, again. So this is not an MUA limitation.
Also, MUAs don't care about the full list of folders, if they are in
subscription mode. In that case, they ask for subscribed folders, LSUB,
not all folders.
Which method do you use? (That's a client option.)
if (create folder $name succeeds) OR (folder $name can be accessed) then
set up local reference to folder $name
This is unrelated. *sigh* In your case, the creation is server side.
And yes, unless you use subscription only, Evo does exactly that on the
next start -- ask for all folders on the server.
else
report error about creating folder $name
endif
Impossible. The error creating the folder occurred on the server, during
delivery, which does not even need to be doveot deliver but any number
of other MDAs.
Either way, no client needs to be running while mail is being delivered,
and often is not. The server just does not even tell the client about a
failure, even *if* it potentially could know about that. This was purely
a server-side operation and failure, and the client, any client, is not
going to be informed about it.
Only a successfully created folder will be known to the MUA during the
LIST command.
That, of course, depends on IMAP having a means to detect if the
folder exists (even though the folder was not given in a previous list
of existing folders). Trying to open it should be a way to do that
test.
Yes, the IMAP server does detect new folders.
Trying to open it sounds like a client action -- in which case it is
just wrong, because the client cannot even try opening something it
never knew before existed. Other than brute-force trying all possible
char combinations...
But if the IMAPD process itself can't or won't even try to access that
folder because it wasn't in the list when it started, then I see that
as a server side issue, or if the protocol doesn't provide any such
means to ask for a folder not previously seen, then I see that as a
protocol design issue.
Wow, you really do know what you're talking about, don't you? *sigh*
In a nutshell: Failure to create a folder at delivery time is NOT an MUA
issue. And whether or not the user will see new folders created
successfully depends on (not) limiting to subscribed folders, and the
subscription list stored on the server.
Basically, exactly what I wrote in my first reply. Mind reading that
carefully again?
--
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] Is this really a user agent issue?
On Tue, 2010-12-21 at 14:48 -0500, Phil Howard wrote:
I suspect this is a user agent issue, given that Evolution is flaky in
so many areas. When I deliver mail to a subfolder/subbox (e.g. the -m
option in the deliver command), and Evolution doesn't know of it, yet,
creating it fails, and Evolution still can't get to it. Doing things
Creating the new mail folder is entirely on the IMAP server side. The
MUA (Evolution in your stated case) is irrelevant. If the creation of
the new folder fails, it is a server side problem.
However, once a new folder has been created (server side, mind you),
Evolution won't know about that folder until it is restarted. Probably
the same with other MUAs, too. In the worst case, restarting Evo twice
should show the new folder.
(That is assuming you are not limiting your MUA to subscribed folders
only, or, as IIRC is the default, deliver auto-subscribes the user to
the just created folder.)
the other way around (create it in Evolution first, then deliver to
it) works fine. Seems to be silliness to me. Just wondered if any
Dovecot aspects might be involved ... such as the fact that the case
is different (e.g. INBOX in the filesystem, but Inbox in
Evolution).
--
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] mail.err
On Tue, 2010-12-07 at 16:58 -0500, Charles Marcus wrote:
On 2010-12-07 4:45 PM, Paul Cartwright wrote:
I keep getting this error, and I have no clue where it comes from. I
have no localhost in my fetchmailrc file, all I have in main.cf is:
mydestination = paulandcilla.homelinux.org, localhost
And you think this is dovecot related because... ?
*grin*
Dec 7 16:00:38 paulandcilla fetchmail[16761]: connection to
localhost:smtp [::1/25] failed: Connection refused.
Even though this *really* is not related to dovecot at all, while we're
here, I might as well try to help nonetheless -- failing with an IPv6
address does look familiar. I don't recall the log messages, since I
mostly debugged with fetchmail directly.
The below fetchmailrc settings, including the comment, are directly
scraped from a machine I set up for a friend a while ago...
defaults
smtphost 127.0.0.1
smtpaddress localhost
# Need the smtp settings above, to get rid of some warnings due to trying the
# IPv6 localhost address first. Or to inject IPv6 addresses in the Received
# headers, if enabled in postfix.
# In short: Do use IPv4, but still append localhost rather than the bare IP as
# the domain, when submitting via SMTP locally. *sigh*
--
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] mail.err
On Tue, 2010-12-07 at 17:16 -0500, Paul Cartwright wrote:
On 12/07/2010 04:58 PM, Charles Marcus wrote:
I keep getting this error, and I have no clue where it comes from. I
have no localhost in my fetchmailrc file, all I have in main.cf is:
mydestination = paulandcilla.homelinux.org, localhost
And you think this is dovecot related because... ?
no, I'm not sure what it is related to. I run dovecot, and postfix.
The log snippet clearly shows that it is fetchmail generating the
message. For some reason, it cannot connect to the localhost IPv6
address for delivery via SMTP.
I believe the solution is either (a) to fix your fetchmail conf, or
(b) to have postfix listen on IPv6 addresses.
--
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] mail.err
Please *do* keep the thread on the list, by replying to the list only.
On Tue, 2010-12-07 at 18:07 -0500, Paul Cartwright wrote:
On 12/07/2010 05:25 PM, Karsten Bräckelmann wrote:
Even though this *really* is not related to dovecot at all, while we're
here, I might as well try to help nonetheless -- failing with an IPv6
address does look familiar. I don't recall the log messages, since I
mostly debugged with fetchmail directly.
I don't think I am using IPv6, actually I KNOW I'm not using it, I'm
pretty sure I turned off that functionality.. I don't think my router
supports it..
I KNOW I didn't try to add that functionality to either fetchmail,
Postfix or Divecot!
As I mentioned in another post, your log message clearly shows the IPv6
address is being used. And yes, your host obviously is capable of that.
You don't need to specifically enable it with fetchmail. It will under
certain circumstances default to IPv6, which in your case happened. As
also mentioned, your postfix seems to not bind to the IPv6 address by
default, though, or it has deliberately been disabled.
Moreover, your router is not even in the picture here -- just like
dovecot, FWIW. Fetchmail fetches the mail from a remote server, and
tries to deliver it locally. That local delivery step is generating the
log messages. A mail, sent from and to your box. Long after the data
stream passed your router...
[ long snip, including your fetchmailrc general settings ]
I will add what you have there, and see what happens, thanks!
--
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] mail.err
On Tue, 2010-12-07 at 23:31 +, Jamie Paul Griffin wrote:
The log snippet clearly shows that it is fetchmail generating the
message. For some reason, it cannot connect to the localhost IPv6
address for delivery via SMTP.
I believe the solution is either (a) to fix your fetchmail conf, or
(b) to have postfix listen on IPv6 addresses.
the op posted this on the postfix list just now and was advised to
check that postfix is configured to listen on ipv6. something along
like having inet_protocols = all in /etc/postfix/main.cf should do it.
*nod* Back those days I opted for the fetchmail use IPv4 localhost
fix, to avoid a single local Received header showing an IPv6 address. :)
Thanks for the note. Although I'm not happy to see the OP used the
shotgun approach to get help...
--
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] mail.err
On Tue, 2010-12-07 at 18:29 -0500, Paul Cartwright wrote:
On 12/07/2010 05:25 PM, Karsten Bräckelmann wrote:
here, I might as well try to help nonetheless -- failing with an IPv6
address does look familiar. I don't recall the log messages, since I
mostly debugged with fetchmail directly.
I have never used IPv6, never set it up, I don't think my router can
handle it..
As I keep repeating -- your server is capable of IPv6, and it was a
localhost only delivery. Your router is even less than irrelevant here.
The below fetchmailrc settings, including the comment, are directly
scraped from a machine I set up for a friend a while ago...
defaults
smtphost 127.0.0.1
smtpaddress localhost
thanks, I added those 2 lines, that seems to have fixed it!
Glad to hear. :)
I guess eventually I'll have to add IPv6 capability, but that might mean
I have to get a new router..
This still is unrelated to your original problem.
--
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] mail.err
On Wed, 2010-12-08 at 00:02 +, Jamie Paul Griffin wrote:
*nod* Back those days I opted for the fetchmail use IPv4 localhost
fix, to avoid a single local Received header showing an IPv6 address. :)
me too :-)
Thanks for the note. Although I'm not happy to see the OP used the
shotgun approach to get help...
indeed but it's not then end of the world. good job there are nice folk
on this list to help out.
True. And as one probably could gather from my first response, I prefer
to just solve the issue, even if the choice of list was misguided. Guess
I mostly got annoyed by the repeated claim of not using IPv6, despite
the clear evidence.
Also, regarding dovecot, I am mostly a lurker -- usually chiming in in
related though actually off-topic issues. ;)
--
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] Ongoing performance issues with 2.0.x
On Wed, 2010-11-17 at 20:55 +0100, Ralf Hildebrandt wrote:
my ($type, $data) = ($1, $3);
to
my ($type, $data) = ($1, $4);
since I added another pair of ()
Just use non-capturing grouping instead. (?:foo)
--
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] Single-instance storage is bad for you!
On Mon, 2010-11-15 at 16:27 -0600, Stan Hoeppner wrote:
Then apparently you didn't read the thread. The OP told his users long
ago do this. Then he made a change and told them [...]
No, he did not.
This thread lost its funny long ago. It started off quite amusing, the
first two posts have been humorous (in case you didn't notice), then
Stan entered the thread. Too bad to see a nice thread die that quickly.
--
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] fallocate and glibc 2.10
On Sun, 2010-10-24 at 18:02 -0500, Stan Hoeppner wrote:
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no
need to fix it for that. Didn't realise that glibc 2.10 was that rare.
How old is glibc 2.10?
I thought Debian Lenny (which I use) was old. It's approaching two
years since release. It currently has glibc 2.7, which was apparently
released in 2007, 3 years ago. This would lead me to belive that glibc
2.10 is _very_ old. I'm not very familiar with glibc. Maybe age
doesn't matter?
It's a version number, generally major.minor.micro. It's not a floating
point number.
7 10, and thus 2.7 is older than 2.10.
--
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] ATTN: David Miller Re: Config review (2.0.5)
On Sun, 2010-10-10 at 17:57 -0400, Jerrale G wrote:
On 10/7/2010 8:16 AM, Ralf Hildebrandt wrote:
fts = squat
I'm probably talking out of the wrong hole again - but have you tried
removing squat from your plugin list to see if it makes a difference?
Daniel Miller,
Please do not get all defensive when someone asks why they're having
performance issues. You act like he said Because of dovecot, i'm having
POP3 or IMAP performance problems. He only said he noticed a change
since going to 2.0.5. You could have suggested to try disabling all the
plugins and then enabling each one until he notices a huge performance
decrease, using whatever he was using to benchmark, instead of
ignorantly implying he should have already known to do so.
I don't think he got all defensive, I don't believe he implied anything,
and I don't think his reply was in any wrong. As I understand it, it was
a gut feeling of his, and turned out to be the issue indeed. (As
confirmed a while ago.)
Granted, I mostly lurk here only, and deleted most of this thread
already, but from memory...
Jerrale, dude, you got all defensive. I don't know who is the author of
the squat fts, and I am too lazy to look it up. But unless you are, I
don't really understand your screaming ATTN attribution on-list in the
first place.
Anyway, I don't feel like a flame war. I will try not to contribute to
this thread any further. However, David, err, Daniel -- don't feel bad.
I did not understand your comment offensive in any way, and I believe
the guys originally involved did neither.
This was a strange (sub)thread to read indeed. Back to my recording.
--
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] cur folder e-mails are not shown...
On Fri, 2010-05-28 at 12:55 +0200, Gonzalo Aguilar Delgado wrote:
I realized that I have only e-mails from last 13 days. I see that I have
lots more in the cur folder inside my Maildir folder.
The problem is that I cannot see them.
What can be the problem?
Since you didn't claim you actually are missing mail, just seeing more
on the IMAP server than in your client...
They could be deleted (actually marked for deletion, physically
removed upon expunge). Those would have a T flag in the file name after
the comma. Your MUA Evolution shows them in the Trash (virtual) folder.
They could have been flagged Junk, and only be displayed in the Junk
(virtual) folder.
You could have a search active, hiding some mail.
You could have specifically hidden them. See the View menu.
--
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] Mailing list's prefix
On Fri, 2010-03-05 at 14:01 +0800, Patrick Nagel wrote:
On 2010-03-05 07:49, Karsten Bräckelmann wrote:
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:
Frankly, I disagree. I do receive legit private messages, forked off of
an on-list thread. From various mailing-lists. I would not want them to
be filtered into a dedicated list folder. For that reason, Subject based
filtering is wrong, and the proper mailing-list headers do a perfect job
here.
[...] 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
It is an off-list reply. It doesn't belong in the list folder.
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.
Well, I'd prefer to drop the Subject tagging. But this decision isn't my
call on this list. :)
If it bugs me enough, I can always drop it locally. The procmail recipe
to accomplish that was the important point of my previous post. I didn't
argue about the tagging itself.
guenther
--
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] Mailing list's prefix
On Fri, 2010-03-05 at 09:50 +, Ed W wrote:
I would suggest it might be an over-bold move given that it changes the
requirement to understand your filtering LDA from beginner to
intermediate, [...]
This is an IMAP *server* list. It should be fairly safe to assume mail
admins exceeded the beginner level for their tools...
Should. Reality on a lot of related lists eloquently shows, this is not
the case. :/
--
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
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] 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
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] Wish-list: X-Delivered-To headers generated by dovecot-deliver
On Sat, 2009-10-17 at 22:41 +0200, Andrzej Adam Filip wrote:
a) *clearly* mark POP/IMAP account fetched by fetchmail
[with fetchmail using directly dovecot-deliver in --mda option]
Would the fetchmail tracepolls option not do? It generates a header like
this, including local and remote account info.
Received: from mail.example.net [192.0.0.1] by local-server with POP3
(fetchmail-6.3.4 polling mail.example.net account user) for
local-u...@localhost (single-drop); Sat, 17 Oct 2009 22:42:27 +0200 (CEST)
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;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] antispam-plugin 1.2 and trailing carriage-returns
*nudge* Anyone? Since Timo seems to be on a list processing spree
lately, here's hoping. :)
On Tue, 2009-09-01 at 22:20 +0200, Karsten Bräckelmann wrote:
Guys,
Dovecot 1.0.15 [1], just built the latest antispam-plugin 1.2 (tarball)
for testing, mailtrain backend for SA integration. Both built from
custom spec files.
The mail that is being trained is different than its respective source
in the mbox file. The trained one shows added, trailing carriage-return
chars for all headers, which are not in the headers in the mbox file.
This breaks sa-learn -- both these variations are different, and SA
would learn *both* when run against each one separately.
How comes? Any insight? How could I fix this, other than wrapping the
sa-learn inside another shell script and have sed strip off the noise?
This becomes more of an issue, once I switch from sa-learn to the
lightning-fast spamc training variant.
TIA
guenther
[1] Yes, I know, sorry. Don't want to change everything at the same
time, and the target system I'm experimenting for runs that version,
too.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;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] Wish-list: X-Delivered-To headers generated by dovecot-deliver
On Sat, 2009-10-17 at 23:57 +0200, Andrzej Adam Filip wrote:
Karsten Bräckelmann guent...@rudersport.de wrote:
On Sat, 2009-10-17 at 22:41 +0200, Andrzej Adam Filip wrote:
a) *clearly* mark POP/IMAP account fetched by fetchmail
[with fetchmail using directly dovecot-deliver in --mda option]
Would the fetchmail tracepolls option not do? It generates a header
like this, including local and remote account info.
Received: from mail.example.net [192.0.0.1] by local-server with POP3
(fetchmail-6.3.4 polling mail.example.net account user) for
local-u...@localhost (single-drop); Sat, 17 Oct 2009 22:42:27 +0200
(CEST)
Is there an easy way to use such tracepoll Received: in
1) sieve scripts?
Dunno.
2) procmail scripts?
That's exactly why I originally tracked down the fetchmail tracepolls
option. :)
Easy? Sure, multi-line headers are re-flowed with procmail, so it's a
single-line RE for matching. But since we're talking about procmail,
any answer regarding easy depends on whom you ask... ;)
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Dovecot] antispam-plugin 1.2 and trailing carriage-returns
Guys,
Dovecot 1.0.15 [1], just built the latest antispam-plugin 1.2 (tarball)
for testing, mailtrain backend for SA integration. Both built from
custom spec files.
The mail that is being trained is different than its respective source
in the mbox file. The trained one shows added, trailing carriage-return
chars for all headers, which are not in the headers in the mbox file.
This breaks sa-learn -- both these variations are different, and SA
would learn *both* when run against each one separately.
How comes? Any insight? How could I fix this, other than wrapping the
sa-learn inside another shell script and have sed strip off the noise?
This becomes more of an issue, once I switch from sa-learn to the
lightning-fast spamc training variant.
TIA
guenther
[1] Yes, I know, sorry. Don't want to change everything at the same
time, and the target system I'm experimenting for runs that version,
too.
--
char *t=\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4;
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;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] Multiple mail locations for a single user
Heya, Ross :)
On Sun, 2009-06-07 at 22:01 +0100, Ross Burton wrote:
Is there any way to let me access all three maildirs through dovecot?
I'm guessing that I can do this with namespaces but I'm not sure. Any
suggestions and pointers?
Personally, I use different system users on the IMAP server with similar
setups. Since in your case there is no local MTA involved, which is part
of the picture here...
The best thing about different accounts is, that (per-account) default
sender addresses and options just work.
--
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] === SPAM === test of mailing list
On Wed, 2009-05-27 at 17:16 +0200, Ioannis Aslanidis wrote:
And this may be why:
* 3.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook
Ugh. :/ I've been looking into a FP for that rule recently, though the
issue I spotted is different from these headers. Hmm, and it actually
doesn't trigger that rule for me.
Ah, that would be why. Ioannis, you're running an old version of SA. :)
This is an old FP that's been fixed long ago. Please update your SA
version 3.1.9 to the latest stable available 3.2.5 -- you'll find you
don't need to lower your required_score threshold to 3.5 either.
guenther
--
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] About Status to the header
On Thu, 2009-04-09 at 21:29 +0900, ogu...@yahoo.co.jp wrote:
I'd like to know about Status to the header on dovecot.
I can see the Status to the header in
/var/spool/mail/user
if I check mail by using mutt, but I cannot see Status to
the header if I check mail by using evolution, thunderbird etc.
- /var/spool/mail/user
--
To: t...@test.example.com
Subject: test
Status: RO
The Status header isn't actually part of the email itself, but part of
the IMAP server internal meta data, added by Dovecot.
This one means the mail is Seen (R) and non-Recent (O).
Your MUA won't see other headers neither, like X-Status, X-Keywords,
X-UID or X-IMAPbase.
guenther
--
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] OT: Looking for a robust IMAP client
On Mon, 2008-12-15 at 14:34 -0500, Stewart Dean wrote:
With sigh, I know, I know a mbox format inbox, I don't know that it
matters much whether it's 10 files or 10,000...it's still gotta haul out
the whole ugly thing.
Aha, mbox. And pine is your last resort (as you stated in a follow up)?
formail and procmail are a last resort! ;) Frankly, if you ask me, they
really are not a bad choice for post processing and surgery in mbox
anyway.
guenther -- who hacked a formail-grep wrapper script ;)
--
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] Stopping imap synchronization on spool failure
On Mon, 2008-10-06 at 11:46 -0700, Chris Cappuccio wrote:
Is there any way to tell an IMAP client to not synchronize/delete old mail
through IMAP? Let's say that recent events cause a mail spool to not exist,
but people may still want to see old messages that are already cached on their
machines.
This is a client question, and details depend on your particular client.
Been there myself before. (Please don't ask where all the users Inbox
went.) Possible solutions include
(a) Do NOT start the client, but harvest the local cache. With some luck
they do resemble mbox, Maildir or MH, so you can simply re-create the
server-side lost messages client-side and copy somewhere else for later
importing or re-feeding.
(b) Kick the connection between client and server, start client. You
might be able to simply copy the (cached) stuff to local folders, wile
there still is no connection to the IMAP server.
Alternatively, starting the client in an offline mode might do the
same.
In either case, I suggest getting a copy of the client cache *now*
before starting it. So you can start from scratch and harvest the copied
cache as per (a), in case some other way failed.
Since you explicitly mentioned client caches, option (a) likely would
be the way to go anyway. You got a cache? Harvest it. That's your best
bet. Anything else is just for convenience...
Good luck.
guenther
--
char *t=[EMAIL PROTECTED];
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] Converting from MBOX to Maildir broke procmail and Spamassasin and halted incoming mail
On Wed, 2008-09-17 at 12:39 -0600, Dan Roberts wrote:
I did have success in getting my mail accounts converted from mbox to
maildir, but then ran aground.
I could see all of my existing mail and create new folders, but I
could not see any of my incoming mail.
What I was late in realizing was that I needed to also adjust the
settings for my LDA, which as I am using sendmail is procmail, and it
was suggested that I needed to adjust /etc/procmail to include the line
DEFAULT=$HOME/Maildir/
I did that, but new mail still didn't show up correctly. I can only
assume that I have something still not properly adjusted in my
procmail settings.
[...]
In each users Home directory I have a .procmailrc file that further
directs things on a user level.
For my directory this file is currently
---
[EMAIL PROTECTED] ~]$ cat .procmailrc
MAILDIR=$HOME/mail
PROBABLYJUNK = /home/dan/mail/probably-spam
^^ ^^
:O H
* ^X-Spam-Status:.*Yes
{
EXITCODE=67
:0:
probably-spam
^ ^^
This makes procmail deliver mail into mbox format files. You most likely
want delivery action lines like this:
.probably-spam/
Note the leading dot and the trailing slash. That makes procmail use
Maildir format. You will have to adjust each and every delivery action.
Please see 'man procmailrc'.
Moreover, your ${PROBABLYJUNK} variable doesn't match your ${DEFAULT}.
You'd better not provide absolute, full paths there.
Given the above snippets, I guess procmail actually *did* deliver your
mail. It's just been dumped in mbox format files, which dovecot with
your changed settings doesn't recognize. And probably scattered in
multiple directories...
guenther
--
char *t=[EMAIL PROTECTED];
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] v1.1.0 released
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-sql
-I../../src/lib-settings -I../../src/lib-ntlm -I../../src/lib-otp
-DAUTH_MODULE_DIR=\/usr/local/lib/dovecot/auth\ -DPKG_LIBEXECDIR=
\/usr/local/libexec/dovecot\-std=gnu99 -g -O2 -Wall -W
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2
-MT auth-master-listener.o -MD -MP -MF .deps/auth-master-listener.Tpo -c
-o auth-master-listener.o auth-master-listener.c
make[3]: *** [auth-master-listener.o] Segmentation fault
Check your memory. Last time I had gcc crash like this, the machine was
dieing. Error messages in the mem test where lighting up like a
Christmas tree within seconds.
But if I type just 'make' again after this the build completes
successfully. Everything else is fine. Is this dovecot related?
Maybe an early stage of mem failure, if it does succeed sporadically.
Probably going to change soon, though...
guenther
--
char *t=[EMAIL PROTECTED];
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] deliver saving mails with hard linking
On Sun, 2008-06-01 at 22:32 +0300, Timo Sirainen wrote:
http://dovecot.org/tmp/deliver-multiple.diff for Dovecot v1.1 implements
-p path parameter for deliver, which reads the input mail from the
specified path instead of stdin. With maildir and hardlink copying
enabled, it also tries to hard link the file to destination instead of
copying it.
Wow. ;)
- Am I forgetting something?..
Cleaning up? Quoting the part from option (2) of your previous mail,
which this seems to implement:
All messages could be then stored in some global
directory and hard linked from there to users' mailboxes.
When reading that I already wondered about cleaning up and freeing disk
space. If every recipient deleted their own copy of the mail, the
inodes link count will go down to 1 due to the still existing global
copy. But it will survive despite being deleted (from the collective
users POV), occupying disk space -- and possibly keeping data around
that is assumed to be removed.
Of course, one could periodically check the link counts in yet another
external script, carefully ensuring deliver is not currently doing its
job, and get rid of the stale copies...
guenther
--
char *t=[EMAIL PROTECTED];
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] deliver saving mails with hard linking
On Mon, 2008-06-02 at 00:06 +0300, Timo Sirainen wrote:
I think my previous mail about it described some persistent uniqueness
checks. This patch is only about delivery-time hard linking. If two
different deliveries sent the same message they would be stored using
different files. So the deliver wrapper script would be like:
cat tempfile
deliver -p tempfile -d user1
deliver -p tempfile -d user2
rm -f tempfile
The result would be that user1 and user2 had the same file with link
count 2 and the file is gone when both of them delete it.
Right. Coincidentally, I just got back to check the patch for unlink...
Walking around indeed does help thinking, even though I guess you got
more space than me. ;-)
If either deliver right before finishing or the wrapper script deletes
the source, cleaning up will not be an issue.
guenther
--
char *t=[EMAIL PROTECTED];
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; }}}
[Dovecot] Searching the Archives (was: Re: dovecot developer documentation)
On Thu, 2008-05-15 at 09:25 +0200, Piotr Wadas wrote:
[...] AFAIK there's no search for mailing list archives
available, to let me search for some older guidance in
this case :(
You can use google, by adding site:dovecot.org to the search.
The dovecot list is one of the last fine mailing lists, that offer
archives in monthly (and a full) mbox format archives, suited for
importing into your mail client and searching *really* conveniently
offline and locally.
Also, dovecot.org offers list access by IMAP. :)
See http://dovecot.org/mailinglists.html
guenther
Caveat: I know I should not post before I got a sane dose of
caffeine. ;)
--
char *t=[EMAIL PROTECTED];
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] Security issue #5: mail_extra_groups setting is often used insecurely
On Wed, 2008-03-05 at 00:29 +0200, Timo Sirainen wrote:
a) Upgrade to v1.0.11 and use the new mail_privileged_group setting
instead of mail_extra_groups.
We tried this but now the mail.log has a number of lines :
« dovecot: IMAP(someuser): open(/var/mail/.temp.) failed: Permission
denied »
Oh, this is actually harmless. You can get rid of it (and improve the
performance) by setting dotlock_use_excl=yes.
But maybe I should release v1.0.12 anyway with that error message
silenced..
You mean seeing that error message only is actually not an error,
because the next locking method just works?
In that case, great -- I'll go change dotlock_use_excl, revert the scary
option (b) of chmod world-writable, and see how it works out. Not using
NFS anyway.
guenther
--
char *t=[EMAIL PROTECTED];
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] Security issue #5: mail_extra_groups setting is often used insecurely
On Tue, 2008-03-04 at 23:41 +0100, Karsten Bräckelmann wrote:
On Wed, 2008-03-05 at 00:29 +0200, Timo Sirainen wrote:
Oh, this is actually harmless. You can get rid of it (and improve the
performance) by setting dotlock_use_excl=yes.
But maybe I should release v1.0.12 anyway with that error message
silenced..
You mean seeing that error message only is actually not an error,
because the next locking method just works?
In that case, great -- I'll go change dotlock_use_excl, revert the scary
option (b) of chmod world-writable, and see how it works out. Not using
NFS anyway.
Seems it did the trick, judging by some quick tests. :)
guenther
--
char *t=[EMAIL PROTECTED];
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] Thunderbird Problem - What causes this?
On Sun, 2008-01-27 at 18:04 -0500, Adam McDougall wrote:
Try running a script to run 'netstat' frequently, say once a minute, and
log the port numbers from the connection, example:
TCPreinheitsgebot:3482mail.egr.msu.edu:993 ESTABLISHED
TCPreinheitsgebot:3485mail.egr.msu.edu:993 ESTABLISHED
Cheers! :-)
--
char *t=[EMAIL PROTECTED];
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] Time just moved backwards error even with ntpd
On Sat, 2008-01-19 at 12:46 +0100, Luigi Rosa wrote:
Scenario: server PC abruptly switched off due to power cable problems
(an UPS cannot solve this issue), so during shutdown Linux was not
This sounds like rather extreme, exceptional circumstances. And actually
an infrastructure problem, rather than software. ;)
able to resinchronize the system clock. After a few hours the server
come back on, Linux booted and the services (ntpd, dovecot and many
others) started
But the system clock was 45 minutes ahead, so:
No. :)
Jan 19 11:13:39 gw ntpd[2112]: synchronized to LOCAL(0), stratum 10
Jan 19 11:13:39 gw ntpd[2112]: kernel time sync disabled 0041
Jan 19 11:14:43 gw ntpd[2112]: synchronized to 62.48.35.100, stratum 2
Jan 19 10:31:55 gw ntpd[2112]: time reset -3600.221385 s
Jan 19 10:31:55 gw ntpd[2112]: kernel time sync enabled 0001
Jan 19 10:31:55 gw dovecot: Time just moved backwards by 3600 seconds.
This might cause a lot of problems, so I'll just kill myself now.
http://wiki.dovecot.org/TimeMovedBackwards
Exactly one hour. Doesn't strike me as a coincidence...
guenther
--
char *t=[EMAIL PROTECTED];
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] procmail/formail -- Maildir
On Mon, 2007-12-03 at 11:02 +0100, Andre Huebner wrote:
i switched mailformat from mbox to maildir. Now i have a little
problem with procmail/formail and headermanipulation of mails.
Here an example:
0
* ^From.*gmx.de
| (formail -t -Iprocmail: gmx.de) /var/spool/mail/xx
I would never do it that way anyway. You are bluntly appending the mail
to the raw spool (or mbox file) without any locking. Instead, make
procmail deliver the mail properly, figuring out the correct locking
method.
So, i can add some different headerlines for later evaluation and the
result is attached to inbox.
^
Now i have the problem that i don't know name of targetfile, cause it
is unique for every mail if maildir is used.
^^^
You made that example up, instead of copy-n-paste'ing real life procmail
receipts, right? Isn't the default system spool still an mbox file, even
when using Maildir?
Anyway, again -- let procmail figure out how to properly deliver the
mail. For Maildir storage, just use the directory name, including the
trailing slash. See 'man procmailrc'. Example below.
I did not found a Option or other workaround to solve this case.
I know, it is not a dovecot problem but i hope somebody can give a
hint.
Could it be a possibility to leave all unchanged? Mails could be
transported to /var/spool/mail/xx and picked up by dovecot if in
dovecot.conf the convert-plugin ist always activated?
No. At the very least you need to tell procmail you are using Maildir
instead if mbox for any delivery receipt.
Note: Example untested.
# Set the Maildir prefix, and have the Inbox in there, too.
MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
# Filter through formail, appending some custom header.
:0 fw
* ^From.*gmx.de
| formail -I X-procmail: gmx.de
# Keep mailing list traffic out of my Inbox. Let procmail care about
# proper locking.
:0 :
* ^List-Id: .+dovecot.dovecot.org
.mailing-lists.dovecot/
# Someone loves me. :) Whatever survived till this point will get
# delivered to the $DEFAULT Maildir.
Now, some words about that obscure tagging with formail. :)
Since you are using procmail with gmx.de (which does offer POP3 only for
free) I assume you are harvesting your mail using fetchmail.
Also, I assume the above example isn't actually what you use. It feels
rather useless to add a custom header for that. Your receipt above will
match on any From: header with a gmx.de substring, too. Which includes
the real name. Besides, you can directly evaluate that header anyway...
I guess you actually mean to tag all mail fetched from the gmx.de POP3
account. In that case, have a look at the fetchmail tracepolls option.
It will add info like polling $server account $user to the procmail
generated Received: header. You can directly filter on that header using
procmail, instead of a custom added one. If this is your use case, the
tracepolls option is the only accurate method anyway. Short of using
dedicated local users. ;)
HTH
guenther
--
char *t=[EMAIL PROTECTED];
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] procmail/formail -- Maildir
Please resist the urge to top-post.
On Mon, 2007-12-03 at 13:58 +0100, Andre Huebner wrote:
Sure, its just a modified example. Reason is to mark mails later graphical
in a webmailer using some procmail/formail technics.
Well, if the fetchmail tagging technique actually matches your use case,
of course depends on my assumptions being correct. ;) If so, it will
certainly be cleaner, more accurate, and much lighter on your machine.
It certainly seems to to me. However, you didn't confirm it yet.
Other than that, you probably want to look into your existing procmail
receipts for lurking problems and unwanted matching. Given the modified
example you posted.
The bad thing about majorly rewriting existing code that you actually
want to be discussed is, that those who want to help you have to guess.
If need be, just mask the actual match, x-ing out alphanumeric-strings
for privacy reasons. Depending on the topic, even changing an IP address
can be harmful and lead to false advice -- or a problem description,
that just doesn't make sense.
I think, if i activate the dovecot convert plugin nothig of my procmail must
be changed. (just only the bugs ;) ) Mails will be deliverd in mbox format
to /var/spool/mail/x
The beauty of procmail is, that it can pre-sort your mail. And yes, it
does work perfectly with Dovecot. :) If you want your mail to be sorted
or classified, why not just let procmail do it?
On Userlogin dovecot is picking up Mails and deliver them to maildir-inbox.
Don't know if this is a very Feasible way, not really clean...
Well, frankly, this is a totally unnecessary step. Since you are using
procmail anyway, just let it deliver the mail into the users Inbox. Why
have the mail being delivered twice?
http://wiki.dovecot.org/Plugins/Convert?highlight=%28convert_mail%29
Also, this plugin is not meant for delivery as you stated above. AFAIK
it is used to *convert* (sic) existing mbox format mail stores into
Maildir. Which pretty much should be a single task per user. OTOH
without looking through the wiki, there is another plugin, snarf or
something to do just that -- harvest an mbox spool, and deliver it to
the actual Inbox.
Even worse, since convert runs once each login, the user will *not* get
any new mail, while being logged in. It won't be before he logs out and
in again, that he will get his mail actually delivered while the user
was idling.
Again, using procmail for local delivery anyway, there is no need for
the snarf plugin either...
guenther
--
char *t=[EMAIL PROTECTED];
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] 1.0.8 install trouble on Ubuntu dapper (PAM)
I found a page on the web saying I might need the pam-devel package,
but that doesn't seem to exist for ubuntu.
I saved the output from ./configure, grepped for pam, and got:
checking for pam_start in -lpam... no
Yup, that needs to be yes.
Any ideas? What do I need to get configure to do pam support?
The pam devel package. :-)
In the debian based world, the equivalent of *-devel packages are named
*-dev. So yes, basically you need exactly what you read about. Just with
a slightly adjusted package name. (The exact package name varies on
distro. Hence, in the RPM world usually the suffix devel is used.
However, added lib prefixes and version numbers do differ frequently.)
A quick google search for ubuntu dapper pam dev seems to suggest, the
package you want is... *drumroll*
libpam0g-dev - Development files for PAM
Have fun...
guenther
--
char *t=[EMAIL PROTECTED];
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 loading during boot
On Wed, 2007-11-21 at 21:33 -0700, Robert W Nocella wrote:
I have two RHEL4 email servers running postfix/MailScanner which use
dovecot. They work great. But during bootup the nfslock script in my
init.d loads rpc.statd and calls portmap to get a port number. Portmap
keeps giving rpc.statd the imaps port number (993). I then have to stop my
The default for rpc.statd actually should be random, rather than a fixed
port...
mail server services, manually start dovecot, then restart the mail server
services and everything goes merrily on its way. Stopping the mail server
services drops rpc.statd from using port 993(according to netstat -tlnp).
This allows dovecot to take it by default. How to I reserve imap and imaps
ports exclusively for use by dovecot. The imap and imaps ports are listed
in /etc/services. Thanks for any insight.
The question is not how to reserve port 993 -- but how to make
rpc.statd (or most of the NFS stack for that matter) behave nicely, and
use a dedicated, fixed port instead of a random one. Since you are
ending up with the same port always, it is likely that this has been
configured to work that way. Not that 993 would be a sane choice,
though...
I once documented how to pin down NFS ports, though for a different
reason. ;) However, it should help you to adjust the port in your case,
too. See the AllowNFS action and documentation here:
http://lists.shorewall.net/~kb/
Please note, that this particular documentation applies to RH style
distros only (including Fedora and Mandriva). It's slightly different
for Debian. And impossible for SuSE out-of-the-box, given their
braindead [1] init scripts.
guenther
[1] Yes, that is a technical term. ;)
--
char *t=[EMAIL PROTECTED];
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 loading during boot
[ adding the list back to Cc ]
On Thu, 2007-11-22 at 14:28 +0100, Marcus Rueckert wrote:
On 2007-11-22 13:31:59 +0100, Karsten Bräckelmann wrote:
And impossible for SuSE out-of-the-box, given their
braindead [1] init scripts.
what is so braindead about it?
See these posts, the second one in particular. Also, my original
Shorewall rules and documentation might be interesting.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03986.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03985.html
Please note that the initial reason for the above pinning down NFS ports
is firewall-friendly behavior and sane rules. With NFS, most involved
services use random ports by default, particularly statd, lockd, mountd,
rquotad. Which leads to somewhat unsatisfying rules as shown in [1].
The init script shipped by SuSE offers no way whatsoever to pass
rpc.statd options, even though it does for rpc.mountd -- and thus no way
to pin down the port out-of-the-box short of hacking the init script.
Marcus, please feel free to keep me posted on this issue and a fix. I'll
happily forward updates to the Shorewall lists.
guenther
[1] http://shorewall.net/ports.htm#NFS
--
char *t=[EMAIL PROTECTED];
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; }}}
[Dovecot] OT: NFS ports (was: Re: dovecot loading during boot)
On Thu, 2007-11-22 at 16:38 +0100, Marcus Rueckert wrote:
On 2007-11-22 15:12:22 +0100, Karsten Bräckelmann wrote:
And impossible for SuSE out-of-the-box, given their
braindead [1] init scripts.
what is so braindead about it?
See these posts, the second one in particular. Also, my original
Shorewall rules and documentation might be interesting.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03986.html
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03985.html
Please note that the initial reason for the above pinning down NFS ports
is firewall-friendly behavior and sane rules. With NFS, most involved
services use random ports by default, particularly statd, lockd, mountd,
rquotad. Which leads to somewhat unsatisfying rules as shown in [1].
The init script shipped by SuSE offers no way whatsoever to pass
rpc.statd options, even though it does for rpc.mountd -- and thus no way
to pin down the port out-of-the-box short of hacking the init script.
which is not that correct. all nfs related init scripts are marked
config. hence all change you do to the init scripts will be preserved on
upgrades, as long we dont change the init script. if the init script got
changed it will copy your file to foo.rpmsave and put the new file in
place. you can later merge your changes into the new file. anyway
This is irrelevant. I did not claim the changes would be overwritten.
The point is not about this being impossible, but about confusing and
inconsistent options.
Following your logic -- why the need for $MOUNTD_PORT in the first
place? Or rather /etc/sysconfig/nfs altogether, since you always can
edit the init script...
there are many sysconfig variables for nfs already. if you see the need
for more the best thing would be to open a bug.[1]
Sorry, won't. I am not a SuSE user and not going to argue about this on
bugzilla. Also, I'm not complaining either, merely pointing out the
options.
hope this helps
Actually, it doesn't. :) There's still the need to edit the init
script, even though there is an options file intended solely for the
purpose of avoiding this and keeping your settings in a sane place.
guenther - who got his share of bugzilla accounts already
--
char *t=[EMAIL PROTECTED];
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; }}}
