Re: Request for feedback on SMTPD restrictions

[Dominic Raferd]

On 23 January 2018 at 04:20, Noel Jones  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?

Re: Request for feedback on SMTPD restrictions

[Noel Jones]

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  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/ 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

Re: Request for feedback on SMTPD restrictions

[li...@lazygranch.com]

Replies in the middle of the email for clarity.
On Mon, 22 Jan 2018 17:18:42 -0500
"Bill Cole"  wrote:

> On 21 Jan 2018, at 20:44 (-0500), li...@lazygranch.com 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

Re: Request for feedback on SMTPD restrictions

[J Doe]

Hi,

> On Jan 22, 2018, at 8:43 AM, Matus UHLAR - fantomas  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.compermit

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

outbound.protection.outlook.compermit

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 whoe...@example.com without the 
permission of authorized destinations for smtpd_relay_restrictions.  I tested 
this by sending mail to whoe...@example.com and it would reject it without this 
permission.

Thanks again,

- J

Re: Request for feedback on SMTPD restrictions

[J Doe]

Hi Noel,

> On Jan 21, 2018, at 3:35 PM, Noel Jones  
>> 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  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/ or MX would be transient 
for a legitimate sender.

- J

Re: Request for feedback on SMTPD restrictions

[Bill Cole]

On 21 Jan 2018, at 20:44 (-0500), li...@lazygranch.com 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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

Re: Self-signed TLS certificates

[DTNX Postmaster]

On 22 Jan 2018, at 15:31, Viktor Dukhovni  wrote:

> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster  wrote:
> 
>>> A "real" certificate is useful if you have customers connecting to
>>> your server as a submission service. While self-signed certs work
>>> fine for that purpose too, sometimes it's easier to avoid talking
>>> folks into how to import your self-signed cert.
>> 
>> Sadly, there are folks who think that a certificate they cannot verify
>> all the way up to a trusted root means that they should fall back to
>> plain text. Mailgun is an example of this, and they are quite widely
>> used despite this and several other problems.
> 
> My view is that if mailgun chooses to shoot itself in the foot and
> considers sending in the clear more secure than unauthenticated TLS
> then so be it, their problem, not mine...
> 
> Have you seen any traffic via mailgun that warrants protection from
> passive monitoring?
> 
> It would be great to compile a list of systems that are broken in
> this manner, and shame them all (politely) in a suitable public
> forum.
> 
> Some senders still don't support TLS at all, even with a CA/B forum
> CA (WebPKI) certificate on the receiving end.

The problem is that Mailgun is used to send transactional email, which might 
contain sensitive data in ways that is not immediately obvious to the user. 
Slack used to use them, for example, including for notifications from private 
channels which might contain things people consider protected.

We talked to Slack at the time, explained what the problem was, difference 
between HTTPS and opportunistic TLS, got all the way up to the CTO, and he 
still got snookered by whatever Mailgun fielded as a counterargument, refused 
to adjust policy expect as a per-domain exception, which isn't very useful 
unless you're spotting it in the logs and open a ticket for it.

Which meant that using a public CA for the MTA certificate was the cheaper 
option, versus having to pick fights. There's simply too many startups out 
there that submit their transactional messages over some HTTPS API, never 
looking at what their deliverability looks like, or think they can 'optimise' 
SMTP, so if spending a little removes the problem entirely, well ... sorted.

Add to that the various pitfalls involved in managing a private CA, which we do 
for other purposes, and the ROI just never happens.

Mvg,
Joni

Re: Self-signed TLS certificates

[Viktor Dukhovni]

> On Jan 22, 2018, at 10:06 AM, Danny Horne  wrote:
> 
> Private CA sounds interesting, will have to read up about it

You can get away with a lot less complexity than the usual OpenSSL CA.
See, for example:

   https://raw.githubusercontent.com/openssl/openssl/master/test/certs/mkcert.sh

which creates certificates via "openssl x509 -req" without all the overhead of
a stateful CA.  What you'd do differently is password-protect the CA key, and
perhaps issue certificates with a somewhat shorter lifetime than the 100 years
in that script.

-- 
Viktor.

Re: Self-signed TLS certificates

[Danny Horne]

On 21/01/2018 9:35 pm, Viktor Dukhovni wrote:
>
> Indeed stick with what you've got.  You could (if not intimidated by the
> logistics, but we may have more tools for you in this space soonish) also
> implement a private CA that signs your no-longer self-signed server cert.
> This makes it possible to publish "3 1 1" + "2 1 1" TLSA records, with
> the "2 1 1" matching the key of your private CA, with that you can rotate
> the server key more frequently, while keeping the CA key password protected.
Private CA sounds interesting, will have to read up about it

Re: canonical based on login name

[Karol Augustin]

On 2018-01-20 16:08, Joris (ideeel) wrote:
> hi list
> 
> I run a webservice (and a mail service). All websites run under the
> same UID of apa...@webserver.domain.com. I know, not ideal, but i
> cannot change that bit. Problem is that if one site gets hacked, user
> apache starts sending spam with no way to figure out which website is
> misbehaving. Thus we are going to enforce websites to use SASL-auth.
> 
> Now the remaining problem is that ,even with SMTP-auth, the MAIL FROM
> username sometimes is still apache. I know gmail rewrites the envelope
> sender and the header sender based on the login name, but i have not
> been able to find how to do this in postfix (canonical_classes does
> not seem to help me here). I cannot really reject the mail using
> reject_authenticated_sender_login_mismatch because the mails will be
> send back to the apache user with again no knowledge of the true
> sender.

Maybe I am not getting something but if you force different SASL-auth
for each website you will have the offending username in the logs.


> 
> hope you can give me some pointers or documentation how I can solve this :)
> 
> best
> Joris


I had exactly the same problem when one of websites I was hosting got
hacked and also wanted to prevent from situation when my user is hacked
(malware) and starts sending emails with matching envelope sender but
forging From header. I ended up using vrfydmn like that:

/usr/bin/python /usr/local/sbin/vrfydmn -F -u vrfydmn -g vrfydmn -s
inet:10072@127.0.0.1 -p /var/run/vrfydmn/vrfydmn.pid

I reject emails from users that try to send them with envelope sender
that they don't own so in my case Postfix makes sure that
envelope-sender is OK (reject_sender_login_mismatch), and then vrfydmn
makes sure that From: matches.

In your case you can (apparently) force PHP to use fixed envelope-from
address. Than you can use this milter to fix From: address. Have a look,
it might be what you need.


https://github.com/croessner/vrfydmn

Karol


--
Karol Augustin
ka...@augustin.pl
http://karolaugustin.pl/
+353 85 775 5312vrfydmn

Re: Self-signed TLS certificates

[Viktor Dukhovni]

> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster  wrote:
> 
>> A "real" certificate is useful if you have customers connecting to
>> your server as a submission service. While self-signed certs work
>> fine for that purpose too, sometimes it's easier to avoid talking
>> folks into how to import your self-signed cert.
> 
> Sadly, there are folks who think that a certificate they cannot verify
> all the way up to a trusted root means that they should fall back to
> plain text. Mailgun is an example of this, and they are quite widely
> used despite this and several other problems.

My view is that if mailgun chooses to shoot itself in the foot and
considers sending in the clear more secure than unauthenticated TLS
then so be it, their problem, not mine...

Have you seen any traffic via mailgun that warrants protection from
passive monitoring?

It would be great to compile a list of systems that are broken in
this manner, and shame them all (politely) in a suitable public
forum.

Some senders still don't support TLS at all, even with a CA/B forum
CA (WebPKI) certificate on the receiving end.

-- 
Viktor.

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, li...@lazygranch.com 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, uh...@fantomas.sk ; 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