A problem I'm not sure how best to solve

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

A problem I'm not sure how best to solve

Phil Stracchino
I have a perplexing puzzle thrust upon me.

Consider the following:

Oct  8 15:55:33 minbar postfix/smtpd[7422]: NOQUEUE: reject: RCPT from
rs230.mailgun.us[209.61.151.230]: 551 5.1.8 <[hidden email]>:
Sender address rejected: Domain not found;
from=<bounce+db1162.5fcd4c-alrekr=[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<rs230.mailgun.us>


mailgun.us is connecting with a good HELO, and appears to be authorized
to send mail on behalf of pluspora.com, but the mail has a sender
address that is bad because mg.pluspora.com does not resolve in DNS, and
so the mail is rejected.

I want to TEMPORARILY (I hope) whitelist [hidden email] as a
sender address as long as the mail is being sent by mailgun.us.

How would you do it?



--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Philip Paeps
On 2018-10-08 22:42:27 (-0400), Phil Stracchino wrote:

>I have a perplexing puzzle thrust upon me.
>
>Consider the following:
>
>Oct  8 15:55:33 minbar postfix/smtpd[7422]: NOQUEUE: reject: RCPT from
>rs230.mailgun.us[209.61.151.230]: 551 5.1.8 <[hidden email]>:
>Sender address rejected: Domain not found;
>from=<bounce+db1162.5fcd4c-alrekr=[hidden email]>
>to=<[hidden email]> proto=ESMTP helo=<rs230.mailgun.us>
>
>
>mailgun.us is connecting with a good HELO, and appears to be authorized
>to send mail on behalf of pluspora.com, but the mail has a sender
>address that is bad because mg.pluspora.com does not resolve in DNS, and
>so the mail is rejected.
>
>I want to TEMPORARILY (I hope) whitelist [hidden email] as a
>sender address as long as the mail is being sent by mailgun.us.
>
>How would you do it?

You could add a check_sender_access which returns OK for mg.pluspora.com
before the reject_unknown_sender_domain in smtpd_recipient_restrictions.

(Guessing, because you didn't include your configuration.)

Philip

--
Philip Paeps
Senior Reality Engineer
Ministry of Information
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Matus UHLAR - fantomas
In reply to this post by Phil Stracchino
On 08.10.18 22:42, Phil Stracchino wrote:

>Consider the following:
>
>Oct  8 15:55:33 minbar postfix/smtpd[7422]: NOQUEUE: reject: RCPT from
>rs230.mailgun.us[209.61.151.230]: 551 5.1.8 <[hidden email]>:
>Sender address rejected: Domain not found;
>from=<bounce+db1162.5fcd4c-alrekr=[hidden email]>
>to=<[hidden email]> proto=ESMTP helo=<rs230.mailgun.us>
>
>
>mailgun.us is connecting with a good HELO, and appears to be authorized
>to send mail on behalf of pluspora.com, but the mail has a sender
>address that is bad because mg.pluspora.com does not resolve in DNS, and
>so the mail is rejected.

correct.

>I want to TEMPORARILY (I hope) whitelist [hidden email] as a
>sender address as long as the mail is being sent by mailgun.us.
>
>How would you do it?

I would not whitelist mail from domain that is not deliverable.
they should fix their DNS first.

but if you really want to whitelist them, you must add it to access list
which will be parsed before reject_unknown_sender_domain.


--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson.  -- Daffy Duck & Porky Pig
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Jan P. Kessler
In reply to this post by Philip Paeps

>> I want to TEMPORARILY (I hope) whitelist [hidden email] as a
>> sender address as long as the mail is being sent by mailgun.us.
>>
>> How would you do it?
>
> You could add a check_sender_access which returns OK for
> mg.pluspora.com before the reject_unknown_sender_domain in
> smtpd_recipient_restrictions.

s/OK/permit_auth_destination/

reduces the chance to become an open relay for that sender

Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Phil Stracchino
In reply to this post by Matus UHLAR - fantomas
On 10/9/18 4:37 AM, Matus UHLAR - fantomas wrote:

> I would not whitelist mail from domain that is not deliverable.
> they should fix their DNS first.
>
> but if you really want to whitelist them, you must add it to access list
> which will be parsed before reject_unknown_sender_domain.

Well, I normally wouldn't either, this is just a temporary patch until
they fix their DNS.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Phil Stracchino
In reply to this post by Jan P. Kessler
On 10/9/18 6:10 AM, Jan P. Kessler wrote:

>
>>> I want to TEMPORARILY (I hope) whitelist [hidden email] as a
>>> sender address as long as the mail is being sent by mailgun.us.
>>>
>>> How would you do it?
>>
>> You could add a check_sender_access which returns OK for
>> mg.pluspora.com before the reject_unknown_sender_domain in
>> smtpd_recipient_restrictions.
>
> s/OK/permit_auth_destination/
>
> reduces the chance to become an open relay for that sender

Good call.  Thanks, I didn't think of that.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Phil Stracchino
In reply to this post by Philip Paeps
On 10/9/18 4:33 AM, Philip Paeps wrote:

> You could add a check_sender_access which returns OK for mg.pluspora.com
> before the reject_unknown_sender_domain in smtpd_recipient_restrictions.


Yeah, I tried that as a quick-and-dirty temporary patch; I'm a little
surprised that it appears not to have worked.

......DOH!  Because I inadvertently typed check_*client*_access instead
of check_sender...

OK, let's try this again.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Viktor Dukhovni
I hope you did not forget that "check_sender_access" returning
"OK" must not be used in smtpd_recipient_restrictions prior to
"reject_unauth_destination", unless your configuration is a bit
more "modern" and uses "smtpd_relay_restrictions" to restrict
relay access.

> On Oct 9, 2018, at 10:58 AM, Phil Stracchino <[hidden email]> wrote:
>
> ......DOH!  Because I inadvertently typed check_*client*_access instead
> of check_sender...
>
> OK, let's try this again.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Phil Stracchino
On 10/9/18 11:03 AM, Viktor Dukhovni wrote:
> I hope you did not forget that "check_sender_access" returning
> "OK" must not be used in smtpd_recipient_restrictions prior to
> "reject_unauth_destination", unless your configuration is a bit
> more "modern" and uses "smtpd_relay_restrictions" to restrict
> relay access.


Indeed, reject_unauth_destination is my third rule, after
permit_mynetworks and permit_tls_clientcerts.  And it's my *second*
rule, after permit_tls_clientcerts, in smtpd_relay_restrictions.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Viktor Dukhovni


> On Oct 9, 2018, at 12:12 PM, Phil Stracchino <[hidden email]> wrote:
>
> Indeed, reject_unauth_destination is my third rule, after
> permit_mynetworks and permit_tls_clientcerts.  And it's my *second*
> rule, after permit_tls_clientcerts, in smtpd_relay_restrictions.

If you already have it in smtpd_relay_restrictions, you don't need
to repeat the check in recipient restrictions.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: A problem I'm not sure how best to solve

Phil Stracchino
On 10/9/18 1:56 PM, Viktor Dukhovni wrote:

>
>
>> On Oct 9, 2018, at 12:12 PM, Phil Stracchino <[hidden email]> wrote:
>>
>> Indeed, reject_unauth_destination is my third rule, after
>> permit_mynetworks and permit_tls_clientcerts.  And it's my *second*
>> rule, after permit_tls_clientcerts, in smtpd_relay_restrictions.
>
> If you already have it in smtpd_relay_restrictions, you don't need
> to repeat the check in recipient restrictions.


...And the problem is now moot because it looks like the DNS has been
fixed.  Mail just started coming through.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958