Re: Restricting submission to legitimate account name only

2018-02-19 Thread @lbutlr
On 2018-02-19 (09:35 MST), Alex wrote: > > In other words, if the sasl_username is alice, I'd like to restrict the > envelope sender and From address to only legitimate accounts belonging to > that sasl user. This may break many people's workflows. For example, most

Re: Restricting submission to legitimate account name only

2018-02-19 Thread Wietse Venema
Alex: > Hi, > I have a postfix-3.1.4 system with a few hundred people using the > submission service. One of the accounts was recently compromised, and > started sending mail as fake users in the same domain. How can I > prevent this? See:

Re: Restricting submission to legitimate account name only

2018-02-19 Thread Alex
HI, On Mon, Feb 19, 2018 at 11:42 AM, Wietse Venema wrote: > Alex: >> Hi, >> I have a postfix-3.1.4 system with a few hundred people using the >> submission service. One of the accounts was recently compromised, and >> started sending mail as fake users in the same domain.

Re: Testing Postfix-3.3....0-RC1

2018-02-19 Thread Wietse Venema
Wietse Venema: > > > $ postconf -n > > > postconf: warning: read "ldap" configuration "/var/tmp/postfix/etc/ldap": > > > Is a directory > > > foo = proxy:ldap:${config_directory}/ldap > > > proxy_read_maps = ${foo}/foo.cf > > Fixed by adding a guard that makes postconf look for database names >

Restricting submission to legitimate account name only

2018-02-19 Thread Alex
Hi, I have a postfix-3.1.4 system with a few hundred people using the submission service. One of the accounts was recently compromised, and started sending mail as fake users in the same domain. How can I prevent this? In other words, if the sasl_username is alice, I'd like to restrict the

Re: Testing Postfix-3.3....0-RC1

2018-02-19 Thread Viktor Dukhovni
> On Feb 19, 2018, at 11:36 AM, Wietse Venema wrote: > > Done. This release candidate also adds 22 missing parameter names > to the proxy_read_maps setting (plus the script that generated those > entries). With so many values in the default setting of proxy_read_maps,

Re: Restricting submission to legitimate account name only

2018-02-19 Thread Wietse Venema
Alex: > HI, > > On Mon, Feb 19, 2018 at 12:08 PM, Alex wrote: > > HI, > > > > On Mon, Feb 19, 2018 at 11:42 AM, Wietse Venema > > wrote: > >> Alex: > >>> Hi, > >>> I have a postfix-3.1.4 system with a few hundred people using the > >>> submission

Re: MTA-STS when?

2018-02-19 Thread Jonathan Sélea
>> [...]. One can of course automate periodic SMTP TLS policy >> updates from the STS URIs of a handful of providers, and let the >> usual outbound TLS policy take care of the rest: >> >>http://www.postfix.org/TLS_README.html#client_tls_policy > I'm much in favor of reusing the Postfix

Re: MTA-STS when?

2018-02-19 Thread Viktor Dukhovni
> On Feb 19, 2018, at 1:43 PM, Jonathan Sélea wrote: > > It sounds like it is a fairly "easy" implementation? If so, when can > expect a testing version for this? > I will gladly test this! Likely some time this year, but it is not entirely trivial, because the spec

Re: Restricting submission to legitimate account name only

2018-02-19 Thread Alex
HI, On Mon, Feb 19, 2018 at 12:08 PM, Alex wrote: > HI, > > On Mon, Feb 19, 2018 at 11:42 AM, Wietse Venema wrote: >> Alex: >>> Hi, >>> I have a postfix-3.1.4 system with a few hundred people using the >>> submission service. One of the accounts was

Re: Restricting submission to legitimate account name only

2018-02-19 Thread Viktor Dukhovni
> On Feb 19, 2018, at 11:35 AM, Alex wrote: > > In other words, if the sasl_username is alice, I'd like to restrict > the envelope sender and From address to only legitimate accounts > belonging to that sasl user. If the account is compromised, you really should deny

Re: Testing Postfix-3.3....0-RC1

2018-02-19 Thread Wietse Venema
Viktor Dukhovni: > > > > On Feb 19, 2018, at 11:36 AM, Wietse Venema wrote: > > > > Done. This release candidate also adds 22 missing parameter names > > to the proxy_read_maps setting (plus the script that generated those > > entries). > > With so many values in the

Re: Testing Postfix-3.3....0-RC1

2018-02-19 Thread Viktor Dukhovni
> On Feb 19, 2018, at 1:34 PM, Wietse Venema wrote: > > Couple things. > > Assuming that we have no new features in a stable release candidate. > > If we do this for proxy_read_maps, then why not for other parameters, > too? How would we justify why some parameter has

Re: MTA-STS when?

2018-02-19 Thread Jonathan Sélea
> Likely some time this year, but it is not entirely trivial, because > the spec requires a first successful delivery to "activate" the policy, > and expedited policy cache refresh on delivery failure. Therefore, > there would need to be some sort of new feedback mechanism at delivery >

Re: MTA-STS when?

2018-02-19 Thread Jonathan Sélea
> Thanks. Note that "by manual" I mean not-based on the missing STS support, > but still based on their published STS policy which you can map to a Postfix > TLS policy via a cron job that updates the data once a week or so. > Fair enough :) Looking forward to it! -- Jonathan

Re: MTA-STS when?

2018-02-19 Thread Viktor Dukhovni
> On Feb 19, 2018, at 1:58 PM, Jonathan Sélea wrote: > >> Cycles to work on this are not immediately available. With so few >> early adopters, and even Gmail in "testing", you might just build >> manual policy that gets you secure transport to Gmail, Yahoo and >> the other

Re: MTA-STS when?

2018-02-19 Thread Wietse Venema
Jonathan S?lea: > >> [...]. One can of course automate periodic SMTP TLS policy > >> updates from the STS URIs of a handful of providers, and let the > >> usual outbound TLS policy take care of the rest: > >> > >>http://www.postfix.org/TLS_README.html#client_tls_policy > > I'm much in favor

Re: Testing Postfix-3.3....0-RC1

2018-02-19 Thread Wietse Venema
Viktor Dukhovni: > > On Feb 19, 2018, at 1:34 PM, Wietse Venema wrote: > > Couple things. > > > > Assuming that we have no new features in a stable release candidate. > > > > If we do this for proxy_read_maps, then why not for other parameters, > > too? How would we