Hello! With many MTAs it is possible to use a special form of adressing: subaddresses or "plussed addresses". For sendmail you can read some information on http://www.sendmail.org/m4/misc_features.html http://www.unix.org.ua/orelly/networking/sendmail/ch24_04.htm#SML2-CH-24-SECT-4-3 In a sieve filter you can analyse these special detail values, the syntax is described in RFC3598 (http://tools.ietf.org/html/rfc3598). The current deliver with sieve plugin for dovecot seems to support this RFC, but has the detail information not available. If I use require ["subaddress", "fileinto", "reject"]; require "envelope"; if envelope :detail "to" "junk" { fileinto "junk"; } the rule is not triggered, because the detail information from envelope is not available. Deliver gets the user information only via command line switch "-d". I did not analyse the problem very deep, but I believe we should introduce a new command line parameter for deliver, so deliver can pass the detail information to the sieve plugin. With that parameter you are able to pass the detail information from sendmail to devecot's deliver in the same way procmail is handled (procmail uses -a parameter). To avoid confusion: deliver has already a parameter -m to specify a different mailbox. In the described case the mailbox should be determined by the sieve filter, not via command line parameter. Existing workaround: Because I need this functionality I wrote a quick (and dirty?) workaround. Sendmail does not call deliver directly, but a wrapper program, that adds an additional "Delivered-To" header line. So the detail information may be processed with if address :detail ["Delivered-to"] "junk" { but I would prefer to call deliver directly. What do you think, is it a useful extension and does it work? Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.
Hi, Wednesday, September 26, 2007, 15:02:06, you wrote:> With many MTAs it is possible to use a special form of adressing: subaddresses or "plussed > addresses". > In a sieve filter you can analyse these special detail values, the syntax is described in > RFC3598 (http://tools.ietf.org/html/rfc3598). > The current deliver with sieve plugin for dovecot seems to support this RFC, but has the > detail information not available. > I did not analyse the problem very deep, but I believe we should introduce a new command > line parameter for deliver, so deliver can pass the detail > information to the sieve plugin.While I am no expert on this (I have just started using sieve filters and Dovecot deliver) it definitely looks tempting to me. I'd be glad to see it (or an equivalent implementation) in Dovecot. -- Best regards, Robert Tomanek mailto:rth23 at poczta.onet.pl
On Wed, 2007-09-26 at 15:02 +0200, Frank Behrens wrote:> The current deliver with sieve plugin for dovecot seems to support this RFC, but has the > detail information not available. If I use > > require ["subaddress", "fileinto", "reject"]; > require "envelope"; > if envelope :detail "to" "junk" { > fileinto "junk"; > } > > the rule is not triggered, because the detail information from envelope is not available. Deliver > gets the user information only via command line switch "-d".Added -a parameter to hg deliver + hg sieve plugin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20070930/91bcc143/attachment-0002.bin>
Apparently Analagous Threads
- [RFC PATCH 1/1] mshyperv: fix recognition of Hyper-V guest crash MSR's
- [RFC PATCH 1/1] mshyperv: fix recognition of Hyper-V guest crash MSR's
- IMAP: Disconnected: BUG: Unknown internal error (Dovecot 1.0.3)
- imap process consuming 100% CPU (Dovecot 1.0.3)
- OT - In which countries are ISDN subaddresses used ?