empty MAIL FROM and check_sender_access

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

empty MAIL FROM and check_sender_access

Stefan Bauer-2
Hi,

I'm using smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/allowed_sender

to make sure, my senders only send out with pre-defined and allowed domains.

Now i noticed, that if my users acknowledge "read confirmations" in clients, mails in the following form arrive at postfix:

from=<> to=<[hidden email]> proto=ESMTP helo=<W8PPCN130916>

and will be rejected as empty mail from is not allowed by check_sender_access.

Howto deal with that?
Reply | Threaded
Open this post in threaded view
|

Re: empty MAIL FROM and check_sender_access

Wietse Venema
Stefan Bauer:

> Hi,
>
> I'm using smtpd_sender_restrictions = check_sender_access
> hash:/etc/postfix/allowed_sender
>
> to make sure, my senders only send out with pre-defined and allowed domains.
>
> Now i noticed, that if my users acknowledge "read confirmations" in
> clients, mails in the following form arrive at postfix:
>
> from=<> to=<[hidden email]> proto=ESMTP helo=<W8PPCN130916>
>
> and will be rejected as empty mail from is not allowed by
> check_sender_access.
>
> Howto deal with that?

http://www.postfix.org/postconf.5.html#smtpd_null_access_lookup_key

        Wietse
Reply | Threaded
Open this post in threaded view
|

empty MAIL FROM and check_sender_access

Stefan Bauer-2
I was more asking if it's even a good idea to add the null entry to the table? i would like to be a good postmaster but not want to relax policies for allowed sender addresses.

Am Di., 25. Sep. 2018 um 13:26 Uhr schrieb Wietse Venema <[hidden email]>:

>
> Stefan Bauer:
> > Hi,
> >
> > I'm using smtpd_sender_restrictions = check_sender_access
> > hash:/etc/postfix/allowed_sender
> >
> > to make sure, my senders only send out with pre-defined and allowed domains.
> >
> > Now i noticed, that if my users acknowledge "read confirmations" in
> > clients, mails in the following form arrive at postfix:
> >
> > from=<> to=<[hidden email]> proto=ESMTP helo=<W8PPCN130916>
> >
> > and will be rejected as empty mail from is not allowed by
> > check_sender_access.
> >
> > Howto deal with that?
>
> http://www.postfix.org/postconf.5.html#smtpd_null_access_lookup_key
>
>         Wietse
Reply | Threaded
Open this post in threaded view
|

Re: empty MAIL FROM and check_sender_access

Viktor Dukhovni


> On Sep 25, 2018, at 10:13 AM, Stefan Bauer <[hidden email]> wrote:
>
> I was more asking if it's even a good idea to add the null entry to the table? i would like to be a good postmaster but not want to relax policies for allowed sender addresses.

You need to allow mail with null return addresses.  These are required in bounces
and auto-replies to avoid loops.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: empty MAIL FROM and check_sender_access

Stefan Bauer-2
I notice that only outlook out of all my mail clients, use the null mailer address. it looks to me after reading the standard - that outlook does it right. Is that correct?

Am Di., 25. Sep. 2018 um 17:22 Uhr schrieb Viktor Dukhovni <[hidden email]>:


> On Sep 25, 2018, at 10:13 AM, Stefan Bauer <[hidden email]> wrote:
>
> I was more asking if it's even a good idea to add the null entry to the table? i would like to be a good postmaster but not want to relax policies for allowed sender addresses.

You need to allow mail with null return addresses.  These are required in bounces
and auto-replies to avoid loops.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: empty MAIL FROM and check_sender_access

Viktor Dukhovni


> On Sep 25, 2018, at 12:27 PM, Stefan Bauer <[hidden email]> wrote:
>
> I notice that only outlook out of all my mail clients, use the null mailer address. it looks to me after reading the standard - that outlook does it right. Is that correct?

Outlook is perhaps the only one that is actually sending MDNs.
These are often not supported or enabled in other mail user agents.

--
        Viktor.