from:"Curtis Villamizar"




On 04/12/16 14:26, Noel Jones wrote:

On 4/12/2016 11:38 AM, Curtis Villamizar wrote:

On 04/12/16 06:25, Wietse Venema wrote:

Curtis Villamizar:

I recently had a problem with mail where an ESP was in three
blacklists
plus SPF failed and spamassassin tossed some mail.  That ESP is
down to
one blacklist now.  A sender got to me out-of-band and I dug up the
maillog from a few days earlier and informed them about how good
their
ESP was serving them.  btw- If I had been using postscreen back
then, I
could not have found this in the logs based on sender email.

Incorrect. In the recommended configuration, postscreen will log
IP address, helo, sender, and recipient.

 Wietse

My inexperience with debugging problems with postscreen logs is
showing.

Curtis


Note the helpful logging of helo/sender/recipient requires the
offending test be set to "enforce" rather than "drop".  This is
noted in the docs.
See the various postscreen_*_action parameters for details, such as:
http://www.postfix.org/postconf.5.html#postscreen_dnsbl_action




   -- Noel Jones


I have nothing set to drop.  Just been running postscreen for such a 
short time and on a little used domain (not this one) that mostly gets 
spammed a lot but gets a small amount of legit email from people that 
forgot that I told them not to use it.  So I haven't had to debug a "got 
a bounce" issue with postscreen.


Thanks for the heads up.  By the time I run postscreen on a domain that 
matters I hope to have a good configuration.


Curtis

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


Not an expert on DMARC, but ...

On 04/12/16 01:56, li...@lazygranch.com wrote:

Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
rua to email me a report. Thus far, only MS Hotmail sends me anything, even though I have 
emailed yahoo accounts.

The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
sure what they intended me to use.


The DMARC RFC (rfc7489) indicates that this is failure reporting. That 
would imply that so far only hotmail got forged email that looked like 
it was from your domain.


If you are not getting reports from anyone else, that is a good thing.  
I don't think there is any requirement to send empty reports or that 
those reports would serve any purpose (except maybe create "I got your 
report and here is your" loops).


Curtis

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



On 04/12/16 06:25, Wietse Venema wrote:

Curtis Villamizar:

I recently had a problem with mail where an ESP was in three blacklists
plus SPF failed and spamassassin tossed some mail.  That ESP is down to
one blacklist now.  A sender got to me out-of-band and I dug up the
maillog from a few days earlier and informed them about how good their
ESP was serving them.  btw- If I had been using postscreen back then, I
could not have found this in the logs based on sender email.

Incorrect. In the recommended configuration, postscreen will log
IP address, helo, sender, and recipient.

Wietse


My inexperience with debugging problems with postscreen logs is showing.

Curtis

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




On 04/12/16 12:06, Robert Schetterer wrote:

Am 12.04.2016 um 07:56 schrieb li...@lazygranch.com:

Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
rua to email me a report. Thus far, only MS Hotmail sends me anything, even though I have 
emailed yahoo accounts.

The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
sure what they intended me to use.

or use

https://dmarcian.com/dmarc-xml/


Since programs will usually be reading the XML and producing reports 
locally, XML is a good format.  Plenty of perl and python modules to 
parse XML.


I use emacs and it does a nice job of coloring XML according to function 
(element, attribute, etc).  Its no worse that reading HTML source.

Doing a survey of email clients with SPF and DKIM verification, I only found 
Thunderbird does this, and with a plugin.  Thunderbird is in caretaker status, 
so I don't use it.


I use my phone and thunderbird to preview my IMAP accounts and 
occasionally respond on one or the other.  Then I run fetchmail (with 
TLS) to empty the folder and actually read and archive my mail.


DKIM signature should be done by the MSA.  That would mean postfix for 
most of the people on this list.  Therefore mail sent from any client 
gets DKIM signed.  There is an opendkim milter for this.  MSA should 
authenticate, match to sender (or verify sender somehow) and then DKIM sign.



Thus an identification system (SPF and DKIM ) had been created that mail system 
administrators are loathe to strictly enforce for received email, and with no 
consequences, is only half heartedly complied with on the sending side.  
(Congrats to the interwebs for at least providing many DKIM/SPf verification 
websites.)
That might be partially because they don't understand how it was 
intended to be deployed.  DKIM signature is not intended to be done by 
the MUA as the general case.


And if we agree (OK, some agree) that strict rejection of received email based 
on SPF and DKIM is not a good idea, you would think at least the email clients 
would make detection of these identification methods more automatic.

Hats off to programmers for providing/maintaining tools that the masses don't 
appreciate.

Rejection of mail with DNS records that indicate that mail MUST be from 
a given address range, or MUST be signed, should be honored to prevent 
forgery.  Those domains are saying that they do have their act together 
and know where their mail should be originating from and have the the 
ability to sign it.  The error in DKIM design was that there is no way 
to determine that unsigned mail should have been signed and DMARC fixes 
that.



Best Regards
MfG Robert Schetterer



Curtis

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

2016-04-11 Thread Curtis Villamizar

On 04/11/16 04:09, lst_ho...@kwsoft.de wrote:

Zitat von jaso...@mail-central.com:

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 ;-)

And if you don't want to receive e-mail you should not operate a mail
server or even publish a mail address.

The conversation was about SPF, DKIM, and DMARC (I think). (Drifted
from TLS).

If the sender (or sending ESP) has no clue about what SPF, DKIM, and
DMARC is, then they don't get penalized (or don't get penalized much).
If they publish SPF and/or DKIM records that are wrong, then they get
penalized more, but still not much. If the publish SPF and/or DKIM
records that are wrong and they publish a DMARC record that says "toss
my email if SPF or DKIM doesn't match", then guess what some mail
servers are going to do - including the big ESPs.

The reason DMARC exists is to prevent sender forgery. Expect some of
the big boys to enforce DMARC, meaning that if you publish a DMARC
record that says "toss and increment statistic if SPF or DKIM is wrong",
they will do exactly that. If you don't publish a DMARC record, then
someone could forge as you, but your legitimate mail won't get tossed.

As far as strict TLS - been there, done that - don't recommend it. If
you use ECDSA, then have a long key RSA as a backup. I've had no
trouble AFAIK setting TLS to high though Viktor doesn't recommend it. I
have not yet analyzed logs to see how often this is causing a fallback.

I recently had a problem with mail where an ESP was in three blacklists
plus SPF failed and spamassassin tossed some mail. That ESP is down to
one blacklist now. A sender got to me out-of-band and I dug up the
maillog from a few days earlier and informed them about how good their
ESP was serving them. btw- If I had been using postscreen back then, I
could not have found this in the logs based on sender email.

Curtis

ps - works for google, though dmarc says "accept and report". Google and
Yahoo are allegedly enforcing or will soon be enforcing dmarc (if you
publish a dmarc record).

gmail.com descriptive text "v=spf1 redirect=_spf.google.com"
20120113._domainkey.gmail.com descriptive text "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/UeJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIldNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wimDO+U8QzI3SD0"
"7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9DpSVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5OctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9NOZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLUTD21MycBX5jYchHjPY/wIDAQAB
_dmarc.gmail.com descriptive text "v=DMARC1; p=none;
rua=mailto:mailauth-repo...@google.com;

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

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

In message <b1132232-5b45-4a7b-8fb8-f240cea1f...@kreme.com>
"@lbutlr" writes:
> 
> On Apr 10, 2016, at 10:24 AM, Curtis Villamizar =
> <cur...@orleans.occnc.com> 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: what error is being reported back to sender, and how to avoid reporting back internal server ports?

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: gmail servers requiring postscreen_access whitelisting

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: gmail servers requiring postscreen_access whitelisting

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=<redac...@gmail.com>, 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

In message <5709c8c8.1050...@megan.vbhcs.org>
Noel Jones writes:
 
> On 4/9/2016 10:00 PM, Curtis Villamizar wrote:
> > 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=<redac...@gmail.com>, to=,
> >   proto=ESMTP, helo=
> > 
> > linefeeds added by me for readability.
> > 
> > gmail would just keep trying a half hour later and mail never gets
> > delivered.
> > 
> > rfc3463 isn't very helpful:
> > 
> >   X.3.2   System not accepting network messages
> > 
> > The host on which the mailbox is resident is not accepting
> > messages.  Examples of such conditions include an immanent
> > shutdown, excessive load, or system maintenance.  This is
> > useful for both permanent and permanent transient errors.
> > 
> > I have lines of the form:
> > 
> >   main.cf:
> >   postscreen_access_list =
> >   cidr:$config_directory/postscreen_access
> >   hash:$config_directory/postscreen_reject
> > 
> >   postscreen_access:
> >   #  google mail servers
> >   2607:f8b0:4002:c00::/60 permit
> >   [... other google server blocks ...]
> > 
> > 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.
> > 
> > Curtis
>  
> Look for other warnings and errors in your logs, maybe just before
> the reject, maybe earlier.
>  
>   -- Noel Jones


This is it for that connections:

Apr  9 01:07:15 mta1 postfix/postscreen[18326]: CONNECT from
  [2607:f8b0:4002:c05::22d]:32999 to [2001:470:88e6:1::141]:25
Apr  9 01:07:18 mta1 postfix/tlsproxy[18331]: CONNECT from
  [2607:f8b0:4002:c05::22d]:32999
Apr  9 01:08:12 mta1 postfix/tlsproxy[18331]: Untrusted TLS connection
  established from [2607:f8b0:4002:c05::22d]:32999: TLSv1.2 with cipher
  ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
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=<redac...@gmail.com>, to=,
  proto=ESMTP, helo=
Apr  9 01:08:12 mta1 postfix/postscreen[18326]: PASS NEW
  [2607:f8b0:4002:c05::22d]:32999
Apr  9 01:08:12 mta1 postfix/tlsproxy[18331]: DISCONNECT
  [2607:f8b0:4002:c05::22d]:32999
Apr  9 01:08:12 mta1 postfix/postscreen[18326]: DISCONNECT
  [2607:f8b0:4002:c05::22d]:32999

The IP address got whitelisted but then the next retry from gmail
usually doesn't come from the same IP address and comes 30 minutes
later.  They seem to have some sort of pool of servers that work on
the same set of mail queues.  Today I caught 2 gmails where this
happenned where I didn't have the block in the permit list but each
got delivered on next attempt.

I haven't had postscreen enabled long and only for two domain, one
currently used only for a web site and therefore available for email
testing and the other that is mostly mail to me and gets a fair amount
of spam.

I now have a non-gmail sender where this happened.  In that case after
the 450 it went immediately to the secondary MX that at this time is
not running postscreen and all was fine.

I'll recheck my configs, then post if I can't figure it out.

Curtis

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

In message <20160410024851.gu26...@mournblade.imrryr.org>
Viktor Dukhovni writes:

> On Sat, Apr 09, 2016 at 09:31:48PM -0400, Curtis Villamizar wrote:
>  
> > > 1) It looks to me that starttls really only protects the path to the
> > >first server. Classic case being sending email over the non-secure
> > >coffee shop wifi.
> > 
> > If you are using TLS to port 587 then that is protecting the first
> > hop.  If both your MUA (email app) and the MSA (mail submission agent)
> > you are talking to insist on using TLS and have some means to mutually
> > authenticate (such as either a client cert or mutual_auth in postfix
> > on the MSA end), then this is subject to MITM.  Postfix does not
> > support validating the client cert (AFAIK - not a guru I said).
>  
> This is wrong.

Can you say what is wrong.  Let me paraphrase and expand a bit.

mutual_auth implies you are using SASL.

With Opportunistic TLS without SASL in postfix you have no
authentication.

With TLS but with SASL plaintext you provide a MITM a means to read
your password.

The simplest MITM is STARTTLS stripping.  If the client end doesn't
insist on TLS, then STARTTLS stripping is possible.  The client TCP
connection can be terminated at the MITM as plain text and a TLS to
the MSA can be started.  In both connections the IP address can be
spoofed if the MITM is in the routing middle (or acting as a L2
bridge).

If both ends insist on TLS but are willing to settle for SSL, then a
MITM is still possible with a TLS downgrade (but harder to do).

If both ends insist on TLS and not SSL but there is no client cert and
no way to tell what the client should be signing for or no CAfile to
check against then a MITM is possible if a rouge CA is used (which is
likely going to be a nation surveilance situation).

Postfix does not support validating the client cert.

Which of these are wrong?  OK to pick more than one.  :-)

Seriously, I did say I'm not an expert.

> > There is really no name to validate the client cert against, other
> > than the hostname provided in the EHLO.
>  
> Submission clients are usually authenticated via SASL, and while
> that does not provide "channel binding", it is good enough in
> practice, if the client properly authenticates the server.

mutual_auth implies you are using SASL and with or without TLS it
helps with MITM, but safe with TLS.

mutual_auth such as SCRAM (or GSSAPI) are reasonably good and MITM
resistant.

> > The point of the article is that unless both ends insist on TLS then
> > MITM is possible.  
>  
> The topic of the articles is TLS between email relays, not MUA to
> submission or IMAP client to IMAP srever.
>  
> MITM is possible when SMTP relays (sending MTAs) don't (and generally
> can't even if they wanted to) authenticate the nexthop MTA.

This statement was independent on MUA->MSA or MSA->MX which is a form
of MTA->MTA.

> > The focus of the paper was on the use of TLS between the MSA and the
> > MX of the destination domain (an MTA - mail transfer agent).  That is
> > usually the next hop.
>  
> No, the topic was relay-to-relay SMTP, TLS is much more prevalent
> with submission and IMAP and generally works adequately with WebPKI.

Sorry.  We are saying the same thing here but I was keeping with
MUA->MSA or MSA->MX since explaining to someone that possibly didn't
know any of these terms.  And MSA->MX is a form of MTA->MTA.

To be pedantic, the focus of the paper is on MTA->MTA where the two
MTA are in different domains.

> -- 
>   Viktor.

I defer to you as an expert on this but I would like to know what is
wrong in the "this is wrong" comment.

Curtis

gmail servers requiring postscreen_access whitelisting

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=

linefeeds added by me for readability.

gmail would just keep trying a half hour later and mail never gets
delivered.

rfc3463 isn't very helpful:

  X.3.2   System not accepting network messages

The host on which the mailbox is resident is not accepting
messages.  Examples of such conditions include an immanent
shutdown, excessive load, or system maintenance.  This is
useful for both permanent and permanent transient errors.

I have lines of the form:

  main.cf:
  postscreen_access_list =
  cidr:$config_directory/postscreen_access
  hash:$config_directory/postscreen_reject

  postscreen_access:
  #  google mail servers
  2607:f8b0:4002:c00::/60 permit
  [... other google server blocks ...]

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.

Curtis

Re: rate limiting

In message <5707263d.7000...@caseyconnor.org>
Casey Connor writes:
> 
> Thank you -- will it accept decimal seconds?
>  
> We are sending on the order of 50-200+ messages per second in this 
> stress test, so the delay between messages could be smaller than .005 
> seconds.

If you are trying to simulate a very busy mailserver, then you should
be concerned about connections to it from multiple hosts per second
most sending one or a few messages and a realistic test would have to
have a nominal TCP RTT in the range of a few to a few 10s of msec
since the speed of light is limited and geographic delays come into
play.  I've been involved in testing and some simulation of this type
but on routers and various switchy-thingies rather than mailservers.

Curtis

> On 04/07/2016 06:19 PM, Wietse Venema wrote:
> > See:
> > http://www.postfix.org/postconf.5.html#default_transport_rate_delay
> > http://www.postfix.org/postconf.5.html#default_destination_rate_delay
> >
> > The names are similar but things work differently.
> >
> > Wietse

Re: rate limiting bad-bot HANGUPs in postscreen?

In message <1460213048.1937714.573722321.23756...@webmail.messagingengine.com>
jaso...@mail-central.com writes:
 
> With postscreen in place, bad bots arr getting fended off.
>  
> Many give up and go away after a couple of tries.
>  
> Some, these days mostly 'ymlf-pc' bots, are more persistent.
>  
> Eg, this one 
>  
>   Apr  8 04:17:20 mail01 postfix/postscreen[20412]: CONNECT from 
> [37.49.226.17]:52066 to [192.0.2.17]:25
>   Apr  8 04:17:20 mail01 postfix/dnsblog[20417]: addr 37.49.226.17 listed 
> by domain zen.spamhaus.org as 127.0.0.4
>   Apr  8 04:17:21 mail01 postfix/postscreen[20412]: PREGREET 14 after 
> 0.14 from [37.49.226.17]:52066: EHLO ylmf-pc\r\n
>   Apr  8 04:17:21 mail01 postfix/postscreen[20412]: DNSBL rank 6 for 
> [37.49.226.17]:52066
>   Apr  8 04:17:21 mail01 postfix/postscreen[20412]: HANGUP after 0.85 
> from [37.49.226.17]:52066 in tests after SMTP handshake
>   Apr  8 04:17:21 mail01 postfix/postscreen[20412]: DISCONNECT 
> [37.49.226.17]:52066
>   Apr  8 04:17:22 mail01 postfix/postscreen[20412]: CONNECT from 
> [37.49.226.17]:54974 to [192.0.2.17]:25
>   Apr  8 04:17:22 mail01 postfix/dnsblog[20415]: addr 37.49.226.17 listed 
> by domain zen.spamhaus.org as 127.0.0.4
>   Apr  8 04:17:22 mail01 postfix/postscreen[20412]: PREGREET 14 after 
> 0.15 from [37.49.226.17]:54974: EHLO ylmf-pc\r\n
>   Apr  8 04:17:22 mail01 postfix/postscreen[20412]: DNSBL rank 6 for 
> [37.49.226.17]:54974
>   Apr  8 04:17:23 mail01 postfix/postscreen[20412]: HANGUP after 0.77 
> from [37.49.226.17]:54974 in tests after SMTP handshake
>   Apr  8 04:17:23 mail01 postfix/postscreen[20412]: DISCONNECT 
> [37.49.226.17]:54974
>   Apr  8 04:17:25 mail01 postfix/postscreen[20412]: CONNECT from 
> [37.49.226.17]:58871 to [192.0.2.17]:25
>   ...
>  
> conitinues on for a total of (in this case) 237 attempts in one continuous 
> string over a few minutes.
>  
> These do not appear as multiple CONCURRENT connection, which I think I can 
> limit with ' postscreen_client_connection_count_limit'.
>  
> Instead, they look like SEQUENTIAL connections.
>  
> IIUC, this is a pretty efficient disconnection by postscreen, so not a huge 
> load on the server.
>  
> But, it's still making connections.
>  
> I can rate limit these in fail2ban+firewall (e.g., 
> http://shorewall.net/ConnectionRate.html), but would prefer to keep this 
> re-action in Postfix.
>  
> Is there a postscreen_ parameter to rate limit these "bursts"? Maybe dropping 
> the connection sooner?
>  
> Jason


Jason,

An excerpt below from a shell script to generate a access file for
postscreen.  I haven't automated running it but will probably zcat a
day or two of prior maillog files plus the current day (for example,
using "zcat /var/log/maillog.0.bz2 | cat - /var/log/maillog | ...").
It gets rid of lots of PREGREET or HANGUP in under 1 sec.  The
threshhold of 5 is quite low but I don't think it will catch any legit
mail servers.  Still playing with this.

Note that the big space before reject is three tabs.

Curtis


echo "#  HANGUP after <1 more than 5 times in one day"
grep postfix/postscreen /var/log/maillog \
| grep 'HANGUP after 0\.' \
| sed -e 's,^.*HANGUP after [0-9\.]* from ,,' \
  -e 's,:[0-9]* in tests after SMTP handshake$,,' \
| sort | uniq -c | sort -n \
| egrep '^ *[6-9] |^ *[1-9][0-9][0-9]* ' \
| sed -e 's,^ *[0-9]* *\[,,' -e 's,\]$, reject,'

echo "#  PREGREET after <1 more than 5 times"
grep postfix/postscreen /var/log/maillog \
| grep 'PREGREET [0-9]* after 0\.[0-9]* ' \
| sed -e 's,^.*PREGREET [0-9]* after 0\.[0-9]* from ,,' \
  -e 's,:[0-9]*: [HE]*LO .*,,' \
| sort | uniq -c | sort -n \
| egrep '^ *[6-9] |^ *[1-9][0-9][0-9]* ' \
| sed -e 's,^ *[0-9]* *\[,,' -e 's,\]$, reject,'

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

In message <20160409210245.gs26...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> 
> On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote:
>  
> > I'm setting up mandatory TLS policy for a couple of private client
> >  servers, using
> > 
> > -   smtpd_tls_security_level = may
> > +   smtpd_tls_security_level = encrypt
> > 
> > I started wondering whether it wouldn't be a bad thing to require
> > ALL email delivered to my server, from anywhere, to use TLS.
>  
> Your server, your rules, but be prepared to refuse a lot of legitimate
> email.

A review of maillogs would tell you how much would get tossed.

I've been doing some work with automated parse of logs.  If I look at
that (including TLS mail rejected by postscreen vs in-the-clear mail
rejected by postscreen) I'll let you know.

> https://www.google.com/transparencyreport/saferemail/
> https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
> 
> https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
>  
> -- 
>   Viktor.

Thanks for the links.  I emailed one of the authors asking why so
little was said about DNSSEC and nothing at all about DANE.

Curtis

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

In message <20160409230701.5468245.39956@lazygranch.com>
li...@lazygranch.com writes:
> 
> Would a guru comment on my "interpretation" of these documents?

Not a guru but ...

> 1) It looks to me that starttls really only protects the path to the
>first server. Classic case being sending email over the non-secure
>coffee shop wifi.

If you are using TLS to port 587 then that is protecting the first
hop.  If both your MUA (email app) and the MSA (mail submission agent)
you are talking to insist on using TLS and have some means to mutually
authenticate (such as either a client cert or mutual_auth in postfix
on the MSA end), then this is subject to MITM.  Postfix does not
support validating the client cert (AFAIK - not a guru I said).

There is really no name to validate the client cert against, other
than the hostname provided in the EHLO.  For the MSA that could be
useful or the MSA could have a sender to name to validate mapping and
CAfile to use.  In principle, IMAP servers could do the same.  But I
don't think there is much demand for that.  It would mean getting
clients to put certs in the MUA.

The point of the article is that unless both ends insist on TLS then
MITM is possible.  There is a lot of discussion of STARTTLS
stripping.  There was not discussion of TLS downgrade attacks but
those are not as easy as STARTTLS stripping.

The focus of the paper was on the use of TLS between the MSA and the
MX of the destination domain (an MTA - mail transfer agent).  That is
usually the next hop.

> 2) Mail between Google/yahoo servers will enforce TLS, but other
>transit may not? My view of starttls email is this. At best, you
>only protect the endpoints.

Google, yahoo, and many others offer STARTTLS.  None require that you
use TLS or check a client cert.

> The snail mail analogy is you leave a message in an envelope for the
> mail carrier. That message makes it to the post office in the
> envelope. As the mail transits between post offices, some of those
> non-postal carriers may remove your envelope. The destination post
> office, should it find your message lacking an envelope, puts your
> message in another envelope, then delivers it.

Sort of.  More like if each post office always removed the envelope
and put your mail in a new one before sending to the next post office,
sometime a transparent envelope.

> 3) I reviewed the DMARC. All my accounts have functional spf and
>dkim. If I set DMARC to quarantine, will my email at least be
>delivered?

No.  I will be held and you (or some email address that is indicated
in the DMARC record) will be notified that mail for that domain is
held - typically in a daily summary for the domain.

> I've looked at dnssec, but it seems like I need a 2nd server to make
> it work. If not, can someone provide what they consider a good link on
> the topic?

You need to sign you domain RRs and then go to your domain registrar
and ask that a DS record be added for your domain.  In that order.

http://www.internetsociety.org/deploy360/dnssec/
http://www.internetsociety.org/deploy360/home/content-providers/dnssec/
http://dnssec-debugger.verisignlabs.com/
https://www.dnssec-tools.org/test/

The last one has a link to a tutorial.

Also regarding DANE:

http://www.internetsociety.org/deploy360/resources/dane/
http://dane.verisignlabs.com/
https://dane.sys4.de
https://dane.sys4.de/common_mistakes

> My understanding is only pgp or s/mime has end to end encryption.

Correct.  SMTP TLS is not end-to-end.

Of course to encrypt using pgp or s/mime both ends must support pgp or
s/mime which has been a problem.  People within various communities of
interest use pgp or s/mime (for example, the security community) but
use is very sparse.

Curtis

> > Original Message
> > From: Viktor Dukhovni
> > Sent: Saturday, April 9, 2016 2:03 PM
> > To: postfix-users@postfix.org
> > Reply To: postfix-users@postfix.org
> > Subject: Re: reality-check on 2016 practical advice re: requiring inbound 
> > TLS?
> >  
> > On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote:
> >  
> > > I'm setting up mandatory TLS policy for a couple of private client
> > > servers, using
> > > 
> > > - smtpd_tls_security_level = may
> > > + smtpd_tls_security_level = encrypt
> > > 
> > > I started wondering whether it wouldn't be a bad thing to require
> > > ALL email delivered to my server, from anywhere, to use TLS.
> >  
> > Your server, your rules, but be prepared to refuse a lot of legitimate
> > email.
> >  
> > https://www.google.com/transparencyreport/saferemail/
> > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
> > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
> >  
> > -- 
> > Viktor.

Re: False positives from header_checks

2016-04-06 Thread Curtis Villamizar


Since pcre evaluates in order you could add

/^Content-(Disposition|Type).*;??x-apple-part-url="[^"]+"$/x  DUNNO


before the pcre that does the rejection.

Since "." is commonly "%2E" you could also change the "\." in the RE to 
"(\.|%2E)".

That doesn't solve base64 encoding.

Disclaimer: I haven't tried this.

Curtis

On 04/06/16 22:02, Laz C. Peterson wrote:

This is great information.

It's very odd ... Apple has been responsible for the foundation of quite a few 
RFC's but in our experience has actually made it difficult for our software to 
both comply with the RFC as well as Apple's client software.

Thank you Cedric.

~ Laz Peterson
Paravis, LLC


On Apr 6, 2016, at 3:28 PM, Cedric Knight  wrote:

The documentation for header_checks includes an example to "block
attachments with bad file name extensions", and I expect many
installations have a similar rule to cut down on malware.  This reads:

  /^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
   ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|
   hlp|ht[at]|
   inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
   \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
   ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
   vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x
 REJECT Attachment name "$2" may not end with ".$4"

Unfortunately, this can now block valid email from iPhone/iOS/ithing
users.  The second ".*" can span multiple parameters.  This shows up in
logs when searching for "x-apple-part-url" as follows:

postfix/cleanup[1234]: 123412341234: reject: header Content-Type:
application/vnd.ms-publisher;??name="redacted
redacted.pub";??x-apple-part-url="abcd1234-1234-5678--123412341...@yahoo.com"

What Apple has done seems legal under RFC 2045 but may make some of
their users' email undeliverable.

Rules can be amended to limit to "token" or "quoted-string" versions of
the filename like this:

  /^Content-(Disposition|Type).*name\s*=\s*
   ("(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\ ]*)
   ((?:\.|=2E)(
   ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|
   hlp|ht[at]|
   inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
   \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
   ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
   vb[esx]?|vxd|ws[cfh])(\?=)?"?)\s*(;|$)/x
 REJECT Attachment name $2$3 may not end with ".$4"

A separate security point is that this doesn't actually block "bad"
extensions if the Content-Type name is base64 encoded and the filename
parameter in the Content-Disposition is percent-encoded.

Hope this is useful to some.

CK

Re: problem sending to outlook.com

2016-04-04 Thread Curtis Villamizar

In message <5700f376.7050...@lfweb.dk>
Lars Nielsen writes:
> 
> Hi,
> This Thursday i had problems sending mails to outlook.com addresses. I 
> found out that MS thought my mail-server was suspicious and had blocked 
> me as sender. I could however mail to them and gotten my server allowed 
> again.
>  
> But how can i ensure that i run a "professional" mail server that 
> doesn't get blocked? I have attached my "postconf -n" output here so you 
> can see if i miss something obvious!?
>  
> Thanks for you help
> Best regards
> Lars Nielsen

I have no idea but I did also get blocked.  Since I only know two
people that I send mail to with M$oft email services, and had only
recently sent only one email I could narrow it down to the content.

The content was something along the lines of "please preview this web
content on web-test.a-domain-i-use and oh btw you'll need to use https
and the cert doesn't cover web-test so click through the warnings".  I
think that was it.  The email referenced a https URL with bad cert
(valid for @, www, but not web-test).

I called.  Tech said they don't save messages or reasons for rejection
and could not give a reason but once resolved you're sort of
semi-whitelisted (low mail volume and a real human responded so they
won't be so touchy next time).  Their spam methods are proprietary.

Nothing in your config jumps out as bad (to me).  You could DKIM sign
your mail and add DKIM and SPF DNS records (maybe DMARC, though I
don't do that but might in the near future).  DKIM and SPF pass can
only help, even if just a little, and DKIM+SPF+DMARC can make sure
that forgery doesn't penalize your domain.

Maybe someone that actually knows what they are talking about will
weigh in on this thread.  :-)

Curtis


> =
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> allow_percent_hack = no
> append_dot_mydomain = no
> biff = no
> bounce_queue_lifetime = 3d
> config_directory = /etc/postfix
> default_destination_concurrency_limit = 3
> delay_warning_time = 4h
> disable_vrfy_command = yes
> home_mailbox = Maildir/
> inet_interfaces = all
> inet_protocols = all
> initial_destination_concurrency = 1
> mailbox_command =
> mailbox_size_limit = 0
> maximal_backoff_time = 8000s
> maximal_queue_lifetime = 5d
> minimal_backoff_time = 600s
> mydestination =
> myhostname = mail.lfw.dk
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 myhomeip/32 
> myserverip/32
> mynetworks_style = host
> myorigin = lfw.dk
> readme_directory = no
> recipient_delimiter = +
> relayhost =
> smtp_helo_timeout = 60s
> smtp_tls_cert_file = /etc/postfix/client.pem
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org, 
> reject_rbl_client blackholes.easynet.nl
> smtpd_delay_reject = yes
> smtpd_error_sleep_time = 20
> smtpd_hard_error_limit = 12
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, 
> warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, 
> regexp:/etc/postfix/helo.regexp, permit
> smtpd_junk_command_limit = 2
> smtpd_recipient_limit = 16
> smtpd_recipient_restrictions = check_client_access 
> hash:/etc/postfix/helo_client_exceptions check_sender_access 
> hash:/etc/postfix/sender_checks, permit_sasl_authenticated, 
> permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_recipient, 
> reject_unknown_sender_domain, reject_unknown_recipient_domain, 
> reject_unauth_destination, reject_unauth_pipelining, check_client_access 
> hash:/etc/postfix/rbl_client_exceptions, reject_rbl_client 
> cbl.abuseat.org, reject_rbl_client sbl-xbl.spamhaus.org, 
> reject_rbl_client bl.spamcop.net, reject_rhsbl_sender 
> dsn.rfc-ignorant.org, permit
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_local_domain = $myhostname
> smtpd_sasl_security_options = noanonymous
> smtpd_sender_restrictions = permit_mynetworks, warn_if_reject 
> reject_non_fqdn_sender, reject_unknown_sender_domain, 
> reject_unauth_pipelining, permit
> smtpd_soft_error_limit = 3
> smtpd_tls_CAfile = /etc/ssl/intermediate.ca.pem
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/postfix/client.pem
> smtpd_tls_key_file = /etc/ssl/mail.lfw.dk.pem
> smtpd_tls_loglevel = 3
> smtpd_tls_mandatory_protocols = !SSLv2
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_use_tls = yes
> swap_bangpath = no
> tls_random_source = /dev/urandom
> unknown_address_reject_code = 554
> unknown_client_reject_code = 554
> unknown_hostname_reject_code = 554
> unknown_local_recipient_reject_code = 450
> virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
> virtual_gid_maps = static:5000
> virtual_mailbox_base = /var/spool/mail
> virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
> virtual_mailbox_limit = 5120
> virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
> virtual_minimum_uid = 5000
>

Re: best practice for blocking fake local domain senders

2016-03-30 Thread Curtis Villamizar

In message

Re: Hardware with non-FQDN EHLO

2016-03-28 Thread Curtis Villamizar

In message <56f6c728.2090...@megan.vbhcs.org>
Noel Jones writes:
> 
> On 3/26/2016 7:18 AM, Nicols wrote:
> > Thanks Wietse and Rob,
> > 
> > The client indeed uses SASL, but it gets rejected at HELO/EHLO time.
> > I will observe these days if I can fence in a reduced CIDR range and
> > use Wietse's approach, if not, I'll set up a Postfix local to the
> > broken client, which indeed is a cleaner way than my original approach.
> > 
> > Thanks!
> > 
> > Nicols
> > 
>  
>  
> If the client uses SASL, all you need to do is put
> permit_sasl_authenticated before your reject_non_fqdn_helo_hostname.
>  
> No need for a CIDR table or any other workarounds.
>  
> smtpd_helo_restrictions =
>permit_mynetworks
>permit_sasl_authenticated
>reject_non_fqdn_helo_hostname
>... any other stuff...


On http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
permit_sasl_authenticated is not listed.

Which makes some sense since the HELO occurs before AUTH.  HELO checks
seem to be all IP and hostname related.

>   -- Noel Jones

Am I missing something?

Curtis

> > 
> >  Mensaje original 
> > De: wie...@porcupine.org
> > Fecha:25/03/2016 17:56 (GMT+00:00)
> > Para: Postfix users
> > Asunto: Re: Hardware with non-FQDN EHLO
> > 
> > Nicols:
> >> Hi,
> >>
> >> I have some hardware which I've configured to send e-mails through
> >> my Postfix server. Unfortunately, this hardware's firmware has
> >> its' EHLO command hardcoded, not being it an FQDN.
> >>
> >> In Postfix, I've configured smtpd_helo_restrictions to
> >> have?reject_non_fqdn_helo_hostname and I'm pretty happy with it
> >> so I don't want to remove it, however it makes its' attempts to
> >> get rejected. Another issue is that it's connections are made from
> >> a dynamic IP address, so whitelisting its IP address is not an
> >> option. However, it has a dynamic hostname which updates each time
> >> it changes (a DynDNS-like host).
> > 
> > Wrap the reject_non_fqdn_helo_hostname inside an access table:
> > 
> > smtpd_mumble_restrictions =
> > ...other stuff...
> > check_client_access cidr:/etc/postfix/reject_non_fqdn_helo.cidr
> > ...more stuff...
> > 
> > /etc/postfix/reject_non_fqdn_helo.cidr:
> >  # Unlike hash files, cidr files are matched in the order of rules.
> >  # IPv4
> >  1.2.3.4 dunno
> >  0.0.0.0/0  reject_non_fqdn_helo_hostname
> >  # IPv6
> >  1:2::3:4 dunno
> >  ::0/0  reject_non_fqdn_helo_hostname
> > 
> > It's a bit clumsy with the CIDR patterns, but hash-based access
> > maps don't have a wild-card pattern.
> > 
> > Wietse

Re: Thousands of login attempts

2016-03-20 Thread Curtis Villamizar

In message <0f3f9e7a-f0da-400a-b331-514a471b4...@valo.at>
Christian Kivalo writes:
> 
> >> One minor comment: I would not even offer AUTH on port 25.
> >
> >I don't. I offer opportunistic TLS on port 25 for SMTPd. All mail
> >submission have to be on port 587.
>  
> You do.
>  
> valo@uschi:~ $ telnet mail.covisp.net 25
> Trying 65.121.55.42...
> Connected to mail.covisp.net.
> Escape character is '^]'.
> 220-mail.covisp.net ESTMP -- Please wait
> 220 mail.covisp.net ESMTP Postfix 3.0.3
> ehlo test.local.host
> 250-mail.covisp.net
> 250-PIPELINING
> 250-SIZE 26214400
> 250-ETRN
> 250-STARTTLS
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.
>  
> See the two lines offering auth on port 25. You should disable auth
> on port 25.

As in "smtpd_sasl_auth_enable = no".

> -- 
> Christian

Plain and login AUTH are particularly dangerous since they send
passwords in the clear.  See if you can find another method:
http://cyrusimap.web.cmu.edu/sasl/authentication_mechanisms.html
http://wiki.dovecot.org/Authentication/Mechanisms

With AUTH PLAIN LOGIN and no TLS, anyone logging in over public WiFi
(or non-switched ethernet, where such a thing still exists) is
exposing their user ID and password to others snooping on the WiFi.
That could be really bad for people who use the same password for
everything (terrible practice but all too common).

btw- Even with TLS, unless client certs are used anyone can connect
and try brute force password guessing, which is what appears to be
happenning.  When presented with STARTTLS and no AUTH most attacks
just go away and don't keep retrying.

I suggest that if it won't break clients (if they can use TLS) use
"smtpd_tls_security_level = yes" on port 587 (which implies
"smtpd_tls_auth_only = yes").  Use "smtpd_sasl_auth_enable = no" on
port 25 even if it means clients have to change configs.  Plus set
smtp_sasl_mechanism_filter to something more reasonable if it doesn't
break clients to do so (and/or change mech_list in cyrus sasl conf).
For example "smtpd_sasl_security_options = noanonymous, noplaintext".
Client certs would be nice but a large number of client certs can be a
headache to keep track of and hard to get into user's client MUAs.

Filters limiting access to port 587 can then be applied a lot more
strickly than filters on port 25 could be.

Curtis

[OT] (was Re: Is /usr/bin/mail a link to sendmail/postfix)

2016-03-15 Thread Curtis Villamizar

In message <76865be6-8041-498d-91ae-36ef80c91...@kreme.com>
"@lbutlr" writes:
> 
> On Mar 13, 2016, at 9:06 AM, Robert Chalmers  wrote:
> >  Nice hardware, but the software is really recycled FreeBSD. say what?
>  
> This should not be news. One of the reasons I chose FreeBSD for my
> servers was because I wouldn't have to change modes between OS X and
> my servers.
>  
> --
> Marriages made in heaven are not exported.

Perhaps being pedantic again, but ... oh another squirrel ...

The kernel has its roots in Mach (back in the late 1980s) but doesn't
closely resemble Mach since long ago.

The utilities are a branch from FreeBSD a very long time ago and they
do track and merge in some changes but there are a lot of differences.
FreeBSD also uses code that originates from places other than BSD -
for example, see src/contrib and src/sys/contrib.  There are some
things you can get from FreeBSD ports collection to make your Mac and
FreeBSD systems look even more similar.

And of course Apple's window system is unique and in no way related to
the Xorg or xf86 or original MIT flavors of X-windows that FreeBSD has
used over time.

Yes there still is a lot of similarity, but recycled version ... No -
just a quick path to get closer to posix in the utilities with least
restrictive licensing.

Curtis

Re: OT yahoo

In message <612d47d4-9465-4031-9d48-e6a0c3a8a...@dukhovni.org>
Viktor Dukhovni writes:
> 
> > On Mar 13, 2016, at 5:42 PM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> > The NS RR are typically delivered in a fixed order, the order in the
> > zone file, and while perhaps neither NS RR is properly a primary in
> > the sense that MX has preference, lots of code uses the first NS
> > first, then tries the second.
>  
> Back to back queries about 1 second apart. :-)
>  
> $ dig +noall +ans +auth +nocl +nottl -t ns orleans.occnc.com @ns01.occnc.com
> orleans.occnc.com.  NS  ns03.occnc.com.
> orleans.occnc.com.  NS  ns01.occnc.com.
>  
> $ dig +noall +ans +auth +nocl +nottl -t ns orleans.occnc.com @ns01.occnc.com
> orleans.occnc.com.  NS  ns01.occnc.com.
> orleans.occnc.com.  NS  ns03.occnc.com.
>  
> -- 
> Viktor.

Hard to argue with that.  I tried @8.8.8.8 and got the same thing.

That implies that if the NS behind the MSO service is not seeing much
action the MSO might be intercepting DNS and giving cached answers.
If so, this is a free "service" to their business Internet customers
that they don't bother telling those customers about.  MSO intercept
and cache might also be why I had trouble with my DNS being somewhat
unreliable when I first turned DNSSEC on (long while ago - fine now).

I just checked and found out that "rrset-order fixed" is compiled out
of bind by default and has been for quite some time, but at least I
can compile it into my next build so I can put a fixed order on my NS
records and favor the better connected nameserver as in:

  rrset-order { class IN type NS order fixed; order random; };

Though if caching servers dole out cached RR random order, that might
not help.

Sometimes I wonder why I didn't just do it right and get colo on the
west coast and have two very well connected sites (oh yeah - cost).

Curtis

Re: OT yahoo

In message <3qnxhn426dzj...@spike.porcupine.org>
Wietse Venema writes:
> 
> Curtis Villamizar:
> > Are you saying they only looked at the primary NS record?  Maybe I
> > misread a prior post but I thought you meant primary MX record.  The
> > former, if true, would be even more broken.
>  
> There are no primary/secondary NS records; what matters are the NS
> records for his domain the parent zone name server hands out.
>  
>   Wietse

Wietse,

You are correct if you want to be pedantic, but ...

The NS RR are typically delivered in a fixed order, the order in the
zone file, and while perhaps neither NS RR is properly a primary in
the sense that MX has preference, lots of code uses the first NS
first, then tries the second.

For example, the bind documentation (Section 6.3 "Zone File") says:

The set of resource information associated with a particular name
is composed of separate RRs. The order of RRs in a set is not
significant and need not be preserved by name servers, resolvers,
or other parts of the DNS. However, sorting of multiple RRs is
permitted for optimization purposes, for example, to specify that
a particular nearby server be tried first.

So I think that might count as at least weak evidence of current
practice, but that has been my experience.  My primary NS is better
connected (at a colocation site, near an IX, with GbE the slowest hop)
and is listed first and the secondary doesn't get much use from
outside (which is good since its connected via a MSO "business
Internet service" which is usable, but nothing like the colo).

Curtis

[OT] OS heritage (was: Re: source code for MacOSX tools)

OT - therefore my first and only post on this.

In message 
Jim Reid writes:
>  
> > On 13 Mar 2016, at 15:06, Robert Chalmers  wrote:
> > 
> > Nice hardware, but the software is really recycled FreeBSD. say what?
>  
> The MacOSX kernel is based on Mach, not BSD, though that Mach kernel
> presents a largely BSD-flavour/POSIX API to user mode applications. It
> might be fairer to say FreeBSD is recycled MacOSX given the
> engineering resources Apple has contributed to FreeBSD. :-)
>  
> Most MacOSX command line tools come from FreeBSD or GNU, apart from
> the obvious independent open source projects like postfix, openssl,
> BIND, ntpd and so on.

https://en.wikipedia.org/wiki/Mac_OS#OS_X
https://en.wikipedia.org/wiki/Darwin_%28operating_system%29
https://en.wikipedia.org/wiki/XNU
https://en.wikipedia.org/wiki/Hybrid_kernel

Briefly:

Mach is an OS based on a minimalist microkernel.  FS, VM, all outside
the microkernel.

In a microkernel all OS services are outside the kernel.  This is best
for security and to some extent reliability.  There are performance
penalties.

OS/X uses the Darwin OS based on XNU which is a hybrid kernel.

In a hybrid kernel that evolved from a more minimalist microkernel,
some OS features that are performance critical are moved into the
kernel.

A monolithic kernel has lots of stuff in the kernel.  A classic
monolithic kernel has lots of stuff running unprotected and is
therefore reliant on it all being very reliable in order to be secure.

BSD was originally a monolithic kernel.  Various BSD flavors have
moved in the hybrid kernel direction with protected kernel spaces and
loadable modules and loadable drivers.  BSD is considered monolithic
with modules.

Linux is monolithic with modules.

So OS/X is neither Mach or BSD but has parts of both.  XNU isn't
really Mach anymore just as the utility set isn't really FreeBSD.

If you have better info, then go ahead and update the wikipedia pages.

> > So all I need - if I'm bothered, is the source of FreeBSD's mail,
> > and rebuild it myself so it links to postfix's sendmail where I want
> > it properly.
>  
> Source code for the pretty much the entire OS excluding Apple's
> GUI-based tools and the window manager can be downloaded from
> http://www.opensource.apple.com. You may be better off compiling from
> that instead of FreeBSD source so you know you're starting from the
> same baseline code Apple is using. Maybe Apple have changed
> /usr/bin/mail somehow. They probably haven't, but you'll never know
> for sure unless you check.
>  
> Some command line tools have been "enhanced" by Apple. For instance
> openssh has been hacked to work with Keychain and although the source
> code for those changes is freely available, it's not yet found its way
> into the official openssh distribution.

btw- FreeBSD base contains sendmail.  Postfix 2.11, 3.1 and 3.2 are in
the FreeBSD ports collection as mail/postfix211, mail/postfix, and
mail/postfix-current (last I checked postfix/postfix-2.11.7.tar.gz
with patches, postfix-3.1.0.tar.gz and postfix-3.2-20160224.tar.gz).

It does seem that using src/usr.bin/mail might work but maybe with a
little work.  Most of the code in src (the base source distribution)
is not keen on being pulled out and compiled in any old environment
which is why "tools" is built first and everything compiled (or cross
compiled) using that tool set and a known set of include files and
library files.  So I don't give it good odds on being a drop in and
compile solution.  Mail is very simple and fairly self contained and
probably hasn't changed significantly in decades so it might drop in.
I'd exhaust other options first.

Curtis

Re: OT yahoo

In message 
"@lbutlr" writes:
 
> On Fri Mar 11 2016 12:21:07 Noel Jones said:
> >=20
> > This problem (postscreen delays legit mail server) is nicely solved
> > by using a dns whitelist such as dnswl.org to bypass postscreen
> > tests for known mail servers... not necessarily "known good"
> > servers, just known to not be a bot.  Then your smtpd and content
> > filtering can decide if you want the mail.
>  
> $ postconf -nf postscreen_dnsbl_sites
> postscreen_dnsbl_sites =3D dul.dnsbl.sorbs.net*1
> zen.spamhaus.org=3D127.0.0.[10..11]*4 =
> zen.spamhaus.org=3D127.0.0.[4..7]*6
> zen.spamhaus.org=3D127.0.0.3*6 zen.spamhaus.org=3D127.0.0.2*6
> spam.dnsbl.sorbs.net*2 multi.surbl.org*2 dnsbl-1.uceprotect.net
> dnsbl-2.uceprotect.net list.dnswl.org=3D127.0.[0..255].0*-3
> list.dnswl.org=3D127.0.[0..255].1*-4 =
> list.dnswl.org=3D127.0.[0..255].[2..255]*-6
> dwl.spamhaus.org=3D127.0.2.[2;3]*-3 =
> swl.spamhaus.org=3D127.0.2.[12;13]*-3
>  
> I think yahoo maybe was only looking at the primary DNS which had gone =
> offline because of the fixed IP issue, and no one else seemed to notice =
> since the other DNS servers were working fine.


Are you saying they only looked at the primary NS record?  Maybe I
misread a prior post but I thought you meant primary MX record.  The
former, if true, would be even more broken.

Curtis

Re: OT: TLS and SNI (was Re: Postfix 3.1 and TLS Cert Files)

2016-03-09 Thread Curtis Villamizar

In message <56e0ccb4.6010...@spectralmud.org>
Richard James Salts writes:
> 
> On 10/03/16 09:32, Curtis Villamizar wrote:
> > In message <56dfcd11.5010...@spectralmud.org>
> > Richard James Salts writes:
> >
> >> On 09/03/16 06:44, Viktor Dukhovni wrote:
> >>>> On Mar 8, 2016, at 2:31 PM, Curtis Villamizar <cur...@orleans.occnc.com> 
> >>>> wrote:
> >>>>
> >>>> With HTTP the server cert is provided after HTTP identifies which
> >>>> virtual host it thinks its talking to.  The IP address along gives no
> >>>> clue.  That connection is then used only for that virtual host.  This
> >>>> is why you can have a TLS cert per vhost (aka DNS domain).
> >>> To be more precise, with HTTPS, the desired TLS server name is
> >>> conveyed via the TLS SNI extension and the HTTP server presents
> >>> the corresponding certificate.  By contrast, the Postfix SMTP
> >>> server neither supports nor needs SNI.
> >> But some MUAs (i.e. user's mail clients) do support SNI and will try to
> >> match against the name that was entered into the configuration. This
> >> might be important if you have many white label resellers who want
> >> clients to be able to enter mail.<reseller's domain> into their
> >> customers mail clients.
> > Which MUAs and exactly how do they use SNI?
>  
> I'm not sure on all of them, but thunderbird does at the very least. It 
> uses the name in the account settings. I tested this by adding an entry 
> to /etc/hosts with garbage in it and changing the settings to point to 
> that and I got a certificate name mismatch when trying to send via 
> submission port(587) on my server and packet capture shows this 
> reflected in the client hello after starttls. At the moment a few 
> clients can guess what server names should be based on an email address, 
> but they're usually using an adhoc heuristic. For instance thunderbird 
> has its own list that administrators can upload configurations for their 
> domain to, otherwise it will fall back to trying the domain itself on 
> well known smtp ports, then mail.domain, then smtp.domain. There is an 
> rfc for publishing records indicating the server the MUA should contact, 
> e.g. _submission._tcp SRV 0 1 mail.example.org. but in this case the 
> email client is recommended to use the email domain itself to 
> authenticate. This changes a bit with dnssec and there is a draft which 
> expires in July that gives some recommendations of this 
> (https://tools.ietf.org/html/draft-melnikov-uta-dnssec-email-tls-certs-00#section-5.1
>  
> specifically), but it's still a mess.

Thanks.  5.1 bullet 2 is what I described as the workaround - one cert
with lots of domain names in subjectAltName.  OK for self signed certs
or a local CA.  Bullet 4 is SNI (best choice IMHO if it was a choice).

> > Most MUAs would be talking to a IMAP to receive mail and might also
> > use IMAP to send mail, therefore port 993, not 25 or 587.
> >
> > btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but
> > I'm not sure about that.
> >
> > If any do use port 587 do the MUAs use SNI to indicate which sender
> > domain?  Your statement above seems to indicate a check made by the
> > client, but against what?  The CN or subjectAltName(s) in the cert?
> SNI requires that the client use an extension to the TLS handshake in 
> their client hello to say "I would like to talk to this FQDN" before it 
> establishes a secure connection. It's then up to the server to choose 
> what do do. In postfix which only supports SNI for the smtp client this 
> will mean it's only based on the ip/port combination and what's in 
> main.cf and/or overridden in master.cf with a separate listener.

So you are confirming that for an MUA that uses the SNI extension,
postfix smptd can't take advantage of this to send a specific cert and
we have to fall back to lots of domains in subjectAltName or separate
ports for each domain.  OK got it.  Thanks.

> > AFAIK postfix has no support for SNI other than the limited support
> > for DANE, but a cert with MX FQDN in CN and all domains pointing at
> > that MX in subjectAltName also solves this with or without SNI.  There
> > does not seem to be any postfix config option to specify per SNI cert.
> > Did I miss it?  Otherwise, the only solution is putting everything in
> > subjectAltName (which means SNI does nothing for port 587 use).
> >
> >>> Firstly, SMTP TLS connections are typically unauthenticated, and
> >>> it does not matter which certificate the server presents, so no
> >>> need

OT: TLS and SNI (was Re: Postfix 3.1 and TLS Cert Files)

2016-03-09 Thread Curtis Villamizar

In message <56dfcd11.5010...@spectralmud.org>
Richard James Salts writes:

> On 09/03/16 06:44, Viktor Dukhovni wrote:
> >> On Mar 8, 2016, at 2:31 PM, Curtis Villamizar <cur...@orleans.occnc.com> 
> >> wrote:
> >>
> >> With HTTP the server cert is provided after HTTP identifies which
> >> virtual host it thinks its talking to.  The IP address along gives no
> >> clue.  That connection is then used only for that virtual host.  This
> >> is why you can have a TLS cert per vhost (aka DNS domain).
> > To be more precise, with HTTPS, the desired TLS server name is
> > conveyed via the TLS SNI extension and the HTTP server presents
> > the corresponding certificate.  By contrast, the Postfix SMTP
> > server neither supports nor needs SNI.
> But some MUAs (i.e. user's mail clients) do support SNI and will try to 
> match against the name that was entered into the configuration. This 
> might be important if you have many white label resellers who want 
> clients to be able to enter mail.<reseller's domain> into their 
> customers mail clients.

Which MUAs and exactly how do they use SNI?

Most MUAs would be talking to a IMAP to receive mail and might also
use IMAP to send mail, therefore port 993, not 25 or 587.

btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but
I'm not sure about that.

If any do use port 587 do the MUAs use SNI to indicate which sender
domain?  Your statement above seems to indicate a check made by the
client, but against what?  The CN or subjectAltName(s) in the cert?

AFAIK postfix has no support for SNI other than the limited support
for DANE, but a cert with MX FQDN in CN and all domains pointing at
that MX in subjectAltName also solves this with or without SNI.  There
does not seem to be any postfix config option to specify per SNI cert.
Did I miss it?  Otherwise, the only solution is putting everything in
subjectAltName (which means SNI does nothing for port 587 use).

> > Firstly, SMTP TLS connections are typically unauthenticated, and
> > it does not matter which certificate the server presents, so no
> > need to have one that matches any particular name.
> >
> > In the rare cases that authentication does take place through
> > the magic of MX record redirection a single MX host can support
> > multiple domains provided that it is the MX hostname and not the
> > target domain that the client authenticates.  This is the case
> > with DANE.
> >
> > https://tools.ietf.org/html/rfc7672#section-1.3

The original question I think had to do with port 587 TLS (though I
admit some initial confusion on Tom's objectives) which would normally
use smtpd_tls_req_ccert=yes and use smtpd_tls_security_level=encrypt
on the server side.  On the client side, connection to port 587 would
be better off with smtp_tls_security_level=encrypt rather than
dane-only and this would have nothing to do with MX records.  In this
context (no MX lookup at all) I'm not sure what role SNI would play
(in a world where postfix supported everything even remotely useful).

If the original question was related to outside users connecting via
port 25 to send mail to a mailing list and getting a "per vhost cert"
(Tom's words, approximately), then SNI could do something useful if
postfix had a means to set smtpd_tls_key_file and smtpd_tls_cert_file
per SNI.  This could be supported if something existed that was like
smtp_tls_policy_maps (the key feature being able to set any main.cf
policy statememt in the rhs) but on the smptd_ side and using SNI as
the key.  (Maybe such a config option exists in a world where postfix
supports everything even remotely useful, but I couldn't find it in
local or online docs).  This would work with or without TLSA records.

If one MX supports a large number of domains, the subjectAltName could
get rather large if there is no means to select key and cert based on
SNI and if the client side wanted to verify per domain (as DANE does)
rather than looking for the MX name in the cert.  Just an observation.
Did I go wrong here somewhere?

Curtis

Re: Postfix 3.1 and TLS Cert Files

2016-03-09 Thread Curtis Villamizar

In message

Re: Postfix 3.1 and TLS Cert Files

2016-03-08 Thread Curtis Villamizar

Tom,

I've been following this thread and also not clear on your
objectives.  See inline.

In message

Re: Postfix Mailman integration

2016-02-29 Thread Curtis Villamizar

In message <20160229171935.gh12...@mournblade.imrryr.org>
Viktor Dukhovni writes:

> On Mon, Feb 29, 2016 at 11:38:26AM -0500, Ruben Safir wrote:
>  
> > > To have mailman reinject on an extra port on localhost is how it
> > > should be done.
> > 
> > Thanks!
>  
> Note that much of the delay was likely due to mailman hitting tarpit
> controls after 10 invalid recipients in a single submission.
>  
> http://www.postfix.org/postconf.5.html#smtpd_error_sleep_time
>  
> Although slow DNS lookups could well have contributed.
>  
> For submission of list messages to a large number of recipients,
> I would generally use sendmail(1) rather than SMTP.  Don't know
> whether mailman supports that.
>  
> -- 
>   Viktor.

IETF uses mailman and supports a large number of working group mailing
lists with up to thousands of subscribers per list, with subscribers
from all over the world, so clearly mailman is usable in for a large
number of large mailing lists.  I think most IETF mailing lists
switched from majordomo some 15 years ago when mailman was fairly new.

Maybe this isn't a useful response.  Just pointing to an existance
proof that the mailman architecture is not fundamentally broken.

btw- I can't tell from headers whether they use sendmail.org sendmail
or postfix or something else, but amavisd-new is mentioned in the
headers.  amsl.com runs most of the mailing lists.

Curtis

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

In message <211281bd-f686-4a8a-9e37-7d4368568...@kreme.com>
LuKreme writes:

> On Jan 30, 2016, at 22:42, Curtis Villamizar <cur...@orleans.occnc.com> wrote:
> > It would be:
> > 
> >  cd /usr/local/etc
> >  mv postfix postfix.old
> >  ln -s ../../../etc/postfix postfix
>  
> No, it most certainly would not. Your configuration files ARE in
> local, if you want to pretend they are in /etc, then create a link in
> etc.  I've done this for years. Works just fine.
>  
> > And yes I did try that.
>  
> And what you tried will not work.

Not to further beat a dead horse but ...

We're not talking about configuring one host, though I try things out
on a single host by hand edits first.

I generate configs and have have tools to rebuild any host from
scratch in a single command line, compare all configs on a running
host to updated config templates, etc.  So I have to change some path
names in config templates and roll out changes.  No big deal but a
"ln -s" command isn't going to do the trick.

As I said to Viktor, I mistakenly thought, based on reading (maybe
misreading) numerous web pages of documentation with no mention of a
limitation, that the -c argument was supposed to work like -c or -cf
in any other package.  Now I know that it doesn't.

Peace,

Curtis

Re: local delivery, alias expansion, and subdomain matches

In message <2a0d3251-10a1-4903-8689-2d190e144...@dukhovni.org>
Viktor Dukhovni writes:

> > On Jan 30, 2016, at 8:03 PM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> > I'm asking a little advice.
> > 
> > On most of my hosts mail is generated for root and then canonicaled to
> > root@fqdn and is relayed to the MSA on another host.  This is by
> > design.
> > 
> >  relayhost = msa-fqdn
> > 
> > There is an alias on the originating host for root but it doesn't seem
> > to expand there.  If that could be fixed, then the rest doesn't matter.
>  
> Aliasing root on null-clients is explained in:
>  
>http://www.postfix.org/MULTI_INSTANCE_README.html#split

OK.  This

> Perhaps STANDARD_CONFIGURATION_README.html should also cover this.
>  
>http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client

Null client seems good for web servers and other servers not involved
in forwarding or delivering email.  Thanks.  I'll need more config
since the MSA will want a client cert and sasl-auth.

btw- BSD jails don't have a loopback, only numbered interfaces.
Would than mean using "inet_interfaces = " (empty).

> That example is at present more minimal, but global recipient aliasing
> via virtual(5) is covered in ADDRESS_REWRITING_README.html:
>  
>http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving
>http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual

I saw this but I'm not sure I got the config quite right.

I think what I need is:

  #  destination domains and virtual alias domains
  mydestination = hash:$config_directory/my-domains
  remote_destination = pcre:$config_directory/pcre-domains
  virtual_alias_domains = $mydestination $remote_destination
  #  local users (comment out if empty) and virtual alias users
  #local_alias_maps = hash:$config_directory/local-aliases
  remote_alias_maps = hash:$config_directory/remote-aliases
  alias_database = $local_alias_maps $remote_alias_maps
  alias_maps = $local_alias_maps
  virtual_alias_maps = $remote_alias_maps
  local_recipient_maps = hash:$config_directory/local-users

  local-aliases:
(remove root, spam, ..., anything mapping to root, spam, ...)
(strictly local aliases - none in my case)
  remote-aliases:
root: ad...@some.where.tld
spam: spam.catc...@some.where.tld
...
(anything mapping to root, spam, ...)

Note: local-users matches the recipients known to cyrus imapd.

(and of course config_directory = /usr/local/etc/postfix).

Since the goal is to catch root@*.domain.tld by using the bare word
root on the lhs in remote-aliases and a pcre to put *.domain.tld in
virtual_alias_domains this should work.  Me thinks.

I think this will work and will try it when I get a chance (on a test
domain first).  Unless someone tells me it won't work.

> -- 
>   Viktor.

Curtis

btw- I think this would also be doable in sendmail address rewriting
rules (just about any rewrite is doable) but like writing assembly
language code, I'd rather not be pursuing such a solution.

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

In message <5a7fbd95-2256-4177-a30d-32e36ea73...@dukhovni.org>
Viktor Dukhovni writes:

> > On Feb 1, 2016, at 3:54 AM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> > As I said to Viktor, I mistakenly thought, based on reading (maybe
> > misreading) numerous web pages of documentation with no mention of a
> > limitation, that the -c argument was supposed to work like -c or -cf
> > in any other package.  Now I know that it doesn't.
>  
> The "-c" argument absolutely works, but makes no promise that having
> problematic settings in the default configuration directory will not
> log any warnings.

It doesn't give any warnings in the manual pages or in
http://www.postfix.org/postconf.5.html#config_directory
Maybe it should.

The entire content is:

  config_directory (default: see "postconf -d" output)

The default location of the Postfix main.cf and master.cf
configuration files. This can be overruled via the following
mechanisms:

The MAIL_CONFIG environment variable (daemon processes and
commands).

The "-c" command-line option (commands only).

With Postfix command that run with set-gid privileges, a
config_directory override requires either root privileges, or it
requires that the directory is listed with the
alternate_config_directories parameter in the default main.cf
file.

As you can see - no warning.

> The default configuration directory is used to determine whether the
> target of the "-c" option is a secondary instance in a single command
> in the start-up shell script.  The lookup of just that single parameter
> happens to trigger a warning on your partly configured system.

Perhaps put something like this in
http://www.postfix.org/postconf.5.html#config_directory
except use the phrase "compiled in default configuration directory".
And the put in each manual page -c description "See limitation
described in config_directory main.cf option".

> For some reason you seem to have gotten rather worked up about a nit
> that really does not warrant the bother.  Most people find it easier
> to either compile with the preferred default, or use the default that's
> compiled-in, and not have to use explicit "-c" options all the time.

I started by asking a question which was phrased (sic) "is this a
bug".  Sorry.  My errant assumption was not clear to me at that time.

> The warning can be ignored, however it is expected that the default
> configuration is at least minimally maintained.  Postfix supports
> multiple instances, so secondary instances are part of a larger
> configuration via the primary instance.

This is not clear in any of the documentation and is only hinted at in
the build instructions you forwarded (as URL).  Maybe that could be
fixed.

> Regaining some perspective would be appropriate at this point.
> Good luck.
>  
> -- 
>   Viktor.

I'm moving my files to /usr/local/etc/postfix.  This means editing a
few configuation file templates.

  % find local-config public -type f \
  | egrep -v 'public/fbsd/build/trace/' \
  | xargs grep -l etc/postfix
  local-config/system-files/etc/mda+/rc.conf
  local-config/system-files/etc/mta+/rc.conf
  local-config/system-files/pkg/pkg-files/cyrus-imapd/init.imapd.sh
  local-config/system-files/pkg/pkg-files/postfix-mda/main.cf
  local-config/system-files/pkg/pkg-files/postfix-mta/main.cf
  local-config/system-files/pkg/pkg-files/postfix-http/main.cf
  local-config/system-files/pkg/pkg-files/dkim-sign/keytable
  local-config/system-files/pkg/pkg-files/dkim-sign/dkim-sign.conf
  local-config/system-files/pkg/pkg-files/postfix-any/init.postfix.sh
  local-config/system-files/pkg/pkg-files/postfix-host/main.cf
  local-config/system-files/pkg/def/postfix-host
  local-config/system-files/pkg/def/postfix-any
  local-config/system-files/pkg/def/dkim-verify
  local-config/system-files/pkg/def/postfix-http
  local-config/system-files/pkg/def/dkim-sign
  local-config/system-files/pkg/def/postfix-mta
  local-config/system-files/pkg/def/postfix-mda
  local-config/system-files/pkg/host-files/mda+/sasl2/add/init.sasl2.sh
  local-config/system-files/default/harbor.rc.conf
  local-config/system-files/default/postfix.rc.conf
  public/fbsd/install-certs/GNUmakefile

This is because I generate configs.  I also changed /etc/postfix/dkim
to /etc/dkim - a more appropriate place and saves permission warnings.

No big deal.  Already completed this morning.

Thanks for the help.

Curtis

Re: local delivery, alias expansion, and subdomain matches

In message <20160201080958.9bede332...@english-breakfast.cloud9.net>
Curtis Villamizar writes:
> > Aliasing root on null-clients is explained in:
> >  
> >http://www.postfix.org/MULTI_INSTANCE_README.html#split
>  
> OK.  This

Oops.

Was going to write "This doesn't help".

The reason is that mail to something that aliases to root arrives at
an MDA and then is aliased to root and reforwarded to the admin
account.  Since it comes (by way of an MTA) from outside, it arrives
at the smptd instance.

The discussion of what I think would work was after the suggestion to
go reread
>http://www.postfix.org/ADDRESS_REWRITING_README.html#receiving
>http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual

The MDA is the tough case.

Curtis

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

2016-01-31 Thread Curtis Villamizar

In message <49c94ad9-3c94-4c48-9726-0e81e1109...@dukhovni.org>
Viktor Dukhovni writes:
 
> > On Jan 31, 2016, at 1:01 AM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> > I use tcsh so:
> > 
> >  # sh -c 'postconf -c $(postconf -dh config_directory ) \
> > -h multi_instance_directories'
> >  postconf: warning: inet_protocols: disabling IPv4 name/address
> >  support: Protocol not supported
> >  # postconf -c /etc/postfix -h multi_instance_directories
> > 
> > This didn't complain about smtputf8_enable but did complain about
> > inet_protocols.  The second form didn't complain at all.
> > 
> >> This is used to determine whether you're starting a secondary instance, 
> >> and uses
> >> the default configuration directory, which really needs to be properly 
> >> configured,
> >> even with "postfix -c ...".
> > 
> > So I would have to edit both?
>  
> No, either use the compile-time default configuration directory as the actual
> configuration directory of the primary Postfix instance, or compile Postfix
> with /etc/postfix as the default configuration directory.  Your:
>  
>   postfix -c /etc/postfix
>  
> hack to avoid using the compile-time configuration directory is not supported.

I'm sorry I used a feature that was described in the documentation and
seemed to mostly work fine.  :-)

I'll convert to /usr/local/etc/postfix.

> I've already posted the relevant link, here it is again.
>  
>http://www.postfix.org/INSTALL.html#build_over

Perhaps someone should clarify the limitation of "-c config_dir" in
the man pages.

http://www.postfix.org/postalias.1.html
http://www.postfix.org/postcat.1.html
http://www.postfix.org/postconf.1.html
http://www.postfix.org/postfix.1.html
http://www.postfix.org/postkick.1.html
http://www.postfix.org/postlock.1.html
http://www.postfix.org/postlog.1.html
http://www.postfix.org/postmap.1.html
http://www.postfix.org/postqueue.1.html
http://www.postfix.org/postsuper.1.html

Also there is no mention of a restriction in:

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

> Either accept the compile-time directory of /usr/local/etc/postfix (on the
> NetBSD system I use it is /usr/pkg/etc/postfix, which works just fine), or
> build Postfix to your taste if using /etc/postfix is very important to you.
>  
> -- 
>   Viktor.

OK.  I'm fine with moving it.  The configuration documentation led me
to believe that it was supposed to work but apparently that is not the
case and the limitation was only in the build documentation.  Sorry to
be so dense.

Curtis

local delivery, alias expansion, and subdomain matches

I'm asking a little advice.

On most of my hosts mail is generated for root and then canonicaled to
root@fqdn and is relayed to the MSA on another host.  This is by
design.

  relayhost = msa-fqdn

There is an alias on the originating host for root but it doesn't seem
to expand there.  If that could be fixed, then the rest doesn't matter.

Instead it is relayed to $relayhost (the MSA).

At the MSA it is relayed to the MDA covering mydomain.tld .

  relay_domains = hash:/etc/postfix/transport

  transport:
mydomain.tld mda1.some-subdomain.mydomain.tld
...
otherdomain.tld  mdaN.some-subdomain.mydomain.tld

At the MDA I use cyrus imapd, therefore have:

  local_transport = lmtp:unix:/var/imap/socket/lmtp

There are two problems here.  One is that the alias isn't expanded on
local delivery otherwise it would go to
ad...@somewhere-else.mydomain.tld .  Since local_transport is set,
local(8) is never run.

The second problem is that I have to list every hostname in
the mydestination hash.

  mydestination = hash:/etc/postfix/my-domains

parent_domain_matches_subdomains doesn't apply to mydestination
otherwise I could have a short file that very rarely changed:

  my-domains:
mydomain.tld exists
subdomain1.mydomain.tld  exists
subdomain2.mydomain.tld  exists
.subdomain1.mydomain.tld exists
.subdomain2.mydomain.tld exists

Instead I need a long file that changes now and then:

  my-domains:
mydomain.tld   exists
subdomain1.mydomain.tldexists
subdomain2.mydomain.tldexists
host1.subdomain1.mydomain.tld  exists
host2.subdomain1.mydomain.tld  exists
...
host1.subdomain2.mydomain.tld  exists
host2.subdomain2.mydomain.tld  exists
...

This also means the this mail is delivered to root at the MDA and not
to the alias ad...@somewhere-else.mydomain.tld .

It seems that a partial solution at the MDA for sending to
ad...@somewhere-else.mydomain.tld is to use virtual_alias_maps .  This
is a partial solution because it would still require an entry for
every hostname.  Perhaps a complete solution at the MDA is to use
virtual_alias_maps with pcre: or regexp:

  virtual_alias_maps = pcre:/etc/postfix/pcre-alias

  pcre-alias:
/(root|postmaster|...)@(.*\.)?mydomain\.tld/
ad...@somewhere-else.mydomain.tld
/(manager|info|marketing|sales|support)@(.*\.)?mydomain\.tld/
s...@somewhere-else.mydomain.tld

This is nice because there are less MDA than hosts.  Domains with just
web content and email don't have mail to root@ per se but the outside
world might send to hostmaster or webmaster or the other things that
get aliased to root but there is only one such address per domain.

Perhaps better is to solve this on the sending end.

  virtual_alias_maps = hash:virtual-alias

  virtual-alias:
root  ad...@somewhere-else.mydomain.tld
postmasterroot
...

For internally sourced mail solving this at the source might be
cleaner (if virtual_alias_maps is run before relayhost relaying) but
means changing more hosts.  For externally sourced mail this has to be
solved at the MDA but need not use pcre.

It seems to me that there should be a way to enable
parent_domain_matches_subdomains on virtual_alias_maps .
That would save having to resort to using pcre in this case.

Any faults in my thinking on this?

Curtis

moving configs from /usr/local/etc/postfix to /etc/postfix

This is more of an annoyance than a serious bug since there is a
simple workaround.  But it seems to me that it is a bug.

Though postfix is compiled with /usr/local prefix (and I prefer the
executables in /usr/local) I have configs in /etc/postfix so I start
postfix with "-c /etc/postfix".  I get:

  /usr/local/sbin/postconf: warning: inet_protocols: disabling IPv4
  name/address support: Protocol not supported

even though /etc/postfix/main.cf has inet_protocols = ipv6

This is on an IPv6-only MDA (all my client hosts that need to reach
the MDA including cell phones can do IPv6).  btw- Any non-ancient
android has no trouble with my ECDSA certs.  Haven't checked iphone.

I can get rid this by editing /usr/local/etc/postfix/main.cf .

It seems that this variable (inet_protocols) and strict_smtputf8 are
evaluated and acted on before the -c arg is considered and the actual
config file is read.  The /usr/local/etc/postfix/main.cf file should
not be read at all if there is "-c /etc/postfix" on the command line.

The workaround is to edit a small number of variables in
/usr/local/etc/postfix/main.cf .

btw- Documentation is a bit off.  It says "smtputf8_enable (default:
yes)" but "postconf -d | grep smtputf8_enable" yeilds "smtputf8_enable
= ${{$compatibility_level} < {1} ? {no} : {yes}}" and "postconf -d |
grep compatibility_level\ =" yields "compatibility_level = 0".

Curtis

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

In message <ba08647a-9b1d-42e5-b57c-efd945ec0...@kreme.com>
"@lbutlr" writes:
> 
> On 30 Jan 2016, at 20:27, Curtis Villamizar <cur...@orleans.occnc.com> wrote:
> > Though postfix is compiled with /usr/local prefix (and I prefer the
> > executables in /usr/local) I have configs in /etc/postfix so I start
> > postfix with "-c /etc/postfix".
>  
> ln -s /usr/local/etc/postfix /etc/

It would be:

  cd /usr/local/etc
  mv postfix postfix.old
  ln -s ../../../etc/postfix postfix

And yes I did try that.  postfix gets upset that config_directory is
not a directory and refuses to do anything.  If this did work I would
have to copy over bounce.cf.default and main.cf.default and maybe
should copy over LICENSE and TLS_LICENSE.

It also didn't like a symlink to the main.cf file.

The workaround is to change 2 lines in /usr/local/etc/postfix/main.cf
and then put the real configuration in /etc/postfix/main.cf (which
still needs the same 2 lines).

Its a minor bug but it might be very easy to fix.

Curtis

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

In message <ff1da2c8-ba5d-4c64-9a1a-1e91bfc64...@dukhovni.org>
Viktor Dukhovni writes:
 
> > On Jan 31, 2016, at 12:24 AM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> >>> /usr/local/sbin/postconf: warning: inet_protocols: disabling IPv4
> >>> name/address support: Protocol not supported
> >>> 
> >>> even though /etc/postfix/main.cf has inet_protocols = ipv6
> >> 
> >> What happens when you run:
> >> 
> >># postconf -dh config_directory
> >> 
> >> Does it report those warnings?  Does the outcome depend on the setting
> >> of inet_protocols in the default configuration file?
>  
> > No complaints for postconf.  I don't think postconf will try to open
> > sockets and realize that there is no ipv4 address.
>  
> And yet, "postconf" is exactly the program that reported the error message.
> It says so quite plainly on the first line I quote.
>  
> Did you in fact revert the default configuration to the version for which
> you observe the above issue?
>  
> If not "postconf -dh config_directory", then how about:
>  
> # postconf -c $(postconf -dh config_directory) -h 
> multi_instance_directories

I use tcsh so:

  # sh -c 'postconf -c $(postconf -dh config_directory ) \
 -h multi_instance_directories'
  postconf: warning: inet_protocols: disabling IPv4 name/address
  support: Protocol not supported
  # postconf -c /etc/postfix -h multi_instance_directories

This didn't complain about smtputf8_enable but did complain about
inet_protocols.  The second form didn't complain at all.

> This is used to determine whether you're starting a secondary instance, and 
> uses
> the default configuration directory, which really needs to be properly 
> configured,
> even with "postfix -c ...".

So I would have to edit both?

If I do this:

  pushd /usr/local/etc/postfix/
  mv main.cf main.cf.orig
  ln -s ../../../../etc/postfix/main.cf main.cf

Then try a few commands:

  # postconf -dh config_directory
  # sh -c 'postconf -c $(postconf -dh config_directory ) \
 -h multi_instance_directories'
  postconf: warning: /usr/local/etc/postfix/main.cf, line 24:
  overriding earlier entry: config_directory=/usr/local/etc/postfix
  # postmap hash:/etc/postfix/my-domains
  postmap: warning: /usr/local/etc/postfix/main.cf, line 24:
  overriding earlier entry: config_directory=/usr/local/etc/postfix

So different complaint with the symlink.

> -- 
>   Viktor.

Curtis

Re: moving configs from /usr/local/etc/postfix to /etc/postfix

In message <16f8c2b2-59cd-41b2-a452-5ec4b4442...@dukhovni.org>
Viktor Dukhovni writes:
 
> > On Jan 30, 2016, at 10:27 PM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> > This is more of an annoyance than a serious bug since there is a
> > simple workaround.  But it seems to me that it is a bug.
> > 
> > Though postfix is compiled with /usr/local prefix (and I prefer the
> > executables in /usr/local) I have configs in /etc/postfix so I start
> > postfix with "-c /etc/postfix".  I get:
> > 
> >  /usr/local/sbin/postconf: warning: inet_protocols: disabling IPv4
> >  name/address support: Protocol not supported
> > 
> > even though /etc/postfix/main.cf has inet_protocols = ipv6
>  
> What happens when you run:
>  
>   # postconf -dh config_directory
>  
> Does it report those warnings?  Does the outcome depend on the setting
> of inet_protocols in the default configuration file?
>  
>  
> -- 
>   Viktor.


No complaints for postconf.  I don't think postconf will try to open
sockets and realize that there is no ipv4 address.

  # postconf -dh config_directory
  /usr/local/etc/postfix
  # postconf -c /etc/postfix -h config_directory
  /etc/postfix

However if I comment out the workaround almost any other command gives
me complaints: postfix, postmap, postqueue, etc.

  # postmap hash:my-domains
  postmap: warning: smtputf8_enable is true,
   but EAI support is not compiled in
  postmap: warning: inet_protocols:
   disabling IPv4 name/address support: Protocol not supported

If I put back the workaround, then postmap is silent.

Curtis

Re: consequences of Moving to 3.0.3 out of ports

2016-01-28 Thread Curtis Villamizar

In message <47e15980-159e-4f15-8256-c868632b2...@kreme.com>
"@lbutlr" writes:
> 
> I've mostly always compiled postfix myself, but managing postfix and
> the mail server is something I have less and less time for, so I took
> the opportunity of moving to 3.x to switch to using ports in freeBSD
> for postfix.

I've used the port collection version for quite some time.  Very
convenient and works fine.  I'm also using 3.0.3.

> Everything went well, once I removed all the older files from
> /usr/sbin and /usr/libexec since ports uses /usr/local/?
>  
> Are there any other gotchas that I need to look out for? The logs look
> good. I am seeing that there are links in /usr/bin (mailq and
> newaliases) but all the references in main.cf point to
> /usr/local/bin. Should I remove these links? (they link to
> ../../usr/sbin/sendmail)?

Those are the old sendmail programs.  These links all lead to
/usr/sbin/mailwrapper (see man mailwrapper and cat
/etc/mail/mailer.conf ).  Postfix puts a new mailq and newaliases in
/usr/local/bin which link to ../../../usr/local/sbin/sendmail .  You
could remove them but they do no harm.  You should also set
sendmail_procname="/usr/local/sbin/sendmail" in /etc/rc.conf to be
safe and set sendmail*_enable to NO (grep sendmail.\*_enable
/etc/defaults/rc.conf to see what to turn off).

> And one last thing, the new sendmail is *much* smaller than the one
> from 2.11:
>  
>  48 -rwxr-xr-x  1 root  wheel   23368 Jan 23 07:45 /usr/local/sbin/sendmail
> 376 -rwxr-xr-x  1 root  wheel  192456 Jul 20  2015 /usr/sbin/sendmail
>  
>  
> #  ldd /usr/local/sbin/postfix 
> /usr/local/sbin/postfix:
> libpostfix-global.so => /usr/local/lib/postfix/libpostfix-global.so 
> (0x281ba000)
> libpostfix-util.so => /usr/local/lib/postfix/libpostfix-util.so 
> (0x281f3000)
> libsasl2.so.3 => /usr/local/lib/libsasl2.so.3 (0x28228000)
> libpam.so.5 => /usr/lib/libpam.so.5 (0x28241000)
> libcrypt.so.5 => /lib/libcrypt.so.5 (0x2824c000)
> libssl.so.8 => /usr/local/lib/libssl.so.8 (0x28271000)
> libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x2880)
> libdb-5.3.so.0 => /usr/local/lib/libdb-5.3.so.0 (0x2899c000)
> libc.so.7 => /lib/libc.so.7 (0x28077000)
> libthr.so.3 => /lib/libthr.so.3 (0x282d5000)
>  
> I notice that from the list of modules in 2.11 pcre and libz,
> libmysqlclient, and libcdb are all missing from the newer
> compile. However, sql lookups are working and there are no pcre lookup
> errors in the logs. Should I be concerned?

Go back to /usr/ports/mail/postfix-current and type "make config" (or
cat /var/db/ports/mail_postfix-current/options) and see if you
included PCRE.  PCRE and TLS are on by default (see the makefile).
MySQL, Postgress, and SQLite are off by default so you must have
enabled one of them to have SQL working.  [note: this is all freebsd
ports specific].

Mine has PCRE enabled but ldd also doesn't find anything with pcre in
the name.

# pkg info -a | grep postfix
postfix-current-3.0.20151003,4 Secure alternative to widely-used Sendmail

# pkg info -d postfix-current-3.0.20151003,4
postfix-current-3.0.20151003,4:
openssl-1.0.2_5
cyrus-sasl-2.1.26_12
pcre-8.37_4
sqlite3-3.9.2

I don't know why ldd doesn't find the anything with pcre in the name.

Curtis

Re: selective disable of smtpd opportunistic TLS

2016-01-22 Thread Curtis Villamizar

In message <20160122041647.gh25...@mournblade.imrryr.org>
Viktor Dukhovni writes:

> On Thu, Jan 21, 2016 at 10:55:19PM -0500, Curtis Villamizar wrote:
>  
> > It took a while to get a dumpfile.  My tcpdump command only covered a
> > subset of comcast.net mailhosts.
> > 
> > This has a failed TLS negotiation and a few packets from a next
> > attempt.  The log entry below covers this first connection.
>  
> Comcast's Client Hello:
>  
> $ tshark -V -r file.pcap -T text
> ...
> Secure Socket Layer
>   SSL Record Layer: Handshake Protocol: Client Hello
>   Content Type: Handshake (22)
>   Version: TLS 1.0 (0x0301)
>   Length: 110
>   Handshake Protocol: Client Hello
>   Handshake Type: Client Hello (1)
>   Length: 106
>   Version: TLS 1.2 (0x0303)
>   Random
>   gmt_unix_time: Jan 21, 2016 21:42:08.0
>   random_bytes: 
> F015DF3A10F02A3715060148AFF41E28315A20155496A43A...
>   Session ID Length: 0
>   Cipher Suites Length: 18
>   Cipher Suites (9 suites)
>   Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>   Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
>   Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>   Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
>   Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
>   Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
>   Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
>   Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
>   Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
>   ...
>  
> No sign of ECDSA support, or AESGCM, or anything else bleeding
> edge.  Similarly configured MTAs will not be able to complete TLS
> handshakes with your server unless you also deploy an RSA certificate.
>  
> -- 
>   Viktor.

Viktor,

The bug that it doesn't fall back then is likely because comcast mail
servers are running sendmail or something else other than postfix.  If
you do know someone at comcast, then please report that.  You might
also want to report that the keys they use are less than LOW security
but that might be a feature.  Please also ask when opportunistic TLS
was enabled.

Note that none of the ciphers used by comcast.net support even low
strength and forward secrecy.

  cat <https://postmaster.comcast.net/outbound-mail-servers.html

In reviewing the logs very few non-spammer domains seem to be failing.
The most concerning non-spammer is cloud9.net.  I'm still considering
keeping the primary MX with the same sort of key and using either no
TLS or a weaker key on the secondary MX.

I'll also run tcpdump on the cloud9.net addresses and run it through
tshark and see what the problem is there.  If it is simply that they
don't use ECDSA or AESGCM, but they do offer something reasonable,
then I'll consider creating an alternate key.  Otherwise I'll just add
them to the cidr file.  I hope someone at cloud9.net is reading this
(they do host the postfix mailing lists), but if not I'll send
off-list email.

Either way I'll continue to watch the logs (or cron will) for
'SSL_accept error' lines (fail) and for 'Trusted TLS connection from'
(trusted) or 'TLS connection established from' (anon or untrusted).
Having a strict primary MX and a weak secondary allows me to do this
logging without dropping mail.

Note that smtpd_tls_ask_ccert does no damage as the client key is
accepted as untrusted and then AUTH is not offered but relay to my
MDAs still happens (which in the two cases today allowed connections
from google.com allowing spammers using gmail to connect - one sending
to spam@ - obviously having harvested that from a hidden div in web
page of mine requesting help building spam filters - I guess even
gmail has spammers openning free accouts).

Thanks for all of the help and good advice.  Thanks also to Wietse who
suggested using smtpd_discard_ehlo_keyword_address_maps.

Curtis

Re: selective disable of smtpd opportunistic TLS

2016-01-22 Thread Curtis Villamizar

In message <20160122213312.gk25...@mournblade.imrryr.org>
Viktor Dukhovni writes:

> On Fri, Jan 22, 2016 at 03:14:22PM -0500, Curtis Villamizar wrote:
>  
> > You might
> > also want to report that the keys they use are less than LOW security
> > but that might be a feature.
>  
> You're mistaken.  These ciphers are HIGH.
>  
> > Note that none of the ciphers used by comcast.net support even low
> > strength and forward secrecy.
>  
> You're mistaken.
>  
> > So for me falling that far back to encoding in 56 bit DES and a SHA1
> > MAC seems a bit too far backwards to go (back to SSLv3 days).
>  
> You're mistaken.
>  
> -- 
>   Viktor.

Viktor,

Yes.  I rechecked.  I was mistaken.  These four are high and offer
forward secrecy.

DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA

Due to the naming used:

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

I did a few openssl ciphers commands and greps for CBC-SHA and
CBC3-SHA and got the wrong ones based on the naming.

I redid this with openssl ciphers -V and used to hex codes.  The last
two are MEDIUM.  The other six are HIGH.  Four offer forward secrecy,
the ones starting the DHE.

My understanding is that RC4 has multiple proven vulnerabilities so
not using the last two is justified.  SHA1 should be avoided, but
admitedly no one would bother with the computational load needed for a
SHA1 attack on our opportunistic TLS email, particularly no spammer
trying to find a relay to use.

You did not respond to the rest of the email.  Any comments on the
rest of it?

  So for now I'll stick with what I have as it is not a
  problem otherwise and add:

smtpd_discard_ehlo_keyword_address_maps =
  cidr:/etc/postfix/no-tls-for-you

no-tls-for-you:
69.252.207.0/24starttls
96.114.154.0/24starttls
69.252.76.0/24 starttls
76.96.68.0/24  starttls
2001:558:fe16:19::/64  starttls
2001:558:fe21:29::/64  starttls

  That covers the comcast.net mail servers according to
  https://postmaster.comcast.net/outbound-mail-servers.html

  In reviewing the logs very few non-spammer domains seem to be failing.
  The most concerning non-spammer is cloud9.net.  I'm still considering
  keeping the primary MX with the same sort of key and using either no
  TLS or a weaker key on the secondary MX.

  I'll also run tcpdump on the cloud9.net addresses and run it through
  tshark and see what the problem is there.  If it is simply that they
  don't use ECDSA or AESGCM, but they do offer something reasonable,
  then I'll consider creating an alternate key.  Otherwise I'll just add
  them to the cidr file.  I hope someone at cloud9.net is reading this
  (they do host the postfix mailing lists), but if not I'll send
  off-list email.

  Either way I'll continue to watch the logs (or cron will) for
  'SSL_accept error' lines (fail) and for 'Trusted TLS connection from'
  (trusted) or 'TLS connection established from' (anon or untrusted).
  Having a strict primary MX and a weak secondary allows me to do this
  logging without dropping mail.

  Note that smtpd_tls_ask_ccert does no damage as the client key is
  accepted as untrusted and then AUTH is not offered but relay to my
  MDAs still happens [...]

Ammending the above, now knowing that the comcast.net keys are high.
I might just add a longish RSA key as a solution for comcast.net but
keeping high in place.  That might also solve the cloud9.net and one
or two others that are non-spammers and currently fail and fall back
to the secondary MX.

[aside: Perhaps ECDSA-AES256-GCM-SHA384 was a bit too much for email.
It seems to not upset HTTPS and browsers.  OTOH- TLSA/DANE support in
browsers is non-existant without plugins but available for email.]

Thanks again.

Curtis

Re: selective disable of smtpd opportunistic TLS

2016-01-21 Thread Curtis Villamizar

In message <20160115235712.gn...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> 
> On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
>  
> > Viktor,
> > 
> > If you are still interested below is a tcpdump.
> > 
> > If not interested, please just delete.
>  
> I was looking for a binary PCAP file, not an ASCII decode.  Yes,
> it would be good to know whether Comcast was having ECDSA issues,
> or something else.
>  
> -- 
>   Viktor.

Viktor,

It took a while to get a dumpfile.  My tcpdump command only covered a
subset of comcast.net mailhosts.

This has a failed TLS negotiation and a few packets from a next
attempt.  The log entry below covers this first connection.

This fails but fallback to the secondary MX happens and mail gets
delivered.

Curtis


Jan 21 16:42:07 mta3 postfix/smtpd[26462]: connect from 
resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: setting up TLS connection from 
resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: 
resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]: TLS cipher 
list 
"aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5:!DES:!aNULL"
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept:before/accept 
initialization
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL3 alert write:fatal:handshake 
failure
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept error from 
resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]: -1
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: warning: TLS library problem: 
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared 
cipher:s3_srvr.c:1411:
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: lost connection after STARTTLS from 
resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: disconnect from 
resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165] ehlo=1 
starttls=0/1 commands=1/2
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: connect from 
resqmta-po-06v.sys.comcast.net[96.114.154.165]
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: setting up TLS connection from 
resqmta-po-06v.sys.comcast.net[96.114.154.165]
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: 
resqmta-po-06v.sys.comcast.net[96.114.154.165]: TLS cipher list 
"aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5:!DES:!aNULL"
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept:before/accept 
initialization
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL3 alert write:fatal:handshake 
failure
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept error from 
resqmta-po-06v.sys.comcast.net[96.114.154.165]: -1
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: warning: TLS library problem: 
error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared 
cipher:s3_srvr.c:1411:
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: lost connection after STARTTLS from 
resqmta-po-06v.sys.comcast.net[96.114.154.165]




binrbAi2QYSBf.bin
Description: application/binary

Re: Question on master.cf

2016-01-16 Thread Curtis Villamizar

In message 
Paul Goyette writes:

> While researching to see if I could find a way to fix my other issue
> (how my primary-MX server can differentiate between messages originating
> on my backup-MX server and those that are simply relayed from elsewhere)
> I thought maybe I could configure the backup-MX to use two different
> smtp transports to sends messages to my primary machine.
>  
> But I'm having difficulty on how to configure this...
>  
> It would appear that master.cf is the place to go.  And it seems that I
> could easily add a new line similar to
>  
>   my_smtp:12345  inet  n  -  n  -  -  smtpd

Better to use this on the secondary where the problem is

smtp inet  n - n - - smtpd
submission   inet  n - n - - smtpd \
[ use -o ... or -o configpath=/path-to-altconfigdir ]

Note that submission is in /etc/services as is smtp (587 and 25).

On port 25 on the secondary only relay mail that is destined to
mydestination to the primary.  Your primary can then always spam check
anything that arrives on port 25.

Use the -o options to only allow your hosts to connect to port 587 and
also to allow relaying the primary MX.

Any misconfigured host in your domain that still sends to port 25 will
get relaying to the outside blocked and then gets spam checked sending
mail to you to complain.

Also take a look at http://www.postfix.org/POSTSCREEN_README.html
which explains how to spam filter before queueing and therefore before
relaying to the primary.  In the MTA (port 25) postscreen replaces
smtpd in the smtp line but there is more to is so read the How-To.
This is an extra step but tosses a lot of obvious spam earlier.

btw- Consider a stronger authentication than IP address, but that is
another topic entirely.

> But it's not clear to me if this syntax will define a new listener (in
> which case this would belong on my primary-MX machine) or if this would
> enable an _outgoing_ connection to primary-MX's port 12345 (in which
> case this would belong on the backup-MX machine).  And in any case, it
> is definitely not clear what syntax would be used for the inverse case.
>  
>  
> If I can get this to work, I think I can modify the local_transport
> parameter on the backup machine to use a non-standard TCP port when
> relaying messages to the primary-MX machine.  Then, on the primary-MX
> I can specify the dspam content filter only on the standard port, and
> not on the special port.
>  
>  
>  
> +--+--++
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +--+--++

Re: selective disable of smtpd opportunistic TLS

In message <20160115051749.gl...@mournblade.imrryr.org>
Viktor Dukhovni writes:
 
> On Thu, Jan 14, 2016 at 11:54:13PM -0500, Curtis Villamizar wrote:
>  
> > > > > > smtp_tls_ciphers = high
> > > > >  
> > > > > Usually best to leave this at "medium".  This is opportunistic
> > > > > TLS, and if high fails, you'll send cleartext, which is NOT
> > > > > stronger than medium.
> > > > 
> > > > That's actually fine if it actuall fell back.  Comcast didn't fall
> > > > back, it tried secondary MX, then TEMPFAIL.  Its only intended for
> > > > internal servers that are supposed to bring up TLS with a trusted key
> > > > and then also SASL authenticate.  Otherwise I might just leave it at
> > > > none.
> > >  
> > > This is an SMTP *client* setting for your outbound connections,
> > > and has nothing to do with what happens when Comcast sends you
> > > mail.  My point is that this is unwise, regardless of Comcast.
> > 
> > This is so that the MTA can authenticate to the MDAs.  My MDA config
> > goes have smtpd_tls_req_ccert = yes.
>  
> Use dedicated transports in master.cf for connections to your MDAs,
> say, the "relay" transport or a similar clone, and configure appropriate
> master.cf overrides:
>  
>   master.cf:
> relay  unix  -   -   y   -   -   smtp
>   -o smtp_tls_ciphers=$relay_tls_ciphers
>  
>   main.cf:
> relay_tls_ciphers = high
>  
> Do not set enforce overly stringent TLS settings for outbound
> opportunistic TLS connections to the Internet at large.  Yes,
> admittedly peers with just "MEDIUM" ciphers are becoming increasingly
> rare, so you might not feel much pain, but there's no win from
> enforcing stronger ciphers if when you don't get them, Postfix
> fails over to cleartext.

Viktor,

Thanks.  I'll do this when I install the new server.  If so I might
have a rather long -o argument.

> > > smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
> > > certificate must be issued by a trusted CA.  For port 587 only,
> > > and understand the consequences.
> > 
> > The difference would be if you have:
> > 
> > smtpd_tls_ask_ccert = yes
> > smtpd_tls_req_ccert = no
> > smtpd_tls_auth_only = trusted
>  
> I see, allow untrusted TLS, but only offer SASL to clients with
> trusted certs, and what are the others supposed to do?

There are three cases:

  1.  Anon TLS - they don't provide a cert
  2.  client provides cert with TLSA - trusted, they ignore the AUTH
  3.  internal client has trusted cert and SASL pw - they can relay

Lets leave this suggestion to die.  I don't need this as there is a
better way to do things (bottom of prior email).

> > then the same config supports opportunistic TLS for the outside
> > without client key (they just don't provide one) but does allow an
> > internal client to authenticate and get relaying.
>  
> Relaying is on port 587, where opportunistic connections simply
> don't happen.  On port 25 you should have no submission clients.
> So this is a non-issue.  Just unconditionally disable SASL on port 25.

See bottom of the prior email.

> > As I mentioned way down at the bottom, another and probably better
> > solution is to relay through the MSA.
>  
> Relay through the MSA, or some other dedicated port.  You can use
> client cert authorization for that, and not bother with SASL at
> all.

By MSA here I mean another host that serves as MSA (on port 25) not
same host on port 587.  Both approaches work.  See bottom of prior
email.

> > > > Relevant parts:
> > > > 
> > > > ASN1 OID: secp384r1
> > > > Signature Algorithm: ecdsa-with-SHA256
> > >  
> > > Well, that's probably why comcast is having trouble, they likely
> > > don't support ECDSA.  You really should field an RSA certificate,
> > > along with the (still bleeding-edge) ECDSA certificate.
> > 
> > That was my first theory but stated a different way.  I said early on
> > that they are probably running older (openssl 1.0.1) code that doesn't
> > support secp384r1.
>  
> Except that 1.0.1 does support EC with that curve, but not on RedHat
> systems (very cautious lawyers).

OK.  If you say so.  My emperical experience indicates that this
version does not support it.  OpenSSL 1.0.1p-freebsd 9 Jul 2015

> > > > Not supported in openssl 1.0.1, but that is > 1 year old version.
> > >  
> > > Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
> > >

Re: Postfix with dspam on a backup-MX server

In message 
Paul Goyette writes:
>  
>  
> I'm having a little bit of a problem with my configuration...  :)
>  
> I have followed all of the how-to docs on getting things set up, and
> everything works fine when an Email client connects to my primary mail
> server.  The postfix rules get triggered and the dspam filter gets
> invoked.
>  
> The problem occurs when a "foreign" client uses my backup MX relay
> machine.  The backup-MX machine is part of my own network, so it gets
> included in the primary server's $mynetworks (via 'mynetworks_style =
> subnet'). Unfortunately this seems to cause my
>  
>   smtpd_client_restrictions = permit_mynetworks,
>   check_client_access ...dspam...
>  
> to permit the message without triggering the dspam filter.

Hi Paul,

I'm not the expert that some on this list are ... but here goes.

Take a look at http://www.postfix.org/SMTPD_ACCESS_README.html#danger
and see if it seems familiar.  If so the answer might be in the use of
smtpd_relay_restrictions rather than smtpd_recipient_restrictions as
long as you are running postfix >= 2.10.

If not, then you might be able to move reject_unauth_destination up in
the list.

> Is there a more appropriate way to trigger the dspam filter, so that
> messages that are relayed by the backup MX server get filtered, BUT
> messages that _originate_on_ the backup MX server are not filtered?

How about http://www.postfix.org/SMTPD_PROXY_README.html ?

> Stated another way, there are 3 classes of messages involved:
>  
> 1. Messages that originate on either of the MX servers.
> 2. Messages that originate externally, and are initially sent to the
> backup-MX machine;  the backup-MX does the usual store-&-forward
> to get messages to the primary-MX machine.
> 3. Messages that originate externally and are sent directly to the
> primary-MX machine.
>  
> Class 1 should _not_ be processed by dspam, and currently behaving
>  as desired
> Class 2 _should_ be processed, but currently is not being processed
> Class 3 _should_ be processed, and is currently behaving as desired.
>  
> Config details are available - just ask for them!

If that didn't help and no one else responds, then maybe go for it.

> +--+--++
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
> | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
> +--+--++

Curtis

Re: selective disable of smtpd opportunistic TLS

In message <20160115235712.gn...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> 
> On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
>  
> > Viktor,
> > 
> > If you are still interested below is a tcpdump.
> > 
> > If not interested, please just delete.
>  
> I was looking for a binary PCAP file, not an ASCII decode.  Yes,
> it would be good to know whether Comcast was having ECDSA issues,
> or something else.
>  
> -- 
>   Viktor.


OK.  I'll do another packet capture.  Binary this time.

Curtis

Re: selective disable of smtpd opportunistic TLS

In message <88031027-d5b8-4f48-947d-294302fac...@dukhovni.org>
Viktor Dukhovni writes:
 
> Post a PCAP file of a single failed TLS handshake.  I know the person
> at comcast in charge of their email transport security.   I can probably
> get them to fix it once we nail down the problem, assuming it is not overly
> aggressive settings on your end.
>  
> -- 
>   Viktor.


Viktor,

If you are still interested below is a tcpdump.

If not interested, please just delete.

Curtis


# tcpdump -n -i em1 -K -l -t -vvv -X 'net 96.114.154.0/24 || net 
2001:558:fe16:19:96:114:154:0/120' | & tee /tmp/dumpfile

tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP (tos 0x0, ttl 53, id 60614, offset 0, flags [DF], proto TCP (6), length 60)
96.114.154.163.59007 > 192.34.84.171.25: Flags [S], seq 2932514262, win 
14600, options [mss 1460,nop,nop,TS val 3786830096 ecr 0,nop,wscale 3], length 0
0x:  4500 003c ecc6 4000 3506 4912 6072 9aa3  E..<..@.5.I.`r..
0x0010:  c022 54ab e67f 0019 aeca 9dd6    ."T.
0x0020:  a002 3908 7c18  0204 05b4 0101 080a  ..9.|...
0x0030:  e1b6 7110   0103 0303..q.
IP (tos 0x0, ttl 64, id 32208, offset 0, flags [DF], proto TCP (6), length 60)
192.34.84.171.25 > 96.114.154.163.59007: Flags [S.], seq 277202429, ack 
2932514263, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3607830461 
ecr 3786830096], length 0
0x:  4500 003c 7dd0 4000 4006 ad08 c022 54ab  E..<}.@.@"T.
0x0010:  6072 9aa3 0019 e67f 1085 c5fd aeca 9dd7  `r..
0x0020:  a012  e7c0  0204 05b4 0103 0306  
0x0030:  0101 080a d70b 1fbd e1b6 7110..q.
IP (tos 0x0, ttl 53, id 60615, offset 0, flags [DF], proto TCP (6), length 52)
96.114.154.163.59007 > 192.34.84.171.25: Flags [.], seq 1, ack 1, win 1825, 
options [nop,nop,TS val 3786830144 ecr 3607830461], length 0
0x:  4500 0034 ecc7 4000 3506 4919 6072 9aa3  E..4..@.5.I.`r..
0x0010:  c022 54ab e67f 0019 aeca 9dd7 1085 c5fe  ."T.
0x0020:  8010 0721 0c3a  0101 080a e1b6 7140  ...!.:q@
0x0030:  d70b 1fbd
IP (tos 0x0, ttl 64, id 32211, offset 0, flags [DF], proto TCP (6), length 97)
192.34.84.171.25 > 96.114.154.163.59007: Flags [P.], seq 1:46, ack 1, win 
1040, options [nop,nop,TS val 3607830691 ecr 3786830144], length 45
0x:  4500 0061 7dd3 4000 4006 ace0 c022 54ab  E..a}.@.@"T.
0x0010:  6072 9aa3 0019 e67f 1085 c5fe aeca 9dd7  `r..
0x0020:  8018 0410 fc2b  0101 080a d70b 20a3  .+..
0x0030:  e1b6 7140 3232 3020 6d74 6133 2e73 6f6d  ..q...@220.mta3.som
0x0040:  6572 7669 6c6c 652e 6f63 636e 632e 636f  erville.occnc.co
0x0050:  6d20 4553 4d54 5020 506f 7374 6669 780d  m.ESMTP.Postfix.
0x0060:  0a   .
IP (tos 0x0, ttl 53, id 60616, offset 0, flags [DF], proto TCP (6), length 52)
96.114.154.163.59007 > 192.34.84.171.25: Flags [.], seq 1, ack 46, win 
1825, options [nop,nop,TS val 3786830374 ecr 3607830691], length 0
0x:  4500 0034 ecc8 4000 3506 4918 6072 9aa3  E..4..@.5.I.`r..
0x0010:  c022 54ab e67f 0019 aeca 9dd7 1085 c62b  ."T+
0x0020:  8010 0721 0a41  0101 080a e1b6 7226  ...!.Ar&
0x0030:  d70b 20a3
IP (tos 0x0, ttl 53, id 60617, offset 0, flags [DF], proto TCP (6), length 89)
96.114.154.163.59007 > 192.34.84.171.25: Flags [P.], seq 1:38, ack 46, win 
1825, options [nop,nop,TS val 3786830374 ecr 3607830691], length 37
0x:  4500 0059 ecc9 4000 3506 48f2 6072 9aa3  E..Y..@.5.H.`r..
0x0010:  c022 54ab e67f 0019 aeca 9dd7 1085 c62b  ."T+
0x0020:  8018 0721 5038  0101 080a e1b6 7226  ...!P8r&
0x0030:  d70b 20a3 4548 4c4f 2072 6573 716d 7461  EHLO.resqmta
0x0040:  2d70 6f2d 3034 762e 7379 732e 636f 6d63  -po-04v.sys.comc
0x0050:  6173 742e 6e65 740d 0a   ast.net..
IP (tos 0x0, ttl 64, id 32212, offset 0, flags [DF], proto TCP (6), length 200)
192.34.84.171.25 > 96.114.154.163.59007: Flags [P.], seq 46:194, ack 38, 
win 1040, options [nop,nop,TS val 3607830739 ecr 3786830374], length 148
0x:  4500 00c8 7dd4 4000 4006 ac78 c022 54ab  E...}.@.@..x."T.
0x0010:  6072 9aa3 0019 e67f 1085 c62b aeca 9dfc  `r.+
0x0020:  8018 0410 9707  0101 080a d70b 20d3  
0x0030:  e1b6 7226 3235 302d 6d74 6133 2e73 6f6d  ..r&250-mta3.som
0x0040:  6572 7669 6c6c 652e 6f63 636e 632e 636f  erville.occnc.co
0x0050:  6d0d 0a32 3530 2d50 4950 454c 494e 494e  m..250-PIPELININ
0x0060:  470d 0a32 3530 2d53 495a 4520 3130 3234  G..250-SIZE.1024
0x0070:  3030

Re: selective disable of smtpd opportunistic TLS

In message <88031027-d5b8-4f48-947d-294302fac...@dukhovni.org>
Viktor Dukhovni writes:
> 
> > On Jan 13, 2016, at 8:52 PM, Curtis Villamizar <cur...@orleans.occnc.com> 
> > wrote:
> > 
> > The logs revealed something about the nature of the problem.  A few of
> > these sort of messages were found.
> > 
> > Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
> >   warning: TLS library problem:
> >   error:1408A0C1:SSL
> >   routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
> > Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
> >   lost connection after STARTTLS
> >   from resqmta-po-05v.sys.comcast.net[2001:558:fe16:19:96:114:154:164]
>  
> Post the output of "postconf -n | grep tls".
> Post the output of "openssl version -a"
>  
> Post a PCAP file of a single failed TLS handshake.  I know the person
> at comcast in charge of their email transport security.   I can probably
> get them to fix it once we nail down the problem, assuming it is not overly
> aggressive settings on your end.
>  
> -- 
>   Viktor.


Hello Viktor,

The output you asked for is below for both MX servers.  Both fail in
the same way if I leave smtpd_tls_security_level = may which is why on
the secondary it was changed to smtpd_tls_security_level = none.  I
get debugging on the primary, mail delivered on the secondary.

btw - Now that I have debugging on I can see that IETF is using TLS
and I've been getting lots of IETF mailing list mail.  This indicates
that others are using TLS successfully.

  # egrep \
  'Trusted TLS connection from|TLS connection established from' \
  /var/log/maillog | awk '{print $6, $11, $12, $15;}' \
  | sort | uniq -c | sort -rn \
  | awk '{printf " %2d %s %s\n%s  %s\n", $1, $2, $3, $4, $5;}'
  6 Anonymous mail.ietf.org[2001:1900:3001:11::2c]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  4 Anonymous unknown[72.13.58.7]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  3 Trusted msa3.somerville.occnc.com[2001:4830:c400:203::172]:
TLSv1  ECDHE-ECDSA-AES256-SHA
  3 Trusted msa1-em1.orleans.occnc.com[2001:470:88e6:1::140]:
TLSv1  ECDHE-ECDSA-AES256-SHA
  3 Anonymous mail.ietf.org[4.31.198.44]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  2 Anonymous ml18tv7c8.sritis.lt[31.193.197.232]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  1 Trusted mda37-em1.somerville.occnc.com[2001:4830:c400:203::1037]:
TLSv1  ECDHE-ECDSA-AES256-SHA
  1 Trusted mda31-em1.somerville.occnc.com[2001:4830:c400:203::1031]:
TLSv1  ECDHE-ECDSA-AES256-SHA
  1 Anonymous vm0157.cs03.seeweb.it[85.94.216.210]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  1 Anonymous unknown[67.227.187.156]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  1 Anonymous unknown[2a01:7c8:aab4:45e::1]:
TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384

The above output is reformated (by awk) for readability.  It seems
some spammers (rDNS = unknown) are running more recent software than
comcast.  But a lot more spammers are running old code and get tossed
out here.  Thats the prior 11 hours (not much mail here).

btw - I just added "!TLSv1.0" to get only TLSv1.2.  I wasn't sure I
could specify !TLSv1.0 so I just tried it.

Curtis


mta3 (primary MX)

/usr/local/sbin/postconf -c /etc/postfix -n | grep tls

smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_cert_file = /etc/postfix/cert.pem
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL MD5 DES
smtp_tls_key_file = /etc/postfix/key.pem
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtp_tls_security_level = dane
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_always_issue_session_ids = no
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_ccert_verifydepth = 5
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = aNULL MD5 DES
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 300
tls_dane_digest_agility = on
tls_dane_digests = sha512 sha256
tls_dane_trust_anchor_digest_enable = yes
tls_disable_workarounds = 0x
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
tls_wildcard_matches_multiple_labels = yes

/usr/local/bin/openssl version -a

OpenSSL 1.0.2e 3 Dec 2015
built on: reproducible build, date unspecified
platform: BSD-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int)
blowfish(idx)
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED
-DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -

TLSv1.0 (was Re: selective disable of smtpd opportunistic TLS)

In message <cmu-lmtpd-92837-145279158...@mda32.somerville.occnc.com>
Curtis Villamizar writes:
 
> btw - I just added "!TLSv1.0" to get only TLSv1.2.  I wasn't sure I
> could specify !TLSv1.0 so I just tried it.
>  
> Curtis


oops that didn't work.

Curtis

Re: selective disable of smtpd opportunistic TLS

Hi Viktor,

I really appreciate all of the good information you have provided.  We
are going in circles in a few places because we have different goals.

See comments inline and at the end of this message.

In message <20160114212645.gk...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> 
> On Thu, Jan 14, 2016 at 03:53:23PM -0500, Curtis Villamizar wrote:
>  
> > > > smtp_tls_ciphers = high
> > >  
> > > Usually best to leave this at "medium".  This is opportunistic
> > > TLS, and if high fails, you'll send cleartext, which is NOT
> > > stronger than medium.
> > 
> > That's actually fine if it actuall fell back.  Comcast didn't fall
> > back, it tried secondary MX, then TEMPFAIL.  Its only intended for
> > internal servers that are supposed to bring up TLS with a trusted key
> > and then also SASL authenticate.  Otherwise I might just leave it at
> > none.
>  
> This is an SMTP *client* setting for your outbound connections,
> and has nothing to do with what happens when Comcast sends you
> mail.  My point is that this is unwise, regardless of Comcast.

This is so that the MTA can authenticate to the MDAs.  My MDA config
goes have smtpd_tls_req_ccert = yes.

This doesn't seem to have caused any problem at all.

> > > > smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
> > >  
> > > This is worse, your opportunistic TLS is constrained to
> > > TLSv1.
> > 
> > The lines are the same.  What I'd like is TLSv1.2 only.  Documentation
> > recommended the !format rather than the "legacy" format (in case there
> > is later a 1.3 defined, for example), there is no TLSv1.0 and TLSv1
> > refers to TLSv1.x.  So no good way to exclude TLSv1.0 afaik (afaik is
> > now past tense, see below).
>  
> To exclude TLSv1, use "!TLSv1".  Do check the docs for syntax,
> that's what they're there for.

By now I figured this out (Note the afaik is now past tense, see
below).  Sorry if I'm seeming dense.

> > > > smtpd_tls_ask_ccert = yes
> > >  
> > > To you do anything with client certs?  If not, don't request
> > > them.
> > 
> > Since the primary reason for having this was for my own hosts,
> > particularly the MSA, the intent was to use them if I could.
>  
> Set that on port 587 only, master.cf.

I have a separate MSA.  Completely different host (BSD jail on a VM).

> > Unfortunately I can't find an option that requires trusted TLS before
> > AUTH, just any TLS (no smtpd_tls_auth_only = trusted, just yes/no).
>  
> smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
> certificate must be issued by a trusted CA.  For port 587 only,
> and understand the consequences.

The difference would be if you have:

smtpd_tls_ask_ccert = yes
smtpd_tls_req_ccert = no
smtpd_tls_auth_only = trusted

then the same config supports opportunistic TLS for the outside
without client key (they just don't provide one) but does allow an
internal client to authenticate and get relaying.

As I mentioned way down at the bottom, another and probably better
solution is to relay through the MSA.  Note that most of my hosts have
to relay with smart host because they are IPv6 only and need to relay
to get to the IPv4 only world.

> > > > smtpd_tls_cert_file = /etc/postfix/cert.pem
> > > > smtpd_tls_key_file = /etc/postfix/key.pem
> > >  
> > > What kind of key is that?  RSA or ECDSA?  Can you
> > > post the output of: 
> > >  
> > > openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v 
> > > ':.*:.*:'
> > 
> > Relevant parts:
> > 
> > ASN1 OID: secp384r1
> > Signature Algorithm: ecdsa-with-SHA256
>  
> Well, that's probably why comcast is having trouble, they likely
> don't support ECDSA.  You really should field an RSA certificate,
> along with the (still bleeding-edge) ECDSA certificate.

That was my first theory but stated a different way.  I said early on
that they are probably running older (openssl 1.0.1) code that doesn't
support secp384r1.

> > Not supported in openssl 1.0.1, but that is > 1 year old version.
>  
> Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
> systems, for patent-fear reasons.

But not secp384r1.  That came with 1.0.2.

> > This is OK if the only thing I want authenticated is my own MSA and
> > MDA servers.
>  
> No, it means that Comcast can't perform a TLS handshake because
> they don't support ECDSA.

I guess we agree that is most likely the problem.

My tcpdump has not picked up anything.  The MTA is a BSD jail and
tcpdump is running on the VM hosting the ja

Re: selective disable of smtpd opportunistic TLS

In message <20160114175729.gg...@mournblade.imrryr.org>
Viktor Dukhovni writes:

> On Thu, Jan 14, 2016 at 12:06:43PM -0500, Curtis Villamizar wrote:
>  
> > /usr/local/sbin/postconf -c /etc/postfix -n | grep tls
> > 
> > smtp_tls_cert_file = /etc/postfix/cert.pem
> > smtp_tls_key_file = /etc/postfix/key.pem
>  
> Usually best to not configure client certificates.
>  
> > smtp_tls_ciphers = high
>  
> Usually best to leave this at "medium".  This is opportunistic
> TLS, and if high fails, you'll send cleartext, which is NOT
> stronger than medium.

That's actually fine if it actuall fell back.  Comcast didn't fall
back, it tried secondary MX, then TEMPFAIL.  Its only intended for
internal servers that are supposed to bring up TLS with a trusted key
and then also SASL authenticate.  Otherwise I might just leave it at
none.

> > smtp_tls_exclude_ciphers = aNULL MD5 DES
>  
> Mostly harmless, but not ideal.  Instead try:
>  
>   smtp_tls_exclude_ciphers =
>   MD5, SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5

OK.  Thanks.  Will do.

> > smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
> This is a terrible idea, it results in unconditional use of
> TLS 1.0 (the hole in that list).  If you really want to force
> TLSv1.2, then you must also disable TLSv1
>  
> > smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
> This is worse, your opportunistic TLS is constrained to
> TLSv1.

The lines are the same.  What I'd like is TLSv1.2 only.  Documentation
recommended the !format rather than the "legacy" format (in case there
is later a 1.3 defined, for example), there is no TLSv1.0 and TLSv1
refers to TLSv1.x.  So no good way to exclude TLSv1.0 afaik (afaik is
now past tense, see below).

> > smtpd_tls_ask_ccert = yes
>  
> To you do anything with client certs?  If not, don't request
> them.

Since the primary reason for having this was for my own hosts,
particularly the MSA, the intent was to use them if I could.

Unfortunately I can't find an option that requires trusted TLS before
AUTH, just any TLS (no smtpd_tls_auth_only = trusted, just yes/no).

The primary reason for having this is for my own servers to use SASL
authenticate after strong TLS and then:

smtpd_tls_auth_only = yes  # would prefer trusted
smtpd_sasl_security_options = mutual_auth
smtpd_relay_restrictions = permit_sasl_authenticated reject_unauth_destination

If I used weak auth it could potentially be leveraged for relay
(although you would have to also get SASL authenticated).  A
man-in-the-middle could watch the SASL with weak encryption and SASL
doesn't offer even moderately strong encryption (DIGEST-MD5) though it
does at least do a weak mutual_auth underneath TLS.

The best I can get now is ask and log when a client cert is trusted.

> > smtpd_tls_cert_file = /etc/postfix/cert.pem
> > smtpd_tls_key_file = /etc/postfix/key.pem
>  
> What kind of key is that?  RSA or ECDSA?  Can you
> post the output of: 
>  
> openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v ':.*:.*:'

Relevant parts:

ASN1 OID: secp384r1
Signature Algorithm: ecdsa-with-SHA256

Not supported in openssl 1.0.1, but that is > 1 year old version.

This is OK if the only thing I want authenticated is my own MSA and
MDA servers.

> > smtpd_tls_ciphers = high
>  
> This is a bad idea, leave it at medium.
>  
> > smtpd_tls_exclude_ciphers = aNULL MD5 DES
>  
> This is not needed.

same as smtp.

> > smtpd_tls_loglevel = 2
>  
> Level 1 is just right, 2 is too much.

Maybe so.  Isn't hurting anything.

> > smtpd_tls_mandatory_ciphers = high
> > smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
> Less harmful on servers, but what do you have against TLSv1.1?
> It is not worse than TLSv1, in fact somewhat better.  Choose
> one of:
>  
> smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
> smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
>  
> > smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
> For opportunistic TLS leave TLSv1, TLSv1.1 and TLSv1.2 enabled.
>  
>   smtpd_tls_protocols = !SSLv2 !SSLv3
>  
> you're changing too many carefully chosen default settings,
> and doing more harm than good.

I thought (apparently incorrectly) that TLSv1 was TLSv1.x so I didn't
include it.  Documentation was not clear on that.

> > smtpd_tls_session_cache_timeout = 300
>  
>Longer is better, especially with Postfix 2.11+ and session
>tickets.  Let the default stand.

Hasn't been a problem.  What would it break?

> > tls_dane_digest_agility = on
> > tls_dane_digests = sha512 sha256
> > tls_dane_trust_anc

Re: TLSv1.0 (was Re: selective disable of smtpd opportunistic TLS)