I have forwarded this entire mail to libsrs2@rt.anarres.org so it is now
in the bug queue. I expect to have these imlpemented after this weekend.
Note to implementors: I expect to put the code for handling of all of
these options into the library, that way the MTA unconditionally calls
(e.g.) srs_reverse, and the SRS library performs reversal only if
configured to do so. This reduces the patch workload for MTA maintainers.
S.
On Wed, 30 Jun 2004, Michel Bouissou wrote:
> Le mercredi 30 Juin 2004 21:12, Xavier Beaudouin a écrit :
> >
> > By the way if someone have a up to date postfix patch (eg for postfix
> > 2.1.3 for example) I will be very pleased to use and test it :)
>
> I've been thinking of this SRS patch for Postfix, and besides the missing
> default values, I believe it misses a number of supplementary control
> parameters.
>
> First, srs_domain should default to $mydomain
>
> Then, the SRS patch being compiled into Postfix, there should be parameters
> for enabling or disabling the SRS subsystem, preferably separately (as one
> might want to stop using forward SRS, but still perform reverse SRS as long
> as there may be SRS'ed mails in the wild)
>
> So I would suggest
>
> srs_forward (whether or not to perform forward SRS globally, boolean, defaults
> to "no")
>
> srs_reverse (whether or not to perform reverse SRS globally, boolean, defaults
> to $srs_forward)
>
> Then, I believe there should be a list of "MAIL FROM:" domains for which
> forward SRS should *never* be performed (let's say when a given server is an
> origin for several mail domains, you don't want to forward SRS mails
> originating from one of your own domains)
>
> I would suggest to add a parameter fot this, such as:
>
> srs_bypass_domains (list of strings, defaults to $mydestination + $srs_domain)
>
> Any comments ?
>
>
--
Shevek http://www.anarres.org/
Robust SPF with MTA support http://www.libspf2.org/
SRS for the next generation http://www.libsrs2.org/
in the bug queue. I expect to have these imlpemented after this weekend.
Note to implementors: I expect to put the code for handling of all of
these options into the library, that way the MTA unconditionally calls
(e.g.) srs_reverse, and the SRS library performs reversal only if
configured to do so. This reduces the patch workload for MTA maintainers.
S.
On Wed, 30 Jun 2004, Michel Bouissou wrote:
> Le mercredi 30 Juin 2004 21:12, Xavier Beaudouin a écrit :
> >
> > By the way if someone have a up to date postfix patch (eg for postfix
> > 2.1.3 for example) I will be very pleased to use and test it :)
>
> I've been thinking of this SRS patch for Postfix, and besides the missing
> default values, I believe it misses a number of supplementary control
> parameters.
>
> First, srs_domain should default to $mydomain
>
> Then, the SRS patch being compiled into Postfix, there should be parameters
> for enabling or disabling the SRS subsystem, preferably separately (as one
> might want to stop using forward SRS, but still perform reverse SRS as long
> as there may be SRS'ed mails in the wild)
>
> So I would suggest
>
> srs_forward (whether or not to perform forward SRS globally, boolean, defaults
> to "no")
>
> srs_reverse (whether or not to perform reverse SRS globally, boolean, defaults
> to $srs_forward)
>
> Then, I believe there should be a list of "MAIL FROM:" domains for which
> forward SRS should *never* be performed (let's say when a given server is an
> origin for several mail domains, you don't want to forward SRS mails
> originating from one of your own domains)
>
> I would suggest to add a parameter fot this, such as:
>
> srs_bypass_domains (list of strings, defaults to $mydestination + $srs_domain)
>
> Any comments ?
>
>
--
Shevek http://www.anarres.org/
Robust SPF with MTA support http://www.libspf2.org/
SRS for the next generation http://www.libsrs2.org/