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
Wietse Venema:
> Viktor Dukhovni:
> > One quick comment about check_sasl_access and established
> > sessions. This may not work reliably with Berkeley DB.
> >
> > It is best to use a SQL, LDAP, ... database. I haven't checked
> > whether tinycdb (when not chrooted) automatically re-opens updated
Viktor Dukhovni:
> One quick comment about check_sasl_access and established
> sessions. This may not work reliably with Berkeley DB.
>
> It is best to use a SQL, LDAP, ... database. I haven't checked
> whether tinycdb (when not chrooted) automatically re-opens updated
> ".cdb" files. If so, CD
One quick comment about check_sasl_access and established
sessions. This may not work reliably with Berkeley DB.
It is best to use a SQL, LDAP, ... database. I haven't checked
whether tinycdb (when not chrooted) automatically re-opens updated
".cdb" files. If so, CDB might work too.
--
On Aug 24, 2014, at 2:20 PM, Wietse Venema wrote:
>
> You use smtpd_proxy_filter (the "before-queue" filter). This does
> not need receive_override_options, because mail takes a path that
> is not subject to double address mapping.
>
> The receive_override_options feature is needed with the muc
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
On Sun, Aug 24, 2014 at 02:08:00PM -0500, Chad M Stewart wrote:
> 127.0.0.1:10026/inet/receive_override_options =
> no_address_mappings,no_header_body_checks,no_unknown_recipient_checks
> 127.0.0.1:10026/inet/smtpd_authorized_xforward_hosts = 127.0.0.0/8
> 127.0.0.1:10026/inet/smtpd_client_restri
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
Chad M Stewart:
>
> On Aug 24, 2014, at 2:00 PM, Wietse Venema wrote:
>
> > Please also examine "postconf -P" output. That shows parameter
> > settings in master.cf that have higher precedence than main.cf.
> >
> > I suspect that you have "receive_override_options" in master.cf.
> > That is nor
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 2:00 PM, Wietse Venema wrote:
> Please also examine "postconf -P" output. That shows parameter
> settings in master.cf that have higher precedence than main.cf.
>
> I suspect that you have "receive_override_options" in master.cf.
> That is normally used to disable address ma
Wietse Venema:
> Chad M Stewart:
> >
> > On Aug 24, 2014, at 1:09 PM, Wietse Venema wrote:
> >
> > > Chad M Stewart:
> > >> I've followed http://www.postfix.org/VIRTUAL_README.html#virtual_mailbox
> > >> (Non-Postfix mailbox store) or at least I've tried to follow it.
> > >> :)
> > >
> > > Plea
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:
>>
Chad M Stewart:
>
> On Aug 24, 2014, at 1:09 PM, Wietse Venema wrote:
>
> > Chad M Stewart:
> >> I've followed http://www.postfix.org/VIRTUAL_README.html#virtual_mailbox
> >> (Non-Postfix mailbox store) or at least I've tried to follow it.
> >> :)
> >
> > Please post "postconf -n" output (that
On Aug 24, 2014, at 1:09 PM, Wietse Venema wrote:
> Chad M Stewart:
>> I've followed http://www.postfix.org/VIRTUAL_README.html#virtual_mailbox
>> (Non-Postfix mailbox store) or at least I've tried to follow it.
>> :)
>
> Please post "postconf -n" output (that is what Postfix sees).
>
> Do not
Hello Wietse,
thanks for your hint to decode base64 encoded login string. My client was
command line and by decoding my encoded login string I recognized that I
missed to escape '@' character - thus my login string was incomplete. Now
both smtp and imap client authentication work properly.
Thanks
Chad M Stewart:
> I've followed http://www.postfix.org/VIRTUAL_README.html#virtual_mailbox
> (Non-Postfix mailbox store) or at least I've tried to follow it.
> :)
Please post "postconf -n" output (that is what Postfix sees).
Do not post main.cf snippets (that is what you think Postfix
uses, but y
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
I'm not sure what I've done wrong, but aliases for virtual users is not
working. A postmap -q returns what it should, but when I send a
test message, the alias address is passed to the downstream system, instead of
the result of the lookup.
I'm setting up Postfix as a frontend to Dovecot on
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
Quirin Maier:
> Hello,
>
> I've setup dovecot and postfix using dovecot sasl on samba4 ldap backend.
> I'd like to authenticate with user's email address as login. While dovecot
> authentication works,
> postfix authentication fails on 'AUTH PLAIN ...' with '535 5.7.8 Error:
> authentication faile
Hello,
I've setup dovecot and postfix using dovecot sasl on samba4 ldap backend.
I'd like to authenticate with user's email address as login. While dovecot
authentication works,
postfix authentication fails on 'AUTH PLAIN ...' with '535 5.7.8 Error:
authentication failed:' Dovecot's debug log file
28 matches
Mail list logo
