On Thu, Aug 28, 2014 at 01:17:06PM +1000, li...@sbt.net.au wrote:
> On Mon, August 25, 2014 2:06 am, Viktor Dukhovni wrote:
>
> > If your relay restrictions look like:
> > main.cf:
> > indexed = ${default_database_type}:${config_directory}/
> > smtpd_relay_restrictions = check_sasl_access ${indexe
On Mon, August 25, 2014 2:06 am, Viktor Dukhovni wrote:
> If your relay restrictions look like:
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtpd_relay_restrictions = check_sasl_access ${indexed}sasl-access,
> permit_sasl_authenticated, permit_mynetworks, reject_unauth_d
2014-08-24 12:52 GMT-03:00 Edwin Marqe :
>
> Recently, we've had an issue with a stolen password of one of our
> users, resulting in a few junk mails sent out. Fortunately, we could
> change the user's password reasonably fast and it didn't do any bigger
> harm. However, after changing the passwor
On Sun, Aug 24, 2014 at 09:24:57PM +0200, li...@rhsoft.net wrote:
> so if the above feature works why postfix don't log the username at all?
The feaure in question allows one to block in real-time the access
of users that are using already authenticated established sessions.
Whatever your questi
Am 24.08.2014 um 21:11 schrieb Wietse Venema:
> CSS:
If your relay restrictions look like:
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_relay_restrictions =
check_sasl_access ${indexed}sasl-access,
permit_sasl_auth
CSS:
> >> If your relay restrictions look like:
> >>
> >>main.cf:
> >>indexed = ${default_database_type}:${config_directory}/
> >>smtpd_relay_restrictions =
> >>check_sasl_access ${indexed}sasl-access,
> >>permit_sasl_authenticated,
> >>permit_mynetworks,
> >>
On Aug 24, 2014, at 12:18 PM, D'Arcy J.M. Cain wrote:
> On Sun, 24 Aug 2014 16:06:36 +
> Viktor Dukhovni wrote:
>> Postfix 2.11 or later has a new feature:
>>
>>http://www.postfix.org/postconf.5.html#check_sasl_access
>>
>> If your relay restrictions look like:
>>
>>main.cf:
>>
On Sun, Aug 24, 2014 at 06:06:52PM +0200, li...@rhsoft.net wrote:
> netstat, ps, lsof, kill
>
> you need to find out the PID of the smtpd process
That can have unintended consequences (the smtpd(8) service might
be throttled). A restart is better than manually killing specific
Postfix d
On Sun, 24 Aug 2014 16:06:36 +
Viktor Dukhovni wrote:
> Postfix 2.11 or later has a new feature:
>
> http://www.postfix.org/postconf.5.html#check_sasl_access
>
> If your relay restrictions look like:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
>
That's exactly what I was looking for, thank you so much guys!
2014-08-24 17:06 GMT+01:00 Viktor Dukhovni :
> On Sun, Aug 24, 2014 at 04:52:35PM +0100, Edwin Marqe wrote:
>
>> Is there a Postfix specific command that would end/kill a user's
>> session? If not, any workaround that would disconnect
netstat, ps, lsof, kill
you need to find out the PID of the smtpd process
honestly it's not worth because if what you describes
you have more imporant problems to solve and restart
postfix even while incoming mail flows is a no-brainer
because it would be re-tried by the sender
Am 24.08.
On Sun, Aug 24, 2014 at 04:52:35PM +0100, Edwin Marqe wrote:
> Is there a Postfix specific command that would end/kill a user's
> session? If not, any workaround that would disconnect that user? I've
> been trying to find something regarding this in the documentation but
> found nothing.
Postfix
Yes, I know that restarting everything ends up, which is what we
finally did, but I was looking for some kind of command or at least a
way of ending a specific user's session without restarting Postfix, as
this domain handles a really big amount of traffic and seems overkill
restart the whole Postf
Am 24.08.2014 um 17:52 schrieb Edwin Marqe:
> Recently, we've had an issue with a stolen password of one of our
> users, resulting in a few junk mails sent out. Fortunately, we could
> change the user's password reasonably fast and it didn't do any bigger
> harm. However, after changing the passw
Hello,
Recently, we've had an issue with a stolen password of one of our
users, resulting in a few junk mails sent out. Fortunately, we could
change the user's password reasonably fast and it didn't do any bigger
harm. However, after changing the password, the user was still able to
continue sendi
15 matches
Mail list logo
