Hi.
I’m using following rules in main.cf
smtpd_recipient_restrictions = permit_mynetworks,check_recipient_access
regexp:/opt/trend/imss/postfix/etc/postfix/access,reject_unauth_pipelining,
reject_non_fqdn_recipient,reject_unknown_recipient_domain,
reject_unauth_destination, l
Hello,
I've got two issues. The first is I'm blocking file attachments in the
mime_headers file below. I'd like to allow those attachments but only
for hosts within the domain, so for example us...@example.com can send
us...@example.com a word document.
The second issue is I'm running virtual use
> "Noel" == Noel Jones writes:
Noel> On 3/31/2017 3:50 PM, John Stoffel wrote:
>> So I created the following entry in my header_checks file:
>>
>> /^Delivered-To:/ WARN Found email with Delivered-To: header already in it!
>>
>> And while it did correctly warn on a bogus email that matched w
On Mon, Apr 03, 2017 at 02:03:41PM -0400, Viktor Dukhovni wrote:
> > Any idea is welcome.
>
> For Postfix 3.2.0 see: https://github.com/vdukhovni/postfix/pull/8
> For 3.3-20170218, see: https://github.com/vdukhovni/postfix/pull/7
>
> The underlying patch is identical. There could be other ways
Just for the record, Victor's finding falsifies the claim that the
problem, once triggered, persists across postfix stop/start.
I suggest moving the fix into the teardown_milters() function. It's
still not perfect, but it keeps things in one place.
Wietse
*** ./src/smtpd/smtpd.c-
> On Apr 3, 2017, at 1:24 PM, Christian Rößner
> wrote:
>
> Any idea is welcome.
For Postfix 3.2.0 see: https://github.com/vdukhovni/postfix/pull/8
For 3.3-20170218, see: https://github.com/vdukhovni/postfix/pull/7
The underlying patch is identical. There could be other ways
to address the
On Mon, Apr 03, 2017 at 05:08:58PM +0200, Christian Rößner wrote:
> I enabled the smptd_milter_maps again and triggered the problem again.
> After that I counted seconds. And while counting, I sent mails from remote
> each 5 seconds. I aborted after more than 6 minutes. Then I waited about
> 80 s
> Am 03.04.2017 um 17:53 schrieb Wietse Venema :
>
> Christian Ro??ner:
>> I did the opposite test now and disabled the smtpd_milter_maps
>> parameter. After that I did the same tests again and milters work
>> always. So enabling this map starts producing the described issue.
>
> And the problem
Christian Ro??ner:
> I did the opposite test now and disabled the smtpd_milter_maps
> parameter. After that I did the same tests again and milters work
> always. So enabling this map starts producing the described issue.
And the problem persists across stopping and starting Postfix,
therefore the
> On Apr 3, 2017, at 11:07 AM, Mario Theodoridis
> wrote:
>
>> If you own a domain that should not be receiving email, you can prevent
>> MTAs trying to send mail to it by explicitly specifying a null MX in the
>> DNS:
>>
>>bikinibottom.com. IN MX 0 .
>
> Good to know, thanks Philip.
Not
> Am 03.04.2017 um 16:47 schrieb Christian Rößner
> :
>
>>
>> Am 03.04.2017 um 16:07 schrieb Christian Rößner
>> :
>>
>>>
>>> Am 03.04.2017 um 15:43 schrieb Wietse Venema :
>>>
>>> Wietse Venema:
> After I ran this (in fact I was too slow ;-) ), I sent a mail from
> external MTA m
On 03/04/17 16:56, Philip Paeps wrote:
If you own a domain that should not be receiving email, you can prevent
MTAs trying to send mail to it by explicitly specifying a null MX in the
DNS:
bikinibottom.com. IN MX 0 .
Good to know, thanks Philip.
--
Mit Freundlichen Grüßen / Regards
Mario
On 2017-03-31 15:01:17 (+0200), Ralf Hildebrandt wrote:
> * Mario Theodoridis :
> > i'm having a curious issue with our postfix instance.
> >
> > It seems it is sending emails to a domain's A record when no MX is found.
> >
> > Is that standard?
>
> Yes.
>
> > If so, can i disable this somewhe
> Am 03.04.2017 um 16:07 schrieb Christian Rößner
> :
>
>>
>> Am 03.04.2017 um 15:43 schrieb Wietse Venema :
>>
>> Wietse Venema:
After I ran this (in fact I was too slow ;-) ), I sent a mail from
external MTA mail.sys4.de and this mail did not run through any
of the milters. I
> Am 03.04.2017 um 15:43 schrieb Wietse Venema :
>
> Wietse Venema:
>>> After I ran this (in fact I was too slow ;-) ), I sent a mail from
>>> external MTA mail.sys4.de and this mail did not run through any
>>> of the milters. It is much more worse than I thought, because each
>>> mail after that
Wietse Venema:
> > After I ran this (in fact I was too slow ;-) ), I sent a mail from
> > external MTA mail.sys4.de and this mail did not run through any
> > of the milters. It is much more worse than I thought, because each
> > mail after that "mail loop" above was not scanned by any milters
> > a
> After I ran this (in fact I was too slow ;-) ), I sent a mail from
> external MTA mail.sys4.de and this mail did not run through any
> of the milters. It is much more worse than I thought, because each
> mail after that "mail loop" above was not scanned by any milters
> anymore! I also stopped po
Hi,
> Am 31.03.2017 um 10:48 schrieb Christian Rößner
> :
>
> Hi,
>
>> Am 30.03.2017 um 17:25 schrieb Viktor Dukhovni :
>>
>>
>>> On Mar 30, 2017, at 11:15 AM, Christian Rößner
>>> wrote:
>>>
>>> It is a VM, but the host uses ECC-RAM. No errors were reported to the
>>> kernel message bu
18 matches
Mail list logo
