On Jul 24, 2012, at 2:37 AM, Stan Hoeppner wrote:
> On 7/24/2012 12:44 AM, CSS wrote:
>>
>> On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote:
>>
>>> On 7/23/2012 4:16 PM, CSS wrote:
>>>
I'd like to take some measures to limit what an authenticated sender can
do but not limit legitim
On 7/24/2012 2:08 AM, CSS wrote:
> Perhaps I'm misunderstanding this, but I was under the impression that the
> anvil limits were all enforced on a per-connection or per-IP limit. I'm
> really after something that can track a particular sasl-authenticated user
> and punish them (and not other
At 04:16 PM 7/23/2012, you wrote:
>Hello,
>
>Sorry for the broad question, but is there any sort of best common practice
>these days regarding limiting outbound email? We recently had a customer's
>account compromised (not sure if it was brute-forced or keylogged) and then
>the perp proceeded t
Len Conrad:
> I've been using postfwd.org for rate-limiting outbound senders,
> and inbound senders and IPs, plus lots of other inbound filtering,
> for a 2+ years. It killed our horrible problem of cracked passwords.
I think that dedicated tools such as postfwd and the like are the
way to go. Th
We store our virtual_foo_maps in,
/etc/posfix/maps/virtual_foo_maps.pgsql
and so the (read-only) database credentials are visible in that file.
I'd like to tighten this up if possible, but I don't want to do anything
stupid.
If I'm not going about this all wrong, what can I do to prevent e.g.
On Jul 24, 2012, at 18:09, Michael Orlitzky wrote:
> We store our virtual_foo_maps in,
>
> /etc/posfix/maps/virtual_foo_maps.pgsql
>
> and so the (read-only) database credentials are visible in that file.
> I'd like to tighten this up if possible, but I don't want to do anything
> stupid.
>
>
On Jul 24, 2012, at 02:22, Ori Bani wrote:
> On Mon, Jul 23, 2012 at 5:07 PM, Viktor Dukhovni
> wrote:
>> On Mon, Jul 23, 2012 at 03:33:53PM -0700, Marty Beckler wrote:
>>
>>> Transport next hops can have MX lookups disabled by adding [] around
>>> the next hop.
>>>
>>> Is it possible to define
On 07/24/12 12:24, DTNX Postmaster wrote:
> On Jul 24, 2012, at 18:09, Michael Orlitzky wrote:
>
>> We store our virtual_foo_maps in,
>>
>> /etc/posfix/maps/virtual_foo_maps.pgsql
>>
>> and so the (read-only) database credentials are visible in that file.
>> I'd like to tighten this up if possibl
On Jul 24, 2012, at 6:23 AM, Len Conrad wrote:
> At 04:16 PM 7/23/2012, you wrote:
>> Hello,
>>
>> Sorry for the broad question, but is there any sort of best common practice
>> these days regarding limiting outbound email? We recently had a customer's
>> account compromised (not sure if it wa
On Wednesday, July 25, 2012 at 12:09 AM, Michael Orlitzky wrote:
> We store our virtual_foo_maps in,
>
> /etc/posfix/maps/virtual_foo_maps.pgsql
>
> and so the (read-only) database credentials are visible in that file.
> I'd like to tighten this up if possible, but I don't want to do anything
Le 24/07/2012 08:37, Stan Hoeppner a écrit :
> On 7/24/2012 12:44 AM, CSS wrote:
>>
>> On Jul 24, 2012, at 1:24 AM, Stan Hoeppner wrote:
>>
>>> On 7/23/2012 4:16 PM, CSS wrote:
>>>
I'd like to take some measures to limit what an authenticated sender can
do but not limit legitimate use.
>
Le 24/07/2012 18:09, Michael Orlitzky a écrit :
> We store our virtual_foo_maps in,
>
> /etc/posfix/maps/virtual_foo_maps.pgsql
>
> and so the (read-only) database credentials are visible in that file.
> I'd like to tighten this up if possible, but I don't want to do anything
> stupid.
>
> If
On 07/24/2012 07:33 PM, mouss wrote:
>
> map_directory = /var/db/postmap
> cidr = cidr:${map_directory}/cidr
> db = ${db_type}:${map_directory}/${db_type}
> map_directory = /var/db/postmap
> regex = ${regex_type}:${map_directory}/${regex_type}
> sql = ${sql_type}:${map_directory}/${sql_type}
> ...
Hi,
Recently I got request if our mail server can notify the receiver if there
is email spam and if the receiver feel it genuine email then they can
release it by them self. Does postfix can do this? Or does anyone has
implement this?
Thank you
14 matches
Mail list logo