Timo Sirainen schreef:

On Fri, 2009-05-22 at 20:45 +0200, John Fawcett wrote:

...

I read in the list archives about work in progress on an lmtp delivery agent.As a previous cyrus user where that was the preferred delivery method from postfix, this sounds interesting.

I was wondering whether it will handle recipient delimiters. ie will it be able to map user+foo@example.com to user@example.com? I'm not interested in the delivery into folder stuff, just the plain delivery to inbox.

Hmm. Stephan, you currently have sieve_subaddress_sep setting. Should we instead use a common setting here? Like:

protocol lda { recipient_delimiter = + }

With v1.2 it probably wouldn't do anything, but with v2.0 LMTP could use it. Sounds sensible. I can for instance make the plugin use this setting if sieve_subaddress_sep is not set.

Regards,

-- Stephan Bosch stephan@rename-it.nl

On 5/29/2009, Charles Marcus (CMarcus@Media-Brokers.com) wrote:

...

...

...

Hmm. Stephan, you currently have sieve_subaddress_sep setting. Should we instead use a common setting here? Like:

protocol lda { recipient_delimiter = + }

...

...

With v1.2 it probably wouldn't do anything, but with v2.0 LMTP could use it.

...

Sounds sensible. I can for instance make the plugin use this setting if sieve_subaddress_sep is not set.

How hard would it be to allow the use of more than one delimiter? Obviously this would have to be well documented, explaining the pitfalls, and sysadmins would have to make sure that that character was illegal when it came to creating the actual accounts...

The reason I ask is, some sites don't allow the use of the '+' delimiter, so having a second optional character, and/or the ability to use a dot anywhere in the local part, would provide a workaround to these site...

--

Best regards,

Crles

On 6/2/2009, Steffen Kaiser (skdovecot@smail.inf.fh-brs.de) wrote:

...

The reason I ask is, some sites don't allow the use of the '+' delimiter, so having a second optional character, and/or the ability to use a dot anywhere in the local part, would provide a workaround to these site...

'+' is the separator of sendmail. The MTA must support it, too, to know that the recipient is local.

Qmail uses '-', in postfix you can configure the delimiter.

I know... I don't have local recipients, but you are right, I was forgetting that recipient validation is done by the MTA...

So, I'd need to find a way to trick postfix into seeing one or more alternate characters as '+' (or whatever it is defined as), for recipient validation purposes...

But, the LDA/Sieve would *also* need to be able to handle these same characters, for Delivery/Filtering purposes.

To insert a '.' anyplace into the recipient name, you have to do something on MTA level. E.g. with sendmail you could map:

'lo.calRecpient' to 'localRecipient+lo.calRecpient'

But that's not what I want. I want:

lo.calRecipient@example.com = localRecipient@example.com

for both recipient validation *and* Delivery purposes, *but*...

obviously the LDA (in addition to postfix) would have to understand that they are the same, and Sieve would as well, in order to be able to filter/file into a folder based on a matching rule *if* one exists - or just Deliver to the Inbox for localRecipient@example.com if one doesn't.

I have been using this ability in gmail for a long time, and it is extremely powerful, so I'd just love to see a private implementation.

--

Best regards,

Charles

On 6/2/2009, Steffen Kaiser (skdovecot@smail.inf.fh-brs.de) wrote:

...

obviously the LDA (in addition to postfix) would have to understand that they are the same, and Sieve would as well, in order to be able to filter/file into a folder based on a matching rule *if* one exists - or just Deliver to the Inbox for localRecipient@example.com if one doesn't.

Therefore my suggestions to map "us.er" to "user+us.er". This is done with envelope information during SMTP not in headers, hence, should not effect delivery phase. After mapping, postfix delivers to "user" (local recipient), you configure Postfix to call Dovecot deliver with "-d user -m detail -n". "-m detail" is the default mailbox, "-n" does not create a missing mailbox.

Hmmm... ok, I think (hope) I see...

Thanks for applying the clue-stick so gently Steffen... :)

Now I'm off to the postfixadmin list to see if this capability could be added (to have some kind of regex based aliasing that can be toggled on/off, that controls the whole thing, allowing me to simply specify the optional 'plus' character(s) I want to use.

--

Best regards,

Charles

On 6/2/2009 8:36 AM, Joan wrote:

Hi all,

On the Mercurial repository, I see many upcoming releases (1.2 (which works almost very fine), 1.3 (what is it ?), 2.0 (how stable is it ?))

What is the rational behind all those versions ?

http://wiki.dovecot.org/Roadmap

My understanding is, Timo had originally been planning a 1.3 release, but decided that 2.0 will come after 1.2, which is very close to release ready - but I'm not sure, maybe he is still planning a 1.3...

2.0 will contain major changes (see page above)...

--

Best regards,

Charles