Alex JOST schrieb:
> Am 11.06.2014 21:17, schrieb Kai Krakow:
>>* mbox server: handle pop3 and imap requests from users
>>* accepts no external traffic, just from mailout / bulkmail
>>* just a receiver for local domains
>>* maybe handle dovecot outgoing mails (thou we
Am 11.06.2014 21:17, schrieb Kai Krakow:
* mbox server: handle pop3 and imap requests from users
* accepts no external traffic, just from mailout / bulkmail
* just a receiver for local domains
* maybe handle dovecot outgoing mails (thou we didn't support anyway)
Any ide
On Sat, Jun 7, 2014 at 3:33 PM, Kai Krakow wrote:
> How is one supposed to automatically block such hijacked accounts within
> postfix? A simple heuristic could be detecting unusual high mail volume for
> that account, probably by detecting the always repeating or similar
> subjects.
What I do a
Stan Hoeppner schrieb:
> On 6/10/2014 3:39 PM, Wietse Venema wrote:
>> Kai Krakow:
>>> BTW: In this context, what's the best approach to put mailboxes on a
>>> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
>>> transport the mails via transport_map into a machine which h
On 6/10/2014 3:39 PM, Wietse Venema wrote:
> Kai Krakow:
>> BTW: In this context, what's the best approach to put mailboxes on a
>> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
>> transport the mails via transport_map into a machine which hosts the LDA
>> (dovecot in
Kai Krakow:
> BTW: In this context, what's the best approach to put mailboxes on a
> separate machine? Let the LDA drop mails into NFS mounts, or let postfix
> transport the mails via transport_map into a machine which hosts the LDA
> (dovecot in our case)?
I recommend Dovecot via LMTP, but NFS
On 6/10/2014 1:24 PM, Kai Krakow wrote:
> And those silly autodetection of older MUAs sticks to port 25
unencrypted. So even new customers who redo
> their installations on their own silently go back to port 25.
So... why on earth are you allowing UNENCRYPTED AUTH at ALL, let alone
on port 2
Peter schrieb:
> On 06/08/2014 08:17 PM, Kai Krakow wrote:
>> MX and Submission machine are the same postfix instance (and even the
>> same worker process on port 25), it won't work. I'm planning to maybe
>> change this in the future. But as with migrating all people to not submit
>> on port 25 i
On 06/08/2014 08:17 PM, Kai Krakow wrote:
> MX and Submission machine are the same postfix instance (and even the same
> worker process on port 25), it won't work. I'm planning to maybe change this
> in the future. But as with migrating all people to not submit on port 25 it
> is a long way to g
On 06/09/2014 04:56 PM, li...@rhsoft.net wrote:
>>> well, one could say: block them from submission port and don't allow
>>> SASL on 25, but that works only if you are a startup beginning from
>>> scratch,
>>
>> If that's the case then you can put submission on a separate IP address,
>> so that you
Am 09.06.2014 03:45, schrieb Peter:
> On 06/08/2014 03:53 AM, li...@rhsoft.net wrote:
>> well, one could say: block them from submission port and don't allow
>> SASL on 25, but that works only if you are a startup beginning from
>> scratch, i condsidered that but it would take weeks and months to
On 06/08/2014 08:53 AM, LuKreme wrote:
>
>> the stupidity is trying 25 first
>
> That is still what most servers support or even require.
I think the vast number of ESPs will accept submission on port 587.
Only supporting port 25 for submission nowadays is a disaster
considering the number of IS
On 06/08/2014 03:53 AM, li...@rhsoft.net wrote:
> well, one could say: block them from submission port and don't allow
> SASL on 25, but that works only if you are a startup beginning from
> scratch, i condsidered that but it would take weeks and months to
> explain all customers that they have to
On Sun, 8 Jun 2014, li...@rhsoft.net wrote:
but why setup fail2ban at all if you have no sshd on standard ports
and already a hyperfast "rbldnsd" running which scales over more than
one server without touch any configuration
frankly you can even use your RBL with web application firewalls
http:
Am 08.06.2014 18:27, schrieb Joe Laffey:
> On Sun, 8 Jun 2014, li...@rhsoft.net wrote:
>> Am 08.06.2014 17:18, schrieb Joe Laffey:
>>> On Sun, 8 Jun 2014, Kai Krakow wrote:
>>>
Noel Jones schrieb:
But I want to (automatically) block the suspicious networks and not first
block
On Sun, 8 Jun 2014, li...@rhsoft.net wrote:
Am 08.06.2014 17:18, schrieb Joe Laffey:
On Sun, 8 Jun 2014, Kai Krakow wrote:
Noel Jones schrieb:
But I want to (automatically) block the suspicious networks and not first
block all then whitelist the known-good.
Not sure I completely underst
Am 08.06.2014 17:18, schrieb Joe Laffey:
> On Sun, 8 Jun 2014, Kai Krakow wrote:
>
>> Noel Jones schrieb:
>>
>> But I want to (automatically) block the suspicious networks and not first
>> block all then whitelist the known-good.
>
> Not sure I completely understand the issue, but is this some
On Sun, 8 Jun 2014, Kai Krakow wrote:
Noel Jones schrieb:
But I want to (automatically) block the suspicious networks and not first
block all then whitelist the known-good.
Not sure I completely understand the issue, but is this something where
you could use fail2ban to monitor your logs
Noel Jones schrieb:
> On 6/7/2014 8:33 AM, Kai Krakow wrote:
>> Wietse Venema schrieb:
>>
>>> Kai Krakow:
Hello list!
Is there a way to prevent postfix from offering SASL auth (and
that includes denying open relaying) to clients based on DNS RBL
lookups? I've discovered
Wietse Venema schrieb:
> Kai Krakow:
>> How is one supposed to automatically block such hijacked accounts within
>> postfix? A simple heuristic could be detecting unusual high mail volume
>> for that account, probably by detecting the always repeating or similar
>> subjects.
>
> Typically, this
Noel Jones schrieb:
> On 6/7/2014 10:53 AM, li...@rhsoft.net wrote:
>>
>>
>> Am 07.06.2014 17:25, schrieb Noel Jones:
>>> I wonder why you're just trying to stop SASL from those client...
>>> Why not just use reject_rbl_client (and maybe other restrictions)
>>> before permit_sasl_authenticated
Am 07.06.2014 22:53, schrieb LuKreme:
>> On 07 Jun 2014, at 10:39 , li...@rhsoft.net wrote:
>>
>> Am 07.06.2014 18:29, schrieb LuKreme:
>>>
>>> On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
>>>
i condsidered that but it would take weeks and months to
explain all customers that they
> On 07 Jun 2014, at 10:39 , li...@rhsoft.net wrote:
>
>
>
> Am 07.06.2014 18:29, schrieb LuKreme:
>>
>> On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
>>
>>> i condsidered that but it would take weeks and months to
>>> explain all customers that they have to fix their client configs
>>>
On 6/7/2014 10:53 AM, li...@rhsoft.net wrote:
>
>
> Am 07.06.2014 17:25, schrieb Noel Jones:
>> I wonder why you're just trying to stop SASL from those client...
>> Why not just use reject_rbl_client (and maybe other restrictions)
>> before permit_sasl_authenticated to reject all mail from them?
Am 07.06.2014 09:59, schrieb Kai Krakow:
> Hello list!
>
> Is there a way to prevent postfix from offering SASL auth (and that
> includes
> denying open relaying) to clients based on DNS RBL lookups? I've discovered
> the option smtpd_sasl_exceptions_networks which allows to do that by adding
Am 07.06.2014 18:29, schrieb LuKreme:
>
> On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
>
>> i condsidered that but it would take weeks and months to
>> explain all customers that they have to fix their client configs
>> and i see even new configured clients using 25 because the idiotic
>>
On 07 Jun 2014, at 09:53 , li...@rhsoft.net wrote:
> i condsidered that but it would take weeks and months to
> explain all customers that they have to fix their client configs
> and i see even new configured clients using 25 because the idiotic
> MUA's still default to 25 and burrie the port set
Am 07.06.2014 17:25, schrieb Noel Jones:
> I wonder why you're just trying to stop SASL from those client...
> Why not just use reject_rbl_client (and maybe other restrictions)
> before permit_sasl_authenticated to reject all mail from them? If
> you're unwilling to accept SASL credentials, why
On 6/7/2014 8:33 AM, Kai Krakow wrote:
> Wietse Venema schrieb:
>
>> Kai Krakow:
>>> Hello list!
>>>
>>> Is there a way to prevent postfix from offering SASL auth (and
>>> that includes denying open relaying) to clients based on DNS RBL
>>> lookups? I've discovered the option smtpd_sasl_exception
Kai Krakow:
> How is one supposed to automatically block such hijacked accounts within
> postfix? A simple heuristic could be detecting unusual high mail volume for
> that account, probably by detecting the always repeating or similar
> subjects.
Typically, this is done with postfwd (a third-pa
Wietse Venema schrieb:
> Kai Krakow:
>> Hello list!
>>
>> Is there a way to prevent postfix from offering SASL auth (and
>> that includes denying open relaying) to clients based on DNS RBL
>> lookups? I've discovered the option smtpd_sasl_exceptions_networks
>> which allows to do that by adding
Kai Krakow:
> Hello list!
>
> Is there a way to prevent postfix from offering SASL auth (and
> that includes denying open relaying) to clients based on DNS RBL
> lookups? I've discovered the option smtpd_sasl_exceptions_networks
> which allows to do that by adding static subnet entries or adding
>
32 matches
Mail list logo
