Request for feedback on SMTPD restrictions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Request for feedback on SMTPD restrictions

J Doe
Hi,

I have a basic SMTP server set up with what I believe to be good smtpd_*_ restrictions, but I was wondering if anyone could provide any insight on how to improve them or if I have been redundant in the restrictions.  Even with reading the man pages, I find some of the restrictions tricky.

I am eventually having a submission service (with an -o smtpd_relay_restrictions=permit_sasl_authenticated in master.cf), for this server but right now what follows is just for a SMTP server on port 25.

smtpd_client_restrictions = permit_mynetworks,
        reject_unauth_pipelining,
        check_client_access hash:/etc/postfix/client_acl,
        reject_unknown_client_hostname,
        permit

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
        reject_unauth_pipelining,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        check_helo_access hash:/etc/postfix/helo_acl,
        reject_unknown_helo_hostname,
        permit

smtpd_sender_restrictions = permit_mynetworks,
        reject_unauth_pipelining,
        reject_non_fqdn_sender,
        check_sender_access hash:/etc/postfix/sender_acl,
        reject_unknown_sender_domain,
        permit

smtpd_recipient_restrictions = permit_mynetworks,      
        permit_auth_destination,                                                          
        reject                                                                            
                                                                                                                 
smtpd_relay_restrictions = permit_mynetworks,                                                                    
        permit_auth_destination,                                                              
        reject

Thanks,

- J
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Noel Jones-2
On 1/20/2018 11:56 PM, J Doe wrote:

> Hi,
>
> I have a basic SMTP server set up with what I believe to be good smtpd_*_ restrictions, but I was wondering if anyone could provide any insight on how to improve them or if I have been redundant in the restrictions.  Even with reading the man pages, I find some of the restrictions tricky.
>
> I am eventually having a submission service (with an -o smtpd_relay_restrictions=permit_sasl_authenticated in master.cf), for this server but right now what follows is just for a SMTP server on port 25.
>
> smtpd_client_restrictions = permit_mynetworks,
> reject_unauth_pipelining,
> check_client_access hash:/etc/postfix/client_acl,
> reject_unknown_client_hostname,
>         permit

reject_unknown_client_hostname is likely to reject legit mail.  Use
with caution.

Consider instead using reject_unknown_reverse_client_hostname, which
rejects clients with no PTR record.  This is similar to what many
large providers do and is fairly low risk.

The "permit" at the end is unnecessary, but doesn't break anything.
Same with all the other "permit" in restrictions below.

>
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks,
> reject_unauth_pipelining,
>         reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname,
> check_helo_access hash:/etc/postfix/helo_acl,
> reject_unknown_helo_hostname,
> permit

reject_unknown_helo_hostname is likely to reject legit mail.  Use
with caution.



  -- Noel Jones

>
> smtpd_sender_restrictions = permit_mynetworks,
> reject_unauth_pipelining,
> reject_non_fqdn_sender,
> check_sender_access hash:/etc/postfix/sender_acl,
>         reject_unknown_sender_domain,
>         permit
>
> smtpd_recipient_restrictions = permit_mynetworks,      
> permit_auth_destination,                                                          
> reject                                                                            
>                                                                                                                  
> smtpd_relay_restrictions = permit_mynetworks,                                                                    
> permit_auth_destination,                                                              
>         reject
>
> Thanks,
>
> - J
>

Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

lists@lazygranch.com
On Sun, 21 Jan 2018 14:35:42 -0600
Noel Jones <[hidden email]> wrote:

> On 1/20/2018 11:56 PM, J Doe wrote:
> > Hi,
> >
> > I have a basic SMTP server set up with what I believe to be good
> > smtpd_*_ restrictions, but I was wondering if anyone could provide
> > any insight on how to improve them or if I have been redundant in
> > the restrictions.  Even with reading the man pages, I find some of
> > the restrictions tricky.
> >
> > I am eventually having a submission service (with an -o
> > smtpd_relay_restrictions=permit_sasl_authenticated in master.cf),
> > for this server but right now what follows is just for a SMTP
> > server on port 25.
> >
> > smtpd_client_restrictions = permit_mynetworks,
> > reject_unauth_pipelining,
> > check_client_access hash:/etc/postfix/client_acl,
> > reject_unknown_client_hostname,
> >         permit  
>
> reject_unknown_client_hostname is likely to reject legit mail.  Use
> with caution.
>
> Consider instead using reject_unknown_reverse_client_hostname, which
> rejects clients with no PTR record.  This is similar to what many
> large providers do and is fairly low risk.
>
> The "permit" at the end is unnecessary, but doesn't break anything.
> Same with all the other "permit" in restrictions below.
>
> >
> > smtpd_helo_required = yes
> > smtpd_helo_restrictions = permit_mynetworks,
> > reject_unauth_pipelining,
> >         reject_invalid_helo_hostname,
> > reject_non_fqdn_helo_hostname,
> > check_helo_access hash:/etc/postfix/helo_acl,
> > reject_unknown_helo_hostname,
> > permit  
>
> reject_unknown_helo_hostname is likely to reject legit mail.  Use
> with caution.
>
>
>
>   -- Noel Jones
>
> >
> > smtpd_sender_restrictions = permit_mynetworks,
> > reject_unauth_pipelining,
> > reject_non_fqdn_sender,
> > check_sender_access hash:/etc/postfix/sender_acl,
> >         reject_unknown_sender_domain,
> >         permit
> >
> > smtpd_recipient_restrictions = permit_mynetworks,      
> > permit_auth_destination,                                                          
> > reject                                                                            
> >                                                                                                                  
> > smtpd_relay_restrictions =
> > permit_mynetworks,
> > permit_auth_destination, reject
> >
> > Thanks,
> >
> > - J
> >  
>

Doing some reading on the PTR record, I believe I've have been doing my
MX record incorrectly. The reverse DNS can only point to one domain
name. If you are hosting multiple domains on one server, all MX records
should point to the domain name that has the PTR record.

For example, suppose the "main" domain of the server is example.com. In
this case, example.com has the PTR record. If you also host
something.com at the same IP address, the MX record for something.com
should point to example.com, not something.com.

https://serverfault.com/questions/158828/ptr-record-rdns-for-multiple-domains-on-a-shared-ip-address

Is my interpretation correct?

As an aside, note the superfluous "permit" shows up in many guides
online, but not all of them. I experimented dropping the extra permit
and things worked, but put them back in anyway out of paranoia. I'm
going to drop them now.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Matus UHLAR - fantomas
On 21.01.18 00:56, J Doe wrote:
>I have a basic SMTP server set up with what I believe to be good smtpd_*_
> restrictions, but I was wondering if anyone could provide any insight on
> how to improve them or if I have been redundant in the restrictions.  Even
> with reading the man pages, I find some of the restrictions tricky.

>smtpd_helo_required = yes
>smtpd_helo_restrictions = permit_mynetworks,
> reject_unauth_pipelining,
>        reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname,
> check_helo_access hash:/etc/postfix/helo_acl,
> reject_unknown_helo_hostname,
> permit

I'd put check_helo_access before reject_invalid_helo_hostname and
reject_non_fqdn_helo_hostname, so I could allow some hosts use HELO string
that would otherwise be rejected.

You can sometimes get a machine with hardcoded and unconfigurable HELO
string.

>smtpd_sender_restrictions = permit_mynetworks,
> reject_unauth_pipelining,
> reject_non_fqdn_sender,
> check_sender_access hash:/etc/postfix/sender_acl,
>        reject_unknown_sender_domain,
>        permit

Here I recommend the opposite - putting reject_unknown_sender_domain before
check_sender_access, unless you have sane reason to accept mail from invalid
domains (maybe one like the above).

>smtpd_recipient_restrictions = permit_mynetworks,
> permit_auth_destination,
> reject
>
>smtpd_relay_restrictions = permit_mynetworks,
> permit_auth_destination,
>        reject

I believe putting "reject_unauth_destination, permit" is better than
"permit_auth_destination, reject", if you put any kind of restrictions in
the future.

Also, with "reject_unauth_destination" you can skip the default "permit"

On 21.01.18 14:35, Noel Jones wrote:

>> smtpd_client_restrictions = permit_mynetworks,
>> reject_unauth_pipelining,
>> check_client_access hash:/etc/postfix/client_acl,
>> reject_unknown_client_hostname,
>>         permit
>
>reject_unknown_client_hostname is likely to reject legit mail.  Use
>with caution.
>
>Consider instead using reject_unknown_reverse_client_hostname, which
>rejects clients with no PTR record.  This is similar to what many
>large providers do and is fairly low risk.

I think that reject_unknown_reverse_client_hostname is not a good idea -
having fake/invalid PTR record is imho worse than than no PTR record.

check_client_access before it (either one) is proper way to configure local
whitelists.

>> smtpd_helo_required = yes
>> smtpd_helo_restrictions = permit_mynetworks,
>> reject_unauth_pipelining,
>>         reject_invalid_helo_hostname,
>> reject_non_fqdn_helo_hostname,
>> check_helo_access hash:/etc/postfix/helo_acl,
>> reject_unknown_helo_hostname,
>> permit
>
>reject_unknown_helo_hostname is likely to reject legit mail.  Use
>with caution.

I believe the same as above applies.

On 21.01.18 17:44, [hidden email] wrote:
>Doing some reading on the PTR record, I believe I've have been doing my
>MX record incorrectly. The reverse DNS can only point to one domain
>name.

incorrect - IP can have multiple PTR records, although it's not recommended.
- single PTR is more safe, because you need only care about one reverse
(and forward) DNS record.

> If you are hosting multiple domains on one server, all MX records
>should point to the domain name that has the PTR record.

Incorrect.

The only case multiple MX should point to the same hostname is when using
SSL/TLS certificate, and in such case all MX records should point to hostname
in the certificate - not to the contents of PTR record.

Note that using SSL/TLS between servers is not widespread and I don't know
of client rejecting delivery to server with mismatched certificate


simply said:
The PTR record has NOTHING in common with MX records.

I have already encountered cases, where people were doing stupid things to
fullfill this "requirement".  This is one of things nice to have, but other
things may be more important than this one.


>As an aside, note the superfluous "permit" shows up in many guides
>online, but not all of them. I experimented dropping the extra permit
>and things worked, but put them back in anyway out of paranoia. I'm
>going to drop them now.

the "permit" is default (implicit) for most (if not all) of the directives.
As its description says:

permit
      Permit the request. This restriction is useful at the end of a
      restriction list, to make the default policy explicit.

--
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.
Windows found: (R)emove, (E)rase, (D)elete
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Bill Cole-3
In reply to this post by lists@lazygranch.com
On 21 Jan 2018, at 20:44 (-0500), [hidden email] wrote:

> The reverse DNS can only point to one domain
> name.

Not so. Multiple PTR records for one address may violate some people's
expectations, but it's not wrong if the address doesn't really have a
public name that is more "real" than the others.

> If you are hosting multiple domains on one server,

Niggle: not one server, one IP address. A server can have many IP
addresses and there's a long history of people asking here how to make
Postfix use specific IPs for specific domains, for essentially cosmetic
reasons. The multi-instance support mostly ended that FAQ.

> all MX records
> should point to the domain name that has the PTR record.

That really makes no difference. It is arguably good practice to have a
PTR reversing every A record but simplicity is arguably more important,
so having just one A and one PTR for each name/IP pair is fine, even if
that IP is handling mail for many domains.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

J Doe
In reply to this post by Noel Jones-2
Hi Noel,

> On Jan 21, 2018, at 3:35 PM, Noel Jones <[hidden email]>
>> smtpd_client_restrictions = permit_mynetworks,
>>    reject_unauth_pipelining,
>>    check_client_access hash:/etc/postfix/client_acl,
>>    reject_unknown_client_hostname,
>>        permit
>
> reject_unknown_client_hostname is likely to reject legit mail.  Use
> with caution.
>
> Consider instead using reject_unknown_reverse_client_hostname, which
> rejects clients with no PTR record.  This is similar to what many
> large providers do and is fairly low risk.

Thank you for your feedback.

Ok, I will move from: reject_unknown_client_hostname to: reject_unknown_reverse_client_hostname as I am looking to block senders that do not provide reverse DNS lookup.  These usually show up in my logs with Postfix identifying their connecting IP address but a DNS value of “unknown”.

> The "permit" at the end is unnecessary, but doesn't break anything.
> Same with all the other "permit" in restrictions below

Interesting.  Ok, I had thought it was required.  I think I may keep them, even though they’re redundant, as it seems to document the intent a bit better.

>> smtpd_helo_required = yes
>> smtpd_helo_restrictions = permit_mynetworks,
>>    reject_unauth_pipelining,
>>        reject_invalid_helo_hostname,
>>    reject_non_fqdn_helo_hostname,
>>    check_helo_access hash:/etc/postfix/helo_acl,
>>    reject_unknown_helo_hostname,
>>    permit
>
> reject_unknown_helo_hostname is likely to reject legit mail.  Use
> with caution.

Ok, although I checked man 5 postconf again for the definition:

“Reject the request when the HELO or EHLO hostname has no DNS A or MX record.”

Is there ever a case where a legitimate mail sender would not have either an A (and I assume if it is an IPv6 sender an AAAA record), or a MX record ?

The other way I had looked at it was that since the SMTP error code for this is 4xx, if it does reject a legitimate sender the sender would queue the message and try again.  I would assume that not having A/AAAA or MX would be transient for a legitimate sender.

- J
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

J Doe
In reply to this post by Matus UHLAR - fantomas
Hi,

> On Jan 22, 2018, at 8:43 AM, Matus UHLAR - fantomas <[hidden email]> wrote:
>
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions = permit_mynetworks,
>>    reject_unauth_pipelining,
>>       reject_invalid_helo_hostname,
>>    reject_non_fqdn_helo_hostname,
>>    check_helo_access hash:/etc/postfix/helo_acl,
>>    reject_unknown_helo_hostname,
>>    permit
>
> I'd put check_helo_access before reject_invalid_helo_hostname and
> reject_non_fqdn_helo_hostname, so I could allow some hosts use HELO string
> that would otherwise be rejected.
>
> You can sometimes get a machine with hardcoded and unconfigurable HELO
> string.

Ok.  

The idea behind this was that the only legitimate server I have seen connecting that: a) has a transient reverse DNS lookup problem and b) sometimes passes that but gives a HELO/EHLO hostname that Postfix 3.1.0 rejects is Outlook.com.

So for a client restriction I whitelist a client that has a reverse DNS lookup of:

outbound.protection.outlook.com    permit

I then whitelist the EHLO/HELO hostname with the helo_acl list:

outbound.protection.outlook.com    permit

This works regardless of the Outlook.com server connecting as the names partially match (ie: a real Outlook server might be server-1234.outbound.protection.outlook.com, another might be server-5678.outbound.protection.outlook.com and so forth).

Is this not a good idea, though ?

Also, the last part where you state “You can sometimes get a machine with hard-corded and un-configurable HELO string”, is that you can sometimes get this from a *legitimate*  server ?

>> smtpd_sender_restrictions = permit_mynetworks,
>>    reject_unauth_pipelining,
>>    reject_non_fqdn_sender,
>>    check_sender_access hash:/etc/postfix/sender_acl,
>>       reject_unknown_sender_domain,
>>       permit
>
> Here I recommend the opposite - putting reject_unknown_sender_domain before
> check_sender_access, unless you have sane reason to accept mail from invalid
> domains (maybe one like the above).

Ah, right - good catch.

>> smtpd_recipient_restrictions = permit_mynetworks,
>>    permit_auth_destination,
>>    reject
>>
>> smtpd_relay_restrictions = permit_mynetworks,
>>    permit_auth_destination,
>>       reject
>
> I believe putting "reject_unauth_destination, permit" is better than
> "permit_auth_destination, reject", if you put any kind of restrictions in
> the future.
>
> Also, with "reject_unauth_destination" you can skip the default "permit"

Ok.  One thing that confused me even though it works - why is permitting an authorized destination (either through permit_auth_destination or via reject_unauth_destination), required for relaying if I want people to be able to deliver to recipients at my domain ?

If I remove the permission of authorized destinations and if I host mail for say example.com, I cannot receive mail for [hidden email] without the permission of authorized destinations for smtpd_relay_restrictions.  I tested this by sending mail to [hidden email] and it would reject it without this permission.

Thanks again,

- J
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

lists@lazygranch.com
In reply to this post by Bill Cole-3
Replies in the middle of the email for clarity.
On Mon, 22 Jan 2018 17:18:42 -0500
"Bill Cole" <[hidden email]> wrote:

> On 21 Jan 2018, at 20:44 (-0500), [hidden email] wrote:
>
> > The reverse DNS can only point to one domain
> > name.  
>
> Not so. Multiple PTR records for one address may violate some
> people's expectations, but it's not wrong if the address doesn't
> really have a public name that is more "real" than the others.
>

OK, on Digital Ocean, you only get one reverse DNS per "droplet".

So if I do a reverse DNS lookup on some IP addresses, I will get
multiple domains?
> > If you are hosting multiple domains on one server,  
>
> Niggle: not one server, one IP address. A server can have many IP
> addresses and there's a long history of people asking here how to
> make Postfix use specific IPs for specific domains, for essentially
> cosmetic reasons. The multi-instance support mostly ended that FAQ.

Yeah, I screwed up.
>
> > all MX records
> > should point to the domain name that has the PTR record.  
>
> That really makes no difference. It is arguably good practice to have
> a PTR reversing every A record but simplicity is arguably more
> important, so having just one A and one PTR for each name/IP pair is
> fine, even if that IP is handling mail for many domains.
>

And in practice, doing it wrong doesn't seem to stop the email from
going out.

As it turns out, between the two Digital Ocean droplets I'm running
(the one I'm on now and the new one I'm setting up), none have the
reverse DNS set up properly. Reading the postfix documentation, all
that is required is a reverse DNS point to something. There doesn't
have to be a match.

"reject_unknown_reverse_client_hostname
Reject the request when the client IP address has no address->name
mapping."

I put in a few "features" from this website:
http://en.linuxreviews.org/HOWTO_Stop_spam_using_Postfix
This link is similar, though he suggests fail2ban. I find the anvil
code works good enough.
http://centosfaq.org/centos/sasl-attacks-and-spam/

Comments appreciated. I generally just trawl this list and makes
changes as people suggest. Or not change anything as Viktor always
suggests. ;-)

# SASL
smtpd_sasl_type = dovecot
broken_sasl_auth_clients = yes
smtpd_helo_required = yes
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_non_fqdn_recipient,
  reject_rbl_client rhsbl.scientificspam.net,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client cbl.abuseat.org,
  reject_rbl_client b.barracudacentral.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  reject_rbl_client rabl.nuclearelephant.com,
  reject_rbl_client zen.spamhaus.org,
  check_policy_service unix:private/policy
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources
smtpd_sender_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_address,
  check_sender_access hash:/etc/postfix/spamsources
smtpd_relay_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_policy_service unix:private/policy
#lines added after hacker attack
smtpd_error_sleep_time = 2s
smtpd_soft_error_limit = 3
smtpd_hard_error_limit = 6
smtpd_client_connection_rate_limit = 3
smtpd_client_auth_rate_limit = 20
smtpd_client_connection_count_limit = 3
smtpd_client_new_tls_session_rate_limit = 3
smtpd_client_recipient_rate_limit = 3
smtpd_recipient_limit = 14


Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Noel Jones-2
In reply to this post by J Doe
On 1/22/2018 8:36 PM, J Doe wrote:

>>> smtpd_helo_required = yes
>>> smtpd_helo_restrictions = permit_mynetworks,
>>>    reject_unauth_pipelining,
>>>        reject_invalid_helo_hostname,
>>>    reject_non_fqdn_helo_hostname,
>>>    check_helo_access hash:/etc/postfix/helo_acl,
>>>    reject_unknown_helo_hostname,
>>>    permit
>>
>> reject_unknown_helo_hostname is likely to reject legit mail.  Use
>> with caution.
>
> Ok, although I checked man 5 postconf again for the definition:
>
> “Reject the request when the HELO or EHLO hostname has no DNS A or MX record.”
>
> Is there ever a case where a legitimate mail sender would not have either an A (and I assume if it is an IPv6 sender an AAAA record), or a MX record ?

Yes, it's not terribly unusual for a legit HELO hostname to not resolve.

>
> The other way I had looked at it was that since the SMTP error code for this is 4xx, if it does reject a legitimate sender the sender would queue the message and try again.  
... retry again and again for days and days.  Set the error codes to
5xx after a suitable testing period.


> I would assume that not having A/AAAA or MX would be transient for a legitimate sender.

postfix will always use a 4xx code for a transient DNS error.

The HELO hostname is treated differently from the client hostname
and the sender email domain.

It's not unusual for the HELO hostname to be non-resolvable, AND
having a non-resolvable HELO hostname isn't a particularly strong
spam indicator.

Strong spam indicators for the HELO are
(note: this is for mail coming from the internet. Authenticated
submission mail or legit mail from devices on your network might
break any of these)
- a dynamic hostname (eg. 89-73-46-234.dynamic.chello.pl, which
resolves just fine)
- my own hostname or localhost (old spammer trick still in use)
- a bare IP address nn.nn.nn.nn  (disallowed by RFC)
- an ip literal eg. [nn.nn.nn.nn] (allowed by RFC; but IME always spam)



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Dominic Raferd
On 23 January 2018 at 04:20, Noel Jones <[hidden email]> wrote:
Strong spam indicators for the HELO are
(note: this is for mail coming from the internet. Authenticated
submission mail or legit mail from devices on your network might
break any of these)
- a dynamic hostname (eg. 89-73-46-234.dynamic.chello.pl, which
resolves just fine)
​...

​Is there a method (regex?) for reliably identifying dynamic ip addresses?​ Take for instance 199-127-103-235.static.avestadns.com - it looks dynamic to me but it says it is static. Is it best/safest to rely on '\.dynamic\.' occurring in the name?
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Petri Riihikallio
Dominic Raferd <[hidden email]> wrote on 23.01.2018 at 9:06:
>
> ​Is there a method (regex?) for reliably identifying dynamic ip addresses?​ Take for instance 199-127-103-235.static.avestadns.com - it looks dynamic to me but it says it is static. Is it best/safest to rely on '\.dynamic\.' occurring in the name?

You example is probably a static IP a customer has leased from their ISP’s pool. Some ISPs won’t set up a custom PTR record for such.

No, there is no definite way of identifying dynamic IPs. You may use some regex but it will produce both false negatives and positives. Something along:
/\d+\.(dyn(amic)?|ppoe|pools?|dialup|dsl|rev)(\.[-_A-Za-z0-9]{2,}){2,}$/
You'll have to consider whether it is more worth than it is trouble.

br, Petri


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Kris Deugau
In reply to this post by Dominic Raferd
Dominic Raferd wrote:
> ​Is there a method (regex?) for reliably identifying dynamic ip
> addresses?

Short answer:  No.

If you really insist on going down that rabbit hole, look up the
RDNS_DYNAMIC rule from Apache SpamAssassin.  It's an aggregation of 25
provider-specific probably-dynamic rDNS patterns.

>​ Take for instance 199-127-103-235.static.avestadns.com
> - it looks dynamic to me but it says it is static.

That, right there, is why not.

There is no One True Standard, and even within the more common
conventions there are quite a few variations.

This particular example would be from a provider that has declared a
range of IPs to be static IP assignments, and which has deployed a set
of default records in a particular form so that (presumably) all of
those IPs have IP->name->IP mappings even if they don't have customer-
or service-specific rDNS names on them.

-kgd
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Andrew Sullivan
On Tue, Jan 23, 2018 at 10:50:24AM -0500, Kris Deugau wrote:
>
> There is no One True Standard, and even within the more common conventions
> there are quite a few variations.

And even if people came up with a standard, the operator could lie.
After all, it's just DNS.  There are no DNS Police to come and tell
you that you are using names wrong, or revoke your Internet license if
you do so.

Best regards,

A

--
Andrew Sullivan
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Dominic Raferd
On 23 January 2018 at 16:12, Andrew Sullivan <[hidden email]> wrote:
> On Tue, Jan 23, 2018 at 10:50:24AM -0500, Kris Deugau wrote:
>>
>> There is no One True Standard, and even within the more common conventions
>> there are quite a few variations.
>
> And even if people came up with a standard, the operator could lie.
> After all, it's just DNS.  There are no DNS Police to come and tell
> you that you are using names wrong, or revoke your Internet license if
> you do so.

OK points taken thanks. Corollary: an outgoing mailserver needs an
rDNS that *indicates* a static ip - regardless of whether the ip is
actually static or dynamic. Because plenty of real-world mailservers
do block or severely limit mail from 'dynamic IPs' (e.g. gmail) but
they can base this only on a 'best guess'.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Bill Cole-3
In reply to this post by lists@lazygranch.com
On 22 Jan 2018, at 22:31 (-0500), [hidden email] wrote:

> So if I do a reverse DNS lookup on some IP addresses, I will get
> multiple domains?

Yes, as long as you use a DNS resolution tool and not a client of the
abstracted name resolver of your OS (which may use a complex federation
of naming services.) I had multiple PTRs for a dozen years on my
external NAT addresses when my IP provider was willing to delegate
authority for my in-addr.arpa space to my nameserver. It never caused
any problem more significant than confused humans. The legacy standard
resolver functions (gethostbyname & gethostbyaddr) accommodate the
potential many-to-many mapping of addresses and names, but for reasons I
don't understand, the modern standard reverse resolution function
(getnameinfo) does not.

There is imprecise language in RFC1035 (1987) implying that there should
be only one PTR per IP but it depends on the idea of a "primary host
name" for an IP, which is not  universally meaningful or useful as a
naming concept.


--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Noel Jones-2
In reply to this post by Dominic Raferd
On 1/23/2018 1:06 AM, Dominic Raferd wrote:

> On 23 January 2018 at 04:20, Noel Jones <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Strong spam indicators for the HELO are
>     (note: this is for mail coming from the internet. Authenticated
>     submission mail or legit mail from devices on your network might
>     break any of these)
>     - a dynamic hostname (eg. 89-73-46-234.dynamic.chello.pl
>     <http://89-73-46-234.dynamic.chello.pl>, which
>     resolves just fine)
>     ​...
>
>
> ​Is there a method (regex?) for reliably identifying dynamic ip
> addresses?​ Take for instance 199-127-103-235.static.avestadns.com
> <http://199-127-103-235.static.avestadns.com> - it looks dynamic to
> me but it says it is static. Is it best/safest to rely on
> '\.dynamic\.' occurring in the name?


There is no simple regexp, but there is the fqrdns.pcre project. The
project is a large hand-maintained list of dynamic hostnames with a
goal of zero false positives.  It's not perfect, but it's useful and
safe for general use.

https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre




  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Andrew Sullivan
In reply to this post by Bill Cole-3
On Tue, Jan 23, 2018 at 11:51:37AM -0500, Bill Cole wrote:
>
> There is imprecise language in RFC1035 (1987) implying that there should be
> only one PTR per IP but it depends on the idea of a "primary host name" for
> an IP, which is not  universally meaningful or useful as a naming concept.

We attempted to make this clearer at one point
(https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06)
but the draft was so controversial that it never managed to find
consensus until it was watered down to say "A may be A.  Or maybe not.
You choose."  Didn't seem a lot of point in publishing by then.

Best regards,

A

--
Andrew Sullivan
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Dominic Raferd
In reply to this post by Noel Jones-2
On 23 January 2018 at 16:55, Noel Jones <[hidden email]> wrote:

> On 1/23/2018 1:06 AM, Dominic Raferd wrote:
>> On 23 January 2018 at 04:20, Noel Jones <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Strong spam indicators for the HELO are
>>     (note: this is for mail coming from the internet. Authenticated
>>     submission mail or legit mail from devices on your network might
>>     break any of these)
>>     - a dynamic hostname (eg. 89-73-46-234.dynamic.chello.pl
>>     <http://89-73-46-234.dynamic.chello.pl>, which
>>     resolves just fine)
>>     ...
>>
>>
>> Is there a method (regex?) for reliably identifying dynamic ip
>> addresses? Take for instance 199-127-103-235.static.avestadns.com
>> <http://199-127-103-235.static.avestadns.com> - it looks dynamic to
>> me but it says it is static. Is it best/safest to rely on
>> '\.dynamic\.' occurring in the name?
>
>
> There is no simple regexp, but there is the fqrdns.pcre project. The
> project is a large hand-maintained list of dynamic hostnames with a
> goal of zero false positives.  It's not perfect, but it's useful and
> safe for general use.
>
> https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre

Thanks Noel I have added that to my recipe (but modified the plus and
max formulae to hold rather than reject mails).
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Matus UHLAR - fantomas
In reply to this post by J Doe
>>> smtpd_helo_required = yes
>>> smtpd_helo_restrictions = permit_mynetworks,
>>>    reject_unauth_pipelining,
>>>       reject_invalid_helo_hostname,
>>>    reject_non_fqdn_helo_hostname,
>>>    check_helo_access hash:/etc/postfix/helo_acl,
>>>    reject_unknown_helo_hostname,
>>>    permit

>> On Jan 22, 2018, at 8:43 AM, Matus UHLAR - fantomas <[hidden email]> wrote:
>> I'd put check_helo_access before reject_invalid_helo_hostname and
>> reject_non_fqdn_helo_hostname, so I could allow some hosts use HELO string
>> that would otherwise be rejected.
>>
>> You can sometimes get a machine with hardcoded and unconfigurable HELO
>> string.

On 22.01.18 22:10, J Doe wrote:

>The idea behind this was that the only legitimate server I have seen
> connecting that: a) has a transient reverse DNS lookup problem and b)
> sometimes passes that but gives a HELO/EHLO hostname that Postfix 3.1.0
> rejects is Outlook.com.
>
>So for a client restriction I whitelist a client that has a reverse DNS lookup of:
>
>outbound.protection.outlook.com    permit
>
>I then whitelist the EHLO/HELO hostname with the helo_acl list:
>
>outbound.protection.outlook.com    permit

"OK" probably, permit only applies for postscreen

>Is this not a good idea, though ?

permitting based on dns name? usually not a problem.

>Also, the last part where you state “You can sometimes get a machine with
> hard-corded and un-configurable HELO string”, is that you can sometimes
> get this from a *legitimate* server ?

I meant local machines like copiers, faxes etc.

>>> smtpd_recipient_restrictions = permit_mynetworks,
>>>    permit_auth_destination,
>>>    reject
>>>
>>> smtpd_relay_restrictions = permit_mynetworks,
>>>    permit_auth_destination,
>>>       reject
>>
>> I believe putting "reject_unauth_destination, permit" is better than
>> "permit_auth_destination, reject", if you put any kind of restrictions in
>> the future.
>>
>> Also, with "reject_unauth_destination" you can skip the default "permit"
>
>Ok.  One thing that confused me even though it works - why is permitting an
> authorized destination (either through permit_auth_destination or via
> reject_unauth_destination), required for relaying if I want people to be
> able to deliver to recipients at my domain ?

If you receive mail for local recipients, you are not relaying.
Relaying means you are sending mail from non-local senders to non-local
recipients.

both "permit_auth_destination, reject"
and "reject_unauth_destination, permit"

prevent you from relaying unauthenticated clients. However I recommend the
latter, where you:

1. can put other reasons for message rejection
2. don't have to put "permit" at the end

>If I remove the permission of authorized destinations and if I host mail
> for say example.com, I cannot receive mail for [hidden email] without
> the permission of authorized destinations for smtpd_relay_restrictions.  I
> tested this by sending mail to [hidden email] and it would reject it
> without this permission.

if you leave "reject" at the end, of course you reject all mail.

--
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.
On the other hand, you have different fingers.
Reply | Threaded
Open this post in threaded view
|

Re: Request for feedback on SMTPD restrictions

Voytek
In reply to this post by Noel Jones-2
On Wed, January 24, 2018 3:55 am, Noel Jones wrote:

> There is no simple regexp, but there is the fqrdns.pcre project. The
> project is a large hand-maintained list of dynamic hostnames with a goal of
> zero false positives.  It's not perfect, but it's useful and safe for
> general use.
>
> https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre

within my current list, where should I add ?

    check_client_access hash:/etc/postfix/whitelist
    check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre


smtpd_recipient_restrictions =.
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,.
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_unlisted_recipient,
 permit_mynetworks,
 check_sasl_access hash:/etc/postfix/sasl_access
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_recipient_access hash:/etc/postfix/recipient_no_checks,
 check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
 check_helo_access hash:/etc/postfix/helo_checks,
 check_sender_access hash:/etc/postfix/sender_checks,
 check_client_access hash:/etc/postfix/client_checks,
 check_client_access pcre:/etc/postfix/client_checks.pcre,
 reject_rbl_client zen.spamhaus.org,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
 reject_rbl_client psbl.surriel.com,
 reject_rbl_client ix.dnsbl.manitu.net,
 reject_rbl_client bl.spamcop.net,


12