On 08.02.22 15:37, Sami Ketola wrote:
Maybe you should check the extdata plugin for pigeonhole:
https://doc.dovecot.org/configuration_manual/sieve/plugins/extdata/
I had seen that. But after reading that page it appeared to my rather as
a lookup for static data, e.g. the vacation message
Hi,
is there a way to lookup the action for an incoming mail, especially
which folder to move the mail in, in a database?
Given Problem:
I want to replace the mda mailfilter/maildrop with dovecot/sieve.
The mailfilter script is rather short, but looksup the destination
folder by
t help.
Hadmut
On 24.08.2015 15:28, Maarten Bezemer wrote:
>
> On Sun, 23 Aug 2015, Hadmut Danisch wrote:
>
>> astonished to see, what problems come with Maildir++ and how complicated
>> dovecot tries to deal with them.
> ..
> [fast fwd to "solution"]
>
>> IN
Hi,
I am trying to deal with the problem, that under regular mbox format a
path can lead to either a file or a directory, but not both, while under
IMAP, a path is usually both, a message folder containing subfolders.
I found dovecot's approach to this problem, the Maildir++ layout
described
On Mon, Feb 24, 2014 at 12:54:51AM +0100, Reindl Harald wrote:
you described nothing relevant
You're quite ignorant and obviously don't understand the background.
you only talk why 127.0.0.1 is treated as secured
well because it is by definition, if you don't trust
127.0.0.1 you have
Hi,
although dovecot is great and almost exactly solving my problems and
fitting my requirements, there is an odd detail that causes me problems:
The %c variable. (See http://wiki2.dovecot.org/Variables )
I'm managing an IMAP server for an association, which is connected to an
LDAP server.
On Sun, Feb 23, 2014 at 11:37:55PM +0100, Reindl Harald wrote:
what headache?
The one I've described.
how do you imagine a man-in-the-middle-attack on 127.0.0.1
You're confusing the different attacks. This has nothing to do with a
man-in-the-middle. This is against a passive
On 22.10.2011 10:15, Dennis Guhl wrote:
It's required for debugging purposes, writing mail filters, create
blacklist filters from detected spam, etc.
Disregarding end users mail filters this are all tasks for mailadmins
which can tell thier MTA to write a reliable Return-Path: header and
I don't believe it does make much sense to ask technical questions if
this ends in silly discussions about whether an admin should do
something this or that way or how long logfiles should be kept. This is
not related to the technical question anymore and completely useless.
I was looking for a
On 22.10.2011 18:56, Maarten Bezemer wrote:
On the other hand, the question was a bit broad as a starting point.
The SMTP envelope is nothing more than SMTP protocol and is not in
itself part of the email format RFC. If you want to have this
information saved in the email message, then it is
The mbox from-line, not to be confused with the From: header, is
simply not part of the email message but used only as a separator.
Heck, it need not even contain valid information, but only proper
formatting to satisfy picky/smart MUA's. Usually, it conveniently
does carry some useful
Hi,
just a simple question about dovecot:
The mbox file format contains the SMTP envelope sender and transmission
date in a FROM ... line preceding the RFC822 mail header and body.
As far as I see at the moment, the IMAP protocol does not support
transmission of that SMTP envelope data in
On 21.10.2011 20:02, Dennis Guhl wrote:
The SMTP envelope does only exist within the involved MTAs and only as
long as the message is not finally delivered.
The intended use is to create a backup from a mailbox through IMAP,
which is as close as possible to the original mbox file, thus
Hi,
I would like to setup an IMAP server with SASL and LDAP support.
As far as I can see dovecot supports SASL and LDAP, but not the way I
need it.
If I understand dovecot correctly, it has it's own set of SASL
mechnisms and uses the LDAP server just to store the plaintext
password. In case
Hi,
just a question:
I know that dovecot supports SASL authentication and supports LDAP.
Which means that dovecot performs the SASL methods itself and stores the
plaintext secret on LDAP.
But it is also possible to have the LDAP do the SASL work and dovecot just
pass SASL messages through?
Timo Sirainen wrote:
For plaintext authentication you can use authentication binds and have
the password stored on LDAP side in any way you want.
For non-plaintext authentication Dovecot needs the secret in plaintext
or some other specific format. LDAP doesn't support SASL forwarding.
Hi Sergey,
Sergey A. Kobzar wrote:
You can use standard LDAP attributes. It's more than enough.
Well, I know that it works with standard LDAP attributes, that's what I
do right now. But that is what I want to avoid, because I want to have
IMAP users *without* standard uid/gid attributes
Hi,
does dovecot define its own LDAP schema or should I create my own one?
(I want to provide IMAP boxes for virtual users that do not have a
Unix account on the mail server and thus do not want to use the
plain uid/gid entries of the posix account objectclass to avoid confusion
and
18 matches
Mail list logo
