I've posted on the cyrus-sasl list and now created a new bug report [1] for the
issue, with the proposed patch by Viktor Dukhovni as a starting point (after
all, the other modules might need to be patched as well - didn't check).
[1] https://bugzilla.cyrusimap.org/show_bug.cgi?id=3906
Thanks,
On Wed, Oct 07, 2015 at 12:29:05PM +0200, Patrick Wagner wrote:
> I've posted on the cyrus-sasl list and now created a new bug report [1]
> for the issue, with the proposed patch by Viktor Dukhovni as a starting
> point (after all, the other modules might need to be patched as well -
> didn't chec
it looks like I have a couple of compromised user accounts on one of the
domains on this server, I've changed the user password then even deleted
the user (through postfixadmin) but that didn't help..? I can see in the
log this:
Oct 8 00:27:57 emu postfix/smtpd[7655]: 87E6B5E791:
client=unknown[1
On Thu, Oct 08, 2015 at 12:34:25AM +1100, Voytek wrote:
> it looks like I have a couple of compromised user accounts on one of the
> domains on this server, I've changed the user password then even deleted
> the user (through postfixadmin) but that didn't help..? I can see in the
> log this:
>
>
On Thu, October 8, 2015 12:42 am, Viktor Dukhovni wrote:
> On Thu, Oct 08, 2015 at 12:34:25AM +1100, Voytek wrote:
>
>
>> it looks like I have a couple of compromised user accounts on one of
>> the domains on this server, I've changed the user password then even
>> deleted the user (through postfix
Is 104.200.78.121 listed in your $permit_mynetworks parameter, or a CIDR
that contains it?
Did you postmap /etc/postfix/sasl_access?
Did you try c...@dom.org.au as entry?
Did you try cas@ as entry?
Regards,
Nicolás
El 2015-10-07 14:47, Voytek escribió:
On Thu, October 8, 2015 12:42 am, Viktor
On Thu, October 8, 2015 12:54 am, nico...@devels.es wrote:
Nicolás, thanks
> Is 104.200.78.121 listed in your $permit_mynetworks parameter, or a CIDR
> that contains it?
no
# grep 104.200 main.cf
#
> Did you postmap /etc/postfix/sasl_access?
yes
> Did you try c...@dom.org.au as entry?
> Did
On Wednesday 07/10/2015 at 8:35 am, Voytek wrote:
it looks like I have a couple of compromised user accounts on one of
the
domains on this server, I've changed the user password then even
deleted
the user (through postfixadmin) but that didn't help..? I can see in
the
log this:
Oct 8 00
I’m not getting EAI support built in, even though the libraries appear to be on
the system.
This builds it fine, but not with EAI
make -f Makefile.init dynamicmaps=yes CCARGS='-DHAS_MYSQL
-I/usr/local/include/mysql -DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL
-I/opt/local/include/sasl -DDEF_SERV
Robert Chalmers:
> I?m not getting EAI support built in, even though the libraries appear to be
> on the system.
>
> This builds it fine, but not with EAI
>
> make -f Makefile.init dynamicmaps=yes CCARGS='-DHAS_MYSQL
> -I/usr/local/include/mysql -DUSE_TLS -DUSE_SASL_AUTH -DUSE_CYRUS_SASL
> -I/
I have the icuuc libraries here.
/opt/local/lib/libicuuc.55.1.dylib
/opt/local/lib/libicuuc.55.dylib
/opt/local/lib/libicuuc.a
/opt/local/lib/libicuuc.dylib
and they are pretty recent.
lrwxr-xr-x 1 root admin 19 20 Apr 01:19 /opt/local/lib/libicuuc.dylib ->
libicuuc.55.1.dylib
but I have no
I think I've stopped compromised user sending by stopping and restarting
Postfix, prior to that, I've reloaded Postfix after adding/postmaping
sasl_access list - that didn't help, only stopping Postfix stopped it
I'm worried that 'there is more' ?
I've found one more compromised user by searchin
On Thu, Oct 08, 2015 at 02:15:36AM +1100, Voytek wrote:
> I think I've stopped compromised user sending by stopping and restarting
> Postfix, prior to that, I've reloaded Postfix after adding/postmaping
> sasl_access list - that didn't help, only stopping Postfix stopped it
With Berkeley-DB table
On Wed, Oct 07, 2015 at 03:40:02PM +0100, Robert Chalmers wrote:
> I have the icuuc libraries here.
>
> /opt/local/lib/libicuuc.55.1.dylib
> /opt/local/lib/libicuuc.55.dylib
> /opt/local/lib/libicuuc.a
> /opt/local/lib/libicuuc.dylib
>
> and they are pretty recent.
> lrwxr-xr-x 1 root admin
On Thu, October 8, 2015 2:35 am, Viktor Dukhovni wrote:
> On Thu, Oct 08, 2015 at 02:15:36AM +1100, Voytek wrote:
>
>
>> I think I've stopped compromised user sending by stopping and
>> restarting Postfix, prior to that, I've reloaded Postfix after
>> adding/postmaping sasl_access list - that didn'
On Thu, Oct 08, 2015 at 02:56:37AM +1100, Voytek wrote:
> > With Berkeley-DB tables, updated tables are only picked up by smtpd
> > when a client disconnects and a new client connects.
> >
> > So if a client was hanging on to a single connection and sending
> > lots of messages back to back withou
On Thu, October 8, 2015 2:35 am, Viktor Dukhovni wrote:
> There's nothing more.
Viktor,
thanks again for your help and explanation, just found this, I think I can
call it a day now:
Oct 8 02:08:41 emu postfix/smtpd[29357]: connect from
unknown[104.200.78.121]
Oct 8 02:08:44 emu postfix/smtpd[2
On Thu, October 8, 2015 3:06 am, Viktor Dukhovni wrote:
>
> No. Confirmation would be looking at the logs of the ongoing mails
> *before* the restart and seeing whether all the mail came in over
> a single connection (same pid, no per-connection "connect from" or
> "disconnect from" log entries f
Robert Chalmers:
> but I have no idea what icu-config is, and why I need it. I can
> probably install it on the mac, but why do I need it?
It is a utility that spits out compiler and linker options that
Postfix needs to build with the ICU library. Most systems have one.
Wietse
Wietse Venema:
> Robert Chalmers:
> > but I have no idea what icu-config is, and why I need it. I can
> > probably install it on the mac, but why do I need it?
>
> It is a utility that spits out compiler and linker options that
> Postfix needs to build with the ICU library. Most systems have one.
--On Wednesday, October 07, 2015 5:06 PM + Viktor Dukhovni
wrote:
What would help is putting the "check_sasl_access" table in SQL.
I should've stopped/restarted immediately...
No, instead put your access table in SQL (possibly CDB would work
too, but I'm not sure), that way you don't n
On Wed, Oct 07, 2015 at 02:52:36PM -0700, Quanah Gibson-Mount wrote:
> >What would help is putting the "check_sasl_access" table in SQL.
> >
> >>I should've stopped/restarted immediately...
> >
> >No, instead put your access table in SQL (possibly CDB would work
> >too, but I'm not sure), that way
--On Wednesday, October 07, 2015 11:07 PM + Viktor Dukhovni
wrote:
On Wed, Oct 07, 2015 at 02:52:36PM -0700, Quanah Gibson-Mount wrote:
> What would help is putting the "check_sasl_access" table in SQL.
>
>> I should've stopped/restarted immediately...
>
> No, instead put your access tab
On Wed, Oct 07, 2015 at 10:07:16PM +, Viktor Dukhovni wrote:
> On Wed, Oct 07, 2015 at 02:52:36PM -0700, Quanah Gibson-Mount wrote:
>
> > >What would help is putting the "check_sasl_access" table in SQL.
> > >
> > >>I should've stopped/restarted immediately...
> > >
> > >No, instead put your a
--On Wednesday, October 07, 2015 11:13 PM + Viktor Dukhovni
wrote:
Mind you, if they log in the mean time, and don't send any mail,
the connection is timed out. If they do try to send mail, the
transaction is refused. When the error limit is exceeded the
connection is closed.
So the ex
On Wed, Oct 07, 2015 at 03:20:04PM -0700, Quanah Gibson-Mount wrote:
> User account is compromised
> Spammer creates a persistent connection to send out spam
> Admin adds compromised user to the SASL map
> Admin contacts user, has them change their password
> Admin removes user from the SASL map
>
26 matches
Mail list logo
