Re: gmail servers requiring postscreen_access whitelisting

[Peter]

On 10/04/16 15:00, Curtis Villamizar wrote:
> This is a workaround that shouldn't be needed.
> 
> Any idea what the cause of this is?  So far no legit mail except gmail
> gets caught here.

gmail uses hundreds, or thousands of MTAs and has the unique property
that when they retry after a deferral it is almost always from a
different server (IP).  So postfix clears one IP and they retry from
another which postfix did not clear yet.  Rinse and repeat ad-nauseum.

The only workaround is to either receive so much mail from google that
you eventually get most of their servers on your temporary whitelist, or
to whitelist them in some other way.  newer versions of postfix allow
you to whitelist based on DNSWLS and if you use dnswl.org it will
include the google servers.  In older versions of postfix you will need
to whitelist them manually like you have already done, but they change
from time to time so you need to keep the list up to date.


Peter

Re: gmail servers requiring postscreen_access whitelisting

[Bastian Blank]

On Sat, Apr 09, 2016 at 11:00:53PM -0400, Curtis Villamizar wrote:
> Any idea what the cause of this is?  So far no legit mail except gmail
> gets caught here.

Don't use after-greeting tests in postscreen.  The postscreen
documentation explains exactly why this happens.

Bastian

-- 
"What terrible way to die."
"There are no good ways."
-- Sulu and Kirk, "That Which Survives", stardate unknown

Re: gmail servers requiring postscreen_access whitelisting

[Wietse Venema]

Curtis Villamizar:
> Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
> getting logs of this form:
> 
> Apr  9 01:08:12 mta1 postfix/postscreen[18326]:
>   NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999:
>   450 4.3.2 Service currently unavailable;
>   from=, to=,
>   proto=ESMTP, helo=

DO NOT turn on the after-220 tests:

postscreen_non_smtp_command_enable = no
postscreen_pipelining_enable = no
postscreen_bare_newline_enable = no

Wietse

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

[Wietse Venema]

> > No-one can connect to this from outside.
> 
> That's correct.  Not currently, to this current machine/port, in
> this configuration.

If someone can connect from outside to your 127.0.0.1 port, then
you have a serious infrastructure problem.

Wietse

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

[jasonsu]

On Sun, Apr 10, 2016, at 06:42 AM, Wietse Venema wrote:
> > > No-one can connect to this from outside.
> > 
> > That's correct.  Not currently, to this current machine/port, in
> > this configuration.
> 
> If someone can connect from outside to your 127.0.0.1 port, then
> you have a serious infrastructure problem.

Yes, that's obvious for the current configuration.

Like I said, " ... currently, to this current machine/port, in this 
configuration."

it will change.

Re: gmail servers requiring postscreen_access whitelisting

[Curtis Villamizar]

In message <3qjz5d5s15zj...@spike.porcupine.org>
Wietse Venema writes:
> 
> Curtis Villamizar:
> > Since I enabled postscreen (with soft_bounce=yes in master.cf) I was
> > getting logs of this form:
> > 
> > Apr  9 01:08:12 mta1 postfix/postscreen[18326]:
> >   NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999:
> >   450 4.3.2 Service currently unavailable;
> >   from=, to=,
> >   proto=ESMTP, helo=
>  
> DO NOT turn on the after-220 tests:
>  
> postscreen_non_smtp_command_enable = no
> postscreen_pipelining_enable = no
> postscreen_bare_newline_enable = no
>  
>   Wietse


Based on the terseness of this authoritative response I'll assume this
topic has already been beat to death and the limited benefits of these
tests simply are not worth the headaches.

Peter gave a useful workaround.  I'll reply on that thread.

I had enabled _pipelining_ and _non_smtp_command_ but not
_bare_newline_.  For now I've disabled these tests.

Curtis

Re: gmail servers requiring postscreen_access whitelisting

[Curtis Villamizar]

In message <570a341b.9000...@pajamian.dhs.org>
Peter writes:
> 
> On 10/04/16 15:00, Curtis Villamizar wrote:
> > This is a workaround that shouldn't be needed.
> > 
> > Any idea what the cause of this is?  So far no legit mail except gmail
> > gets caught here.
>  
> gmail uses hundreds, or thousands of MTAs and has the unique property
> that when they retry after a deferral it is almost always from a
> different server (IP).  So postfix clears one IP and they retry from
> another which postfix did not clear yet.  Rinse and repeat ad-nauseum.
>  
> The only workaround is to either receive so much mail from google that
> you eventually get most of their servers on your temporary whitelist, or
> to whitelist them in some other way.  newer versions of postfix allow
> you to whitelist based on DNSWLS and if you use dnswl.org it will
> include the google servers.  In older versions of postfix you will need
> to whitelist them manually like you have already done, but they change
> from time to time so you need to keep the list up to date.
>  
> Peter


This seems like it could be a viable workaround for the after 220
problem.

  postscreen_dnsbl_sites =
  list.dnswl.org*-5
  # followed by some blacklist sites

It could occasionally delay mail from all legitimate senders not in
dnswl.org (almost everyone but a few big guys) if they try both the
primary and secondary MX and those two MX have independent temporary
whitelists.  Tying the temporary whitelists together (so the secondary
immediately passes postscreen tests) using a routable address (since
they are at different sites) seems horribly insecure.  If there was a
way to wrap the connection in TLS, then OK.

Occasionally delaying legitimate mail is to be avoided and I don't see
a workaround for that.

OTOH, as soon as I turned this off some obvious spam got through,
probably bot spam not yet listed in a dnsbl and clever enough to not
get snagged by spamassasin (not all that hard apparently).

The next question is whether the after 220 stops enough spam that the
other tests wouldn't get to make it worth the bother.  Apparently,
based on Wietse's terse comment, he thinks not.

So I'll go with Wietse's advice and disable after 220 tests and see if
I can find an alternative to stop the remaining dribble of spam.

Curtis

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

[Curtis Villamizar]

In message <3qjzc32dcxzj...@spike.porcupine.org>
Wietse Venema writes:
> 
> > > No-one can connect to this from outside.
> > 
> > That's correct.  Not currently, to this current machine/port, in
> > this configuration.
>  
> If someone can connect from outside to your 127.0.0.1 port, then
> you have a serious infrastructure problem.
>  
>   Wietse

Or (assuming that there are no user account on the server) another
service running on the same host that has been compromised.

This is further leveraging a breach.  Of course that means that there
had to already be a non-root breach of something else (which would
already be a bad thing).  But that can't possibly happen (right?).

I'm not a fan of mistaking the loopback interface for a hardenned
security feature.  Unix domain sockets or fifo (ala mkfifo and chmod)
are a better choice than inet with loopback IMO, reducing the chance
of leverage.  Loopback is like a socket or fifo with ugo+rw perms.

Curtis

Re: bad.psky.me RBL?

[Bill Cole]

On 6 Apr 2016, at 10:48, Quanah Gibson-Mount wrote:

Is anyone familiar with this RBL and its quality?  Not a whole lot of 
info at .  Terms seem probably ok 
.


Not trustable: in blackhat vs. whitehat terms: nowhere to put a hat)

1. Not clearly the responsibility of any human or corporate entity of 
any reputation of any sort.


2. They have illegitimately appropriated the "RBL" trademark originally 
registered to MAPS and still used by Trend Micro, owner of all of the 
old MAPS IP (and when last I dealt with them, even some vintage 2000 
MAPS operational assets...)


3. Bogus domain registration info.

4. Apparently reliant on a tiny number of commodity "cloud" VPS's for 
everything: web, base domain DNS, and DNSBL DNS.


5. Weird DNS formal structure. Wildcard SOA for *.bad.psky.me but no 
matching wildcard NS, which could lead to corner-case breakage, because 
they don't return NXDOMAIN for *ANY* query. Evidence of DNS 
incompetence, not what you want in a DNSBL operator.


6. Use of providers (NameCheap & Digital Ocean) that are notable as 
recently preferred providers of professional snowshoe spammers.


This doesn't mean that their data is bad, but unlike the Spamhaus lists 
or even the tragically shoddy Trend Micro versions of the RBL and other 
MAPS lists, it's clear that bad.psky.me is run by someone lacking a 
range of resources (courage, technical skills, cash, integrity, etc.) 
needed to merit trust in a DNSBL.

Re: Improving / fixing my helo_access restriction matches?

[Bill Cole]

On 8 Apr 2016, at 11:22, /dev/rob0 wrote:


EHLO outbound-42.compuserv.com

Yes, compuserv is gone, but it's a nice illustration of how the
string, "user", can appear in a legitimate EHLO.


Tangent: CompuServe was indeed bought by AOL via WorldCom and eventually 
(just a few years ago... ) all their distinct services were killed off, 
but AOL maintains the registration and DNS for compuserve.com and there 
are in fact operational (ish) *.compuserve.com hosts.


On the other hand, compuserv.com is a different story, in that it is 
registered to a domain broker and seems to be available for sale. I 
expect it is massively overpriced.

Re: gmail servers requiring postscreen_access whitelisting

[@lbutlr]

On Apr 10, 2016, at 10:24 AM, Curtis Villamizar  
wrote:
>  postscreen_dnsbl_sites =
>  list.dnswl.org*-5
>  # followed by some blacklist sites

It was my understanding that eh the order of test said not matter because all 
the dnsbls listed would be checked, a final score computed, and then that 
compound number passed along to postscreen.

-- 
Rid yourself of doubt -- or should you? -George Carlin

Re: gmail servers requiring postscreen_access whitelisting

[Wietse Venema]

@lbutlr:
> On Apr 10, 2016, at 10:24 AM, Curtis Villamizar =
>  wrote:
> >  postscreen_dnsbl_sites =3D
> >  list.dnswl.org*-5
> >  # followed by some blacklist sites
> 
> It was my understanding that eh the order of test said not matter =
> because all the dnsbls listed would be checked, a final score computed, =
> and then that compound number passed along to postscreen.

Correct. The lookups are done in parallel, and the score is updated
as the results become available. As long as the numbers are small
enough (no integer over/underflow), the update order does not matter. 

Wietse

Re: False positives from header_checks

[Bill Cole]

On 9 Apr 2016, at 9:00, Wietse Venema wrote:


Unfortunately, I don't have time to decode this discussion. Can
someone post a tested diff, someone maybe post a revised version,
and when there is agreement, then I can adopt it.



Simplest fix: prevent *that* class of false positives by narrowing the 
check to a single attribute, rather than including all attributes in the 
header following one which includes 'name' in its name:


-  /^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
+  /^Content-(Disposition|Type).*name\s*=\s*"?([^;]*(\.|=2E)(

As Viktor noted: regular expressions are the wrong toolkit for MIME 
parsing. A proper mature MIME parser is available for Postfix in the 
MIMEDefang milter, which also is a fine tool for hooking in SpamAssassin 
and AV tools.

Re: bad.psky.me RBL?

[lists]

When this question first arrived, I mediated on why would anyone even bother to 
set up a RBL these days, as if there aren't enough players. Some do charge for 
the service if you are a large volume user, but to charge you do need a track 
record to prove your worth. RBL seems like a not so profitable place for a 
start up.

Now a RBL does get a stream of meta data. To some degree, they know who is 
emailing to who. If you are the only user of a domain, the meta data is 
focused. I suppose that data could be sold. 

That was the limit of my "deep thinking" (cough cough).  

Regarding Digital Ocean, I'm on their VPS. I catch very sporadic ‎hacking from 
their clients, like one every one or two months. Being a client, I report the 
incidents. But unless you are on a one month free trial account, sending spam 
or hacking from a VPS seems like a bad idea since your IP is unique. On a 
hosting company, your IP is mixed with all their clients. You get lost in the 
noise.

One of the reasons I set up a VPS was to specifically not get tarred with 
spammers on a hosting company.

I'm not so sure Names Cheap implies a shady business these days. Old school 
registrars like Verisign have become like Go Daddy, so there is no premium 
neighborhood as far as I know.

  Original Message  
From: Bill Cole
Sent: Sunday, April 10, 2016 10:45 AM
To: Postfix users
Reply To: Postfix users
Subject: Re: bad.psky.me RBL?

On 6 Apr 2016, at 10:48, Quanah Gibson-Mount wrote:

> Is anyone familiar with this RBL and its quality? Not a whole lot of 
> info at . Terms seem probably ok 
> .

Not trustable: in blackhat vs. whitehat terms: nowhere to put a hat)

1. Not clearly the responsibility of any human or corporate entity of 
any reputation of any sort.

2. They have illegitimately appropriated the "RBL" trademark originally 
registered to MAPS and still used by Trend Micro, owner of all of the 
old MAPS IP (and when last I dealt with them, even some vintage 2000 
MAPS operational assets...)

3. Bogus domain registration info.

4. Apparently reliant on a tiny number of commodity "cloud" VPS's for 
everything: web, base domain DNS, and DNSBL DNS.

5. Weird DNS formal structure. Wildcard SOA for *.bad.psky.me but no 
matching wildcard NS, which could lead to corner-case breakage, because 
they don't return NXDOMAIN for *ANY* query. Evidence of DNS 
incompetence, not what you want in a DNSBL operator.

6. Use of providers (NameCheap & Digital Ocean) that are notable as 
recently preferred providers of professional snowshoe spammers.

This doesn't mean that their data is bad, but unlike the Spamhaus lists 
or even the tragically shoddy Trend Micro versions of the RBL and other 
MAPS lists, it's clear that bad.psky.me is run by someone lacking a 
range of resources (courage, technical skills, cash, integrity, etc.) 
needed to merit trust in a DNSBL.

Re: False positives from header_checks

[Wietse Venema]

Bill Cole:
> On 9 Apr 2016, at 9:00, Wietse Venema wrote:
> 
> > Unfortunately, I don't have time to decode this discussion. Can
> > someone post a tested diff, someone maybe post a revised version,
> > and when there is agreement, then I can adopt it.
> 
> 
> Simplest fix: prevent *that* class of false positives by narrowing the 
> check to a single attribute, rather than including all attributes in the 
> header following one which includes 'name' in its name:
> 
> -  /^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
> +  /^Content-(Disposition|Type).*name\s*=\s*"?([^;]*(\.|=2E)(

Thanks, got it.

> As Viktor noted: regular expressions are the wrong toolkit for MIME 
> parsing. A proper mature MIME parser is available for Postfix in the 
> MIMEDefang milter, which also is a fine tool for hooking in SpamAssassin 
> and AV tools.

Absolutely. But this class of false positives is easy to remove.

Wietse

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[Bill Cole]

On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote:

I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing* 
support for those is logged, but not - yet - acted on.


This is dangerous, as is raising the bar too high on ciphersuites.

Case in point: Ditech is one of the largest mortgage servicing companies 
in the US, servicing millions of loans ultimately held by the federal 
government. They send email responses to customer service inquiries out 
via Microsoft's Office365 service, which signs it for the 
"gtservicing.onmicrosoft.com" domain, but has it routed through Cisco 
(formerly Ironport's) "iphmx.com" infrastructure for no visible reason, 
where the From header is apparently re-written to 
, breaking the DKIM signature. While the 
iphmx.com machines accept mail from Microsoft using the suboptimal 
AES256-SHA ciphersuite, they inexplicably use the affirmatively weak 
TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the 
envelope sender (donotre...@gtservicing.com) has a domain with an SPF 
record that is invalid due to its excessive complexity. Topping this 
off, their messages consistently contain nothing but a bunch of 
disclaimer boilerplate plus a link to the REAL message (which thankfully 
is also usually low-content boilerplate) in a .doc file on the 
sharefile.com service, with no authentication required to access the 
link.


This is how security-competent a significant US financial services 
company is regarding email: broken DKIM signatures, invalid SPF records, 
and confidential information regarding mortgage accounts sitting at URLs 
accessible by anyone who can intercept a piece of email which AT BEST is 
transported using encryption which may be crackable in reasonable time 
by entities much weaker than the NSA.


BUT: People *REALLY* want their customer service email from Ditech. If 
you block invalid SPF, it fails. If you block invalid DKIM signatures, 
it fails. If you require strong encryption, it fails. It is possible (I 
have not tested...) that if you require strong encryption or none ("may" 
with a restrictive cipherlist) they may deliver potentially critically 
private information in the clear.


Welcome to 2016: Sturgeon's Law remains in effect.

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[jasonsu]

On Sun, Apr 10, 2016, at 03:13 PM, Bill Cole wrote:
> On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote:
> 
> > I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing* 
> > support for those is logged, but not - yet - acted on.
> 

> as is raising the bar too high on ciphersuites.

That I'm sold on.

> This is dangerous, 

This, not so much.

> Case in point: Ditech ...

Great example & reminder.

But,

(1) I'm not an ESP
(2) If a company publishes a policy, then fails to follow it, not my problem.  
It's theirs.

Yep I know that that's gonna cost me some 'Ditech-esque' mail.

> Welcome to 2016: Sturgeon's Law remains in effect.

Unfortunately, Sturgeon -- as was Orwell -- was an optimist :-/

Jason

Re: gmail servers requiring postscreen_access whitelisting

[Curtis Villamizar]

In message 
"@lbutlr" writes:
> 
> On Apr 10, 2016, at 10:24 AM, Curtis Villamizar =
>  wrote:
> >  postscreen_dnsbl_sites =3D
> >  list.dnswl.org*-5
> >  # followed by some blacklist sites
>  
> It was my understanding that eh the order of test said not matter
> because all the dnsbls listed would be checked, a final score
> computed, and then that compound number passed along to postscreen.

Nobody ever said there was an order dependence.

btw- I don't think list.dnswl.org is a viable workaround for the post
220 problem.  This just affects the dnsbl score which would already be
zero.  The post 220 checks would still be run before putting the gmail
server IP into the temporary whitelist.  Manual maintenance of
postscreen_access is the only thing that would work.

Curtis

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[Curtis Villamizar]

In message <500a9284-b549-460d-8207-f52534e09...@billmail.scconsult.com>
"Bill Cole" writes:
> 
> On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote:
>  
> > I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing* 
> > support for those is logged, but not - yet - acted on.
>  
> This is dangerous, as is raising the bar too high on ciphersuites.
>  
> Case in point: Ditech is one of the largest mortgage servicing companies 
> in the US, servicing millions of loans ultimately held by the federal 
> government. They send email responses to customer service inquiries out 
> via Microsoft's Office365 service, which signs it for the 
> "gtservicing.onmicrosoft.com" domain, but has it routed through Cisco 
> (formerly Ironport's) "iphmx.com" infrastructure for no visible reason, 
> where the From header is apparently re-written to 
> , breaking the DKIM signature. While the 
> iphmx.com machines accept mail from Microsoft using the suboptimal 
> AES256-SHA ciphersuite, they inexplicably use the affirmatively weak 
> TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the 
> envelope sender (donotre...@gtservicing.com) has a domain with an SPF 
> record that is invalid due to its excessive complexity. Topping this 
> off, their messages consistently contain nothing but a bunch of 
> disclaimer boilerplate plus a link to the REAL message (which thankfully 
> is also usually low-content boilerplate) in a .doc file on the 
> sharefile.com service, with no authentication required to access the 
> link.
>  
> This is how security-competent a significant US financial services 
> company is regarding email: broken DKIM signatures, invalid SPF records, 
> and confidential information regarding mortgage accounts sitting at URLs 
> accessible by anyone who can intercept a piece of email which AT BEST is 
> transported using encryption which may be crackable in reasonable time 
> by entities much weaker than the NSA.
>  
> BUT: People *REALLY* want their customer service email from Ditech. If 
> you block invalid SPF, it fails. If you block invalid DKIM signatures, 
> it fails. If you require strong encryption, it fails. It is possible (I 
> have not tested...) that if you require strong encryption or none ("may" 
> with a restrictive cipherlist) they may deliver potentially critically 
> private information in the clear.
>  
> Welcome to 2016: Sturgeon's Law remains in effect.


Great anecdote of a really bad email setup but ...

For a lot of us missing out on Ditech, a specialist in preditory
lending, is not a compelling reason not to enable SPF, DKIM and DMARC.

For my domains (all automated DNS zone file generation) I publish SPF
and DKIM (and any relevant DNSSEC crud and TLSA) and was planning to
update the homegrown tool to add DMARC.  By publishing those records,
you just avoid having someone forge mail as you (including to you, but
there are plenty of simpler ways to protect against that).  I was also
planning to reject based on opendmarc at some point in the
not-so-distant future.

Curtis

Re: gmail servers requiring postscreen_access whitelisting

[Peter]

On 11/04/16 11:37, Curtis Villamizar wrote:
> btw- I don't think list.dnswl.org is a viable workaround for the post
> 220 problem.  This just affects the dnsbl score which would already be
> zero.  The post 220 checks would still be run before putting the gmail
> server IP into the temporary whitelist.  Manual maintenance of
> postscreen_access is the only thing that would work.

You need postfix 2.11 and later then you can use
postscreen_dnsbl_whitelist_threshold to allow whitelisted servers skip
the after-220 tests and therefore not get delayed.


Peter

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[lists]

Then again, the customer service department for an item I ordered has no DKIM. 
The company is using netsuite.com as a portal.  I suppose I can try to contact 
their IT...

I found another legit emailer with SPF but no DKIM. A corporate user that is 
using a barracuda service of some sort. 

I've yet to find email from an actual person that doesn't have DKIM or SPF. It 
is the "and" that doesn't work.

One of the email verification services put me in the top 3% of servers based on 
security. At the time, I though that was nuts. But looking typical email 
headers, that might be true. 

‎
‎

  Original Message  
From: jaso...@mail-central.com
Sent: Sunday, April 10, 2016 4:08 PM
To: postfix-users@postfix.org
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On Sun, Apr 10, 2016, at 03:13 PM, Bill Cole wrote:
> On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote:
> 
> > I block on strict FAILs of any if SPF, DKIM or DMARC. *missing* 
> > support for those is logged, but not - yet - acted on.
> 

> as is raising the bar too high on ciphersuites.

That I'm sold on.

> This is dangerous, 

This, not so much.

> Case in point: Ditech ...

Great example & reminder.

But,

(1) I'm not an ESP
(2) If a company publishes a policy, then fails to follow it, not my problem. 
It's theirs.

Yep I know that that's gonna cost me some 'Ditech-esque' mail.

> Welcome to 2016: Sturgeon's Law remains in effect.

Unfortunately, Sturgeon -- as was Orwell -- was an optimist :-/

Jason

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[Viktor Dukhovni]

> On Apr 10, 2016, at 8:49 PM, li...@lazygranch.com wrote:
> 
> I've yet to find email from an actual person that doesn't have DKIM or SPF.

I've never emailed you directly.  This will be the first time.

-- 
Viktor.

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[Bill Cole]

On 10 Apr 2016, at 20:00, Curtis Villamizar wrote:


Great anecdote of a really bad email setup but ...

For a lot of us missing out on Ditech, a specialist in preditory
lending, is not a compelling reason not to enable SPF, DKIM and DMARC.


The power of a brand shows itself...

Whether or not one approves of the company that now owns and 
inexplicably chose to revive the Ditech brand name recently is 
irrelevant, as are the predatory practices of GMAC when they existed and 
owned that brand. People with conventional "prime" mortgages don't 
really have any say in who services their loan from one year to the 
next: the servicing rights become a highly liquid market commodity once 
Fannie or Freddie holds the actual loan.


My point was that there are companies that people cannot readily choose 
to not do business with who send mail in ways which indicate that they 
have tried but very much failed to adhere to modern security standards. 
On a system where you know enough about all your users to know that they 
don't want to get critical email from clueless sources, you can make 
restrictive choices with no trouble. If you don't actually know that, 
choosing to require senders to use rigorous security correctly will 
often lead to unpleasant surprises.

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

[jasonsu]

On Sun, Apr 10, 2016, at 07:46 PM, Bill Cole wrote:
> On a system where you know enough about all your users to know that they 
> don't want to get critical email from clueless sources, you can make 
> restrictive choices with no trouble. If you don't actually know that, 
> choosing to require senders to use rigorous security correctly will 
> often lead to unpleasant surprises.


Ya gotta break a few eggs to make an omelette ;-)