|
|
Date: Prev Next Date Index Thread: Prev Next Thread Index
On Thu, Jun 09, 2005 at 01:14:57PM -0400, Wietse Venema wrote:
> Miroslav Rudisin: > > Hi, > > > > default value of recipient_delimiter '+' makes problem with stupid non-RFC > >- web forms. I can not simply change delimiter to other, because I would canc > >-el existing email addresses which using it. So I patched postfix to support > >-multiple of them. > > That change breaks the forward_path configuration parameter, which > has a default value of: > > forward_path = $home/.forward${recipient_delimiter}${extension}, > $home/.forward > One way forward (pardon the uninteded pun) is that ${recipient_delimeter} could the one for domains matching mydestination (and by default all others), but more generally (when relaying for domains with distinct recipient delimiters) the recipient delimiter would be chosen on a domain by domain basis: # default recipient_delimiter_maps = static:${recipient_delimiter} Then with the following configuration: delimiter_maps: plusdomain.tld + mindomain.tld - virtual: joe@xxxxxxxxxxxxxx fred@xxxxxxxxxxxxx the input address joe+foo@xxxxxxxxxxxxxx is rewritten via virtual(5) to fred-foo@xxxxxxxxxxxxxx Recipient validation will work for both domains with the recipient delimiter applied in each case. Finally, when a domain has no recipient delimiter (e.g. Exchange behind Postfix), the extension is dropped: joe+foo@xxxxxxxxxxxxxx -> fred@xxxxxxxxxxxxxxx Much more complex than multiple static delimiters, but functionally correct, since a mismatch in delimiters results in backscatter or inability to do recipient validation. The domain -> delimeter lookups can use a small internal cache to make the overhead low. This is quite invasive, and however correct, may not be worth the trouble (I think it is worth doing, but clearly not strongly enough to have done it already). -- Viktor.
Thread at a glance:
Previous Message by Date:Re: [patch] multiple recipient_delimiterMiroslav Rudisin: > Hi, > > default value of recipient_delimiter '+' makes problem with stupid non-RFC >- web forms. I can not simply change delimiter to other, because I would canc >-el existing email addresses which using it. So I patched postfix to support >-multiple of them. That change breaks the forward_path configuration parameter, which has a default value of: forward_path = $home/.forward${recipient_delimiter}${extension}, $home/.forward Instead, use canonical_maps or virtual_maps to rewrite the addresses with the wrong delimiter. Wietse Next Message by Date:Re: [patch] multiple recipient_delimiterVictor Duchovni: > On Thu, Jun 09, 2005 at 01:14:57PM -0400, Wietse Venema wrote: > > > Miroslav Rudisin: > > > Hi, > > > > > > default value of recipient_delimiter '+' makes problem with stupid non-RFC > > >- web forms. I can not simply change delimiter to other, because I would > > >canc > > >-el existing email addresses which using it. So I patched postfix to > > >support > > >-multiple of them. > > > > That change breaks the forward_path configuration parameter, which > > has a default value of: > > > > forward_path = $home/.forward${recipient_delimiter}${extension}, > > $home/.forward > > > > One way forward (pardon the uninteded pun) is that ${recipient_delimeter} > could the one for domains matching mydestination (and by default all others), > but more generally (when relaying for domains with distinct recipient > delimiters) the recipient delimiter would be chosen on a domain by domain > basis: > > # default > recipient_delimiter_maps = static:${recipient_delimiter} > > Then with the following configuration: > > delimiter_maps: > plusdomain.tld + > mindomain.tld - > > virtual: > joe@xxxxxxxxxxxxxx fred@xxxxxxxxxxxxx > > the input address joe+foo@xxxxxxxxxxxxxx is rewritten via virtual(5) > to fred-foo@xxxxxxxxxxxxxx Recipient validation will work for both > domains with the recipient delimiter applied in each case. Finally, > when a domain has no recipient delimiter (e.g. Exchange behind Postfix), > the extension is dropped: joe+foo@xxxxxxxxxxxxxx -> fred@xxxxxxxxxxxxxxx This means the parameter can't be used unless an obvious domain context exists, or when the domain is not found in the table; Postfix lookup tables aren't guaranteed to have a default result. > Much more complex than multiple static delimiters, but functionally > correct, since a mismatch in delimiters results in backscatter or > inability to do recipient validation. > > The domain -> delimeter lookups can use a small internal cache to > make the overhead low. This is quite invasive, and however correct, > may not be worth the trouble (I think it is worth doing, but clearly > not strongly enough to have done it already). I expect that the original poster has only a limited number of address with the "wrong" delimiter (he was talking about RFC violating websites that don't allow + in an address), and that a static canonical or virtual alias mapping can take care of it. Wietse Previous Message by Thread:Re: [patch] multiple recipient_delimiterMiroslav Rudisin: > Hi, > > default value of recipient_delimiter '+' makes problem with stupid non-RFC >- web forms. I can not simply change delimiter to other, because I would canc >-el existing email addresses which using it. So I patched postfix to support >-multiple of them. That change breaks the forward_path configuration parameter, which has a default value of: forward_path = $home/.forward${recipient_delimiter}${extension}, $home/.forward Instead, use canonical_maps or virtual_maps to rewrite the addresses with the wrong delimiter. Wietse Next Message by Thread:Re: [patch] multiple recipient_delimiterVictor Duchovni: > On Thu, Jun 09, 2005 at 01:14:57PM -0400, Wietse Venema wrote: > > > Miroslav Rudisin: > > > Hi, > > > > > > default value of recipient_delimiter '+' makes problem with stupid non-RFC > > >- web forms. I can not simply change delimiter to other, because I would > > >canc > > >-el existing email addresses which using it. So I patched postfix to > > >support > > >-multiple of them. > > > > That change breaks the forward_path configuration parameter, which > > has a default value of: > > > > forward_path = $home/.forward${recipient_delimiter}${extension}, > > $home/.forward > > > > One way forward (pardon the uninteded pun) is that ${recipient_delimeter} > could the one for domains matching mydestination (and by default all others), > but more generally (when relaying for domains with distinct recipient > delimiters) the recipient delimiter would be chosen on a domain by domain > basis: > > # default > recipient_delimiter_maps = static:${recipient_delimiter} > > Then with the following configuration: > > delimiter_maps: > plusdomain.tld + > mindomain.tld - > > virtual: > joe@xxxxxxxxxxxxxx fred@xxxxxxxxxxxxx > > the input address joe+foo@xxxxxxxxxxxxxx is rewritten via virtual(5) > to fred-foo@xxxxxxxxxxxxxx Recipient validation will work for both > domains with the recipient delimiter applied in each case. Finally, > when a domain has no recipient delimiter (e.g. Exchange behind Postfix), > the extension is dropped: joe+foo@xxxxxxxxxxxxxx -> fred@xxxxxxxxxxxxxxx This means the parameter can't be used unless an obvious domain context exists, or when the domain is not found in the table; Postfix lookup tables aren't guaranteed to have a default result. > Much more complex than multiple static delimiters, but functionally > correct, since a mismatch in delimiters results in backscatter or > inability to do recipient validation. > > The domain -> delimeter lookups can use a small internal cache to > make the overhead low. This is quite invasive, and however correct, > may not be worth the trouble (I think it is worth doing, but clearly > not strongly enough to have done it already). I expect that the original poster has only a limited number of address with the "wrong" delimiter (he was talking about RFC violating websites that don't allow + in an address), and that a static canonical or virtual alias mapping can take care of it. Wietse
|
|
