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 envelop
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
> o
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:
http://www.postfix.org/postconf.5.html#smtpd_sender_login_
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. How can I
>> prevent th
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 recently compromised, and
>>> started sending
> 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, and
given that many users
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 recently compro
> 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 access until
the password
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_r
>> [...]. 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 SMTP
> 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 this and some other
> pa
> 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 requires a first successful
> 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
> completio
> 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 "free" email provide
> 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
signature.asc
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
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 ha
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 people have many email add
18 matches
Mail list logo