[Dovecot] recipient delimiter and lmtp
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.
thanks, John
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.
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 3:22 PM, Stephan Bosch wrote:
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.
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...
Also, Google has a very interesting ability to ignore dots (periods) in the local part of the address, so you can essentially create 'unique' addresses on the fly by simply inserting a period anywhere into the local part, that can then be filtered on at delivery time...
--
Best regards,
Charles
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 1 Jun 2009, Charles Marcus 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.
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'
in virtuser or Alias maps.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSiTsaHWSIuGy1ktrAQKkNgf/UGKfPrPnaKvuYH5GIeSw9T142muusAWA HUj15rWsv9jHtTnD8Mbr8uRBfCdTrptfr5vGD4bIdYeJuBtlD3S8lfIaVo9GcLCt /Ig9dsn7LxS/NgGMqxp6Cmhx6/ZCrVmwSxpCCA3sg20CriQQwLiElkYoAUMpiSE4 6+njcsHzC2dOEa5OlFeYFRANOhvskLRNZrBYDSsItb9YYEAqok4WB7ghUY/JqccE I9OXV5zVG0lmcg0AhYm9uUAKMZpxTOZZh0l0WT4+Cs0zbA04FC8rzBP/xy238GEc RtoT81fWMWBhlj4683jeSjen5WK+tn8GEKJY8jckkHP8wskUR09hnA== =8U8t -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 2 Jun 2009, Charles Marcus wrote:
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.
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.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSiUBG3WSIuGy1ktrAQJaEAgAtVS2ZJoWmRsJhABKf2SMfwIAKk6D+S0H OYs3vUkFbsqcQTd+9Xg32R2lpPcuHhHkij5lQM33q+q9lNuBYSf3b2qT4UTcLwcz 4nTCprCySD4UGxa2i1KOs7LKxoXeMO8jRuG5s3uOqEeTqs2fb+6sctSWSnvgInnH t/fClJ7YvO8KTP17b8ecn3NKRBQ2I9295oFhuzQe4P755bdmBoS5PsU4HXL4db0h TFUX4RqDqlBDg3KKWOkmbPczhIRCB71AJmpzetWHyma9ovJH7G8mJ3YXoAMYjDCL 4thGygxjiOnwUXqeQs5nD5G9aiU1cQPcgz/J/L6Ks0P3DiGh0nj3MQ== =UNsH -----END PGP SIGNATURE-----
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
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 ?
Thanks
Joan
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
participants (6)
-
Charles Marcus
-
Joan
-
John Fawcett
-
Steffen Kaiser
-
Stephan Bosch
-
Timo Sirainen