from:"Curtis"




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 
> <donotre...@ditech.com>, 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=<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

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 <ced...@gn.apc.org> 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

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 <rob...@chalmers.com.au> 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 <a63e44a5-cc29-48c2-9a88-978275bd6...@rfc1035.com>
Jim Reid writes:
>  
> > On 13 Mar 2016, at 15:06, Robert Chalmers <rob...@chalmers.com.au> 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 <c2f5f6c7-83f0-4206-87f1-4ca72b91a...@kreme.com>
"@lbutlr" writes:
 
> On Fri Mar 11 2016 12:21:07 Noel Jones<njo...@megan.vbhcs.org> 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: [SOLVED] Re: A bug, maybe?

2016-02-22 Thread Curtis Maurand




On 2/22/2016 3:03 PM, Viktor Dukhovni wrote:

On Mon, Feb 22, 2016 at 02:57:23PM -0500, Curtis Maurand wrote:


The problem was in the /etc/nsswitch.conf.
I changed the line
 hosts:   files dns
to
 hosts:dns files
and that solved the trouble.

Is "delivery.mailspamprotection.com" listed in /etc/hosts?

If so, then the wound was self-inflicted.  If not, then the C-library
getaddrinfo() is buggy, since skipping all the non-matching entries
in /etc/hosts should have no effect on the results from DNS.

Why yes it was.  I don't even remember doing that.

I will sheepishly return to my corner, now, with my head bowed in 
embarrassment.  I'll need a bandage to stop the bleeding.


--Curtis


--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748

[SOLVED] Re: A bug, maybe?

2016-02-22 Thread Curtis Maurand




On 2/20/2016 5:19 PM, Curtis Maurand wrote:



On 2/20/2016 1:46 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
returns a valid address.  It might not match the reverse, but it did return
an address.
# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

 $ ./getaddrinfo delivery.mailspamprotection.com
 Hostname:   delivery.mailspamprotection.com
 Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 
108.163.204.150 198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 
198.143.161.21 184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 
96.127.190.4 198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 
69.175.69.93 184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 
198.143.161.27 108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 
184.154.58.230 108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 
108.163.201.226 108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 
198.143.161.12 184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 
69.175.69.90 108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 
184.154.48.172 108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 
108.163.204.149 96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 
108.178.24.173 108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 
198.143.161.20 184.154.58.229 1
08.163.220.51 96.127.176.251 108.163.220.50 108.178.24.170 108.163.220.53 
198.143.161.22 184.154.208.38 184.154.48.170 184.154.58.228 108.178.24.172 
198.143.161.14 108.178.24.179 198.143.161.19 108.163.204.147 198.143.161.26 
96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

 http://www.linfo.org/etc_host_conf.html

 /etc/hosts.conf:
multi on


That said.  Since the unit has been updated, but not rebooted, I may need to
reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.


interesting.  on my 12.04 mail server it works correctly.  on the 
14.04 server it is not.  both have "multi on" set.  I fired up another 
virtual machine with 14.04 installed and that one works fine.  As a 
work around, I've set my mx to the 12.04 machine that works with a 
transport command that sends the mail to the host that should be 
receiving the mail.  the machine that is not working right claims to 
not have any updates available, thought the getaddrinfo() has been 
patched.  frustrating.  Thank you for your help.  The problem appears 
to not be postfix.


The problem was in the /etc/nsswitch.conf.

I changed the line

hosts:   files dns

to

hosts:dns files

and that solved the trouble.

--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748

Re: A bug, maybe?




On 2/20/2016 1:46 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 01:37:39PM -0500, Curtis Maurand wrote:


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program
returns a valid address.  It might not match the reverse, but it did return
an address.
# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

There's your problem, it is supposed to return *all* the addresses.  On
my system:

 $ ./getaddrinfo delivery.mailspamprotection.com
 Hostname:   delivery.mailspamprotection.com
 Addresses:  108.163.220.52 108.163.201.229 69.175.69.94 
108.163.204.150 198.143.161.10 108.163.201.230 96.127.190.5 184.154.58.227 
198.143.161.21 184.154.48.173 198.143.161.29 69.175.69.92 108.163.243.190 
96.127.190.4 198.143.161.30 108.178.24.182 108.163.243.188 108.163.228.171 
69.175.69.93 184.154.208.34 184.154.208.36 96.127.176.253 96.127.190.2 
198.143.161.27 108.163.220.54 198.143.161.11 108.163.228.170 198.143.161.13 
184.154.58.230 108.163.243.189 108.163.228.174 108.163.201.228 108.178.24.171 
108.163.201.226 108.178.24.181 108.163.201.227 184.154.208.37 108.178.24.174 
198.143.161.12 184.154.48.171 96.127.176.250 108.163.243.186 108.178.24.180 
69.175.69.90 108.163.243.187 108.163.228.172 96.127.176.252 184.154.177.50 
184.154.48.172 108.163.204.148 198.143.161.28 108.163.204.146 184.154.208.35 
108.163.204.149 96.127.190.6 69.175.69.91 184.154.58.226 108.163.228.173 
108.178.24.173 108.178.24.178 96.127.176.254 198.143.161.18 184.154.48.174 
198.143.161.20 184.154.58.229 108.163.220.51 96.127.176.251 108.163.220.50 
108.178.24.170 108.163.220.53 198.143.161.22 184.154.208.38 184.154.48.170 
184.154.58.228 108.178.24.172 198.143.161.14 108.178.24.179 198.143.161.19 
108.163.204.147 198.143.161.26 96.127.190.3

If your getaddrinfo returns only the first address, it is busted.
Perhaps this is controlled via /etc/hosts.conf:

 http://www.linfo.org/etc_host_conf.html

 /etc/hosts.conf:
multi on


That said.  Since the unit has been updated, but not rebooted, I may need to
reboot to get the kernel fix.  Ubuntu does, at least, backport fixes.

The getaddrinfo issue is not resolved via a kernel fix, it is
addressed via a glibc fix.


interesting.  on my 12.04 mail server it works correctly.  on the 14.04 
server it is not.  both have "multi on" set.  I fired up another virtual 
machine with 14.04 installed and that one works fine.  As a work around, 
I've set my mx to the 12.04 machine that works with a transport command 
that sends the mail to the host that should be receiving the mail.  the 
machine that is not working right claims to not have any updates 
available, thought the getaddrinfo() has been patched.  frustrating.  
Thank you for your help.  The problem appears to not be postfix.



--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748

Re: A bug, maybe?




On 2/20/2016 12:17 PM, Viktor Dukhovni wrote:

On Sat, Feb 20, 2016 at 11:40:09AM -0500, Curtis Maurand wrote:


i just sent myself a test message from the client's system.  Here is what I
got.  I immediately ran the lookups using dig.  postfix can't seem to
resolve things properly.  Running Ubuntu Server 14.04 LTS with ispconfig
installed.  I'm using powerdns with powerdns recursor.  resolv.conf points
to the localhost's external ip address.  This is sort of annoying.  I really
don't want to open up the server's to misconfigured system as that increases
the amount of spam dramatically.

Do keep in mind that on Ubuntu systems Postfix tends to have many
services in master.cf chooted by default, the chroot jail may have
a different /etc/resolv.conf, and may have different copies of
various dynamically loaded nss modules.

Do disable chroot for "smtpd" if enabled, and do test your
getaddrinfo() implementation.


Nothing is chrooted.  resolv.conf is world readable.  Wietse's program 
returns a valid address.  It might not match the reverse, but it did 
return an address.

# ./getaddr delivery.mailspamprotection.com
Hostname:   delivery.mailspamprotection.com
Addresses:  108.163.228.171

That said.  Since the unit has been updated, but not rebooted, I may 
need to reboot to get the kernel fix.  Ubuntu does, at least, backport 
fixes.





--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748

Re: A bug, maybe?




On 2/20/2016 11:26 AM, Curtis Maurand wrote:



On 2/20/2016 11:12 AM, Christian Kivalo wrote:

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from=<edi...@whiteeaglenews.com> to=<cmaur...@xyonet.com> proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery




450 4.7.1 Client host rejected: cannot find your hostname,
[108.163.243.188]:
retry timeout exceeded

the original message was sent on the 15th.  the return bounce on the 
19th.  I haven't rebooted or restarted services on that machine and 
all of the included lookups for this mail message were performed on 
the same machine this morning.


i just sent myself a test message from the client's system.  Here is 
what I got.  I immediately ran the lookups using dig.  postfix can't 
seem to resolve things properly.  Running Ubuntu Server 14.04 LTS with 
ispconfig installed.  I'm using powerdns with powerdns recursor.  
resolv.conf points to the localhost's external ip address.  This is sort 
of annoying.  I really don't want to open up the server's to 
misconfigured system as that increases the amount of spam dramatically.


Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: warning: hostname 
delivery.mailspamprotection.com does not resolve to address 108.163.220.52
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: connect from 
unknown[108.163.220.52]
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: NOQUEUE: reject: RCPT 
from unknown[108.163.220.52]: 450 4.7.1 Client host rejected: cannot 
find your hostname, [108.163.220.52]; from=<cmaur...@whiteeaglenews.com> 
to=<cmaur...@xyonet.com> proto=ESMTP helo=
Feb 20 11:31:45 ispconfig postfix/smtpd[16013]: disconnect from 
unknown[108.163.220.52]

Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: connect from localhost[::1]
Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: lost connection after 
CONNECT from localhost[::1]
Feb 20 11:32:01 ispconfig postfix/smtpd[16013]: disconnect from 
localhost[::1]


root@ispconfig:/var/www/webmail.xyonet.com/web# dig 
delivery.mailspamprotection.com |grep 108.163.220

delivery.mailspamprotection.com. 30 IN  A 108.163.220.50
delivery.mailspamprotection.com. 30 IN  A 108.163.220.51
delivery.mailspamprotection.com. 30 IN  A 108.163.220.53
delivery.mailspamprotection.com. 30 IN  A 108.163.220.54
delivery.mailspamprotection.com. 30 IN  A 108.163.220.52
root@ispconfig:/var/www/webmail.xyonet.com/web# dig ptr 
52.220.163.108.in-addr.arpa


; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> ptr 52.220.163.108.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32216
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;52.220.163.108.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
52.220.163.108.in-addr.arpa. 3495 INPTR delivery.mailspamprotection.com.





--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748


--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748

Re: A bug, maybe?




On 2/20/2016 11:12 AM, Christian Kivalo wrote:

On 2016-02-20 16:45, Curtis Maurand wrote:

Not sure if I found something or not.  A client tried to send email
to one of my other addresses.  The requisite portion of the main.cf
follows at the end of the message.  The logs are telling me:

Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: warning: hostname
delivery.mailspamprotection.com does not resolve to address
108.163.243.188
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: connect from
unknown[108.163.243.188]
Feb 19 16:30:29 ispconfig postfix/smtpd[18437]: NOQUEUE: reject: RCPT
from unknown[108.163.243.188]: 450 4.7.1 Client host rejected: cannot
find your hostname, [108.163.243.188];
from=<edi...@whiteeaglenews.com> to=<cmaur...@xyonet.com> proto=ESMTP
helo=


Have you had dns lookup problems? This is a temporary error and the 
client should retry delivery




450 4.7.1 Client host rejected: cannot find your hostname,
[108.163.243.188]:
retry timeout exceeded

the original message was sent on the 15th.  the return bounce on the 
19th.  I haven't rebooted or restarted services on that  machine and all 
of the included lookups for this mail message were performed on the same 
machine this morning.



--
Curtis Maurand
cur...@maurand.com <mailto:cur...@maurand.com>
207-252-7748

A bug, maybe?