Re: valvula or policyd

[Benning, Markus]

Hi,

i just uploaded version 1.15 of mtpolicyd with support for accounting 
and quotas:


https://markusbenning.de/blog/?p=36

I also wrote a small guide on how to implement smtp level 
accounting/quotas with mtpolicyd:


https://mtpolicyd.org/getting-started.html#Mail::MtPolicyd::Cookbook::HowtoAccountingQuota

--
Markus


Am 2014-12-23 13:50, schrieb Benning, Markus:

I just implemented a first version of a accounting plugin for
mtpolicyd:

https://www.mtpolicyd.org/documentation.html#Mail::MtPolicyd::Plugin::Accounting

github project: https://github.com/benningm/mtpolicyd

I'm currently testing it on a small postfix installation with the
following setup:

Vhost in mtpolicyd.conf:


  name="accounting"

  
module = "Accounting"
fields = "client_address,sasl_username,recipient,sender"
  


(dont forget to configure a database with db_dsn,db_user,db_password in 
global)


Check in postfix:

smtpd_end_of_data_restrictions = check_policy_service 
inet:127.0.0.1:12346


If you're using an smtpd_proxy_filter setup dont forget to add

-o smtpd_end_of_data_restrictions=

to the re-inject smtpd instances or you'll duplicate counters.

My plan is to test the plugin for a while and also implement a Quota 
plugin

to enforce limits and then release it with the next version.


Markus

On Sat, Dec 20, 2014 at 02:16:56PM +0100, Benning, Markus wrote:

Hello,

i created a policyd called mtpolicyd. You can find the project
website at:

https://mtpolicyd.org/

It is written in perl and is easily extentible thru perl plugins.
Currently its main target is spamfiltering/reputation and therefor i'm
already using it in production.

I'll have to extend it with more relay access control features in
near future.
I'm also willed to write a quota plugin(s) for it.
You're welcome if you want to contribute your requirements, use
cases, testing or code.

 Markus

Am 2014-12-19 16:04, schrieb Selcuk Yazar:
>Hi,
>
>we are using for quota management policyd v2.0.11 . i want to upgrage
>policyd to 2.0.14 .
>
>what is the best policyd software for postfix . Valvula in fist order
>on list
>
>should i upgrade or install valvula ?
>
>thanks in advance.
>
>--
>
>Selçuk YAZAR

Issues using Postfix behind a load balancer

[Brad Riemann]

Hello!

First time caller, long time listener :).

I've been working on a new mail filtering solution for our company that 
revolves around the solution receiving inbound mail through a load balancer.

We have come upon an issue that I am not finding any sort of documentation or 
notes that others have experienced..

We are using a load balancer behind a nat, that distributes the inbound emails 
to a clustered mail scanning solution (we have been having issues with our 
current solution where the existing servers are overloaded, and this gives us 
the ability to plug and play new servers with zero dns adjustments..) Now, our 
load balancers hands off the message to the first available postfix server, we 
get headers that look like the following (after postfix picks it up).

--
Received: from batch.email.flyfrontier.com (edge1.dc1.domain.com [172.16.4.#])
 by mta02.dc1.domain.com (Postfix) with ESMTP id ###
 for ; Wed, 7 Jan 2015 10:48:52 -0600 (CST)
--

The issue, if you don't see it, is that postfix seems to be using the load 
balancer ip as the last hop, and because the load balancer is just pushing 
content through it is not recording the previous hop to the headers, which is 
causing some issues..

I have looked at the proxy protocol settings, as well as the XCLIENT options, I 
was just wondering if anyone had any success using the re-writing options 
within postfix to fix the received header before it gets processed by the 
scanners/grey list check?

Our load balancer might be able to rewrite the headers, but I have to assume 
that these are written based on the way that postfix is receiving the email, 
from the load balancer node instead of ignoring the node and just using the 
previous hop for this purpose.

Not being able to see the last true hop is causing issues with the scanning 
software and I've been racking my brain the last few days trying to figure out 
how to make this work properly..

Any advice would be greatly appreciated!

Brad Riemann

briem...@techpro.com



Phone: 630 .938 .5300
Toll Free: 800. 262 .0537
Direct Fax: 630. 845 .4635

2325 Dean St.
Suite 900
St. Charles, IL 60175

[cid:image002.gif@01CDDA01.062C9560]


For Support Dial: 800 .262 .0537 Press 3 at the prompt

[cid:image003.gif@01CDDA01.062C9560]

w w w . t e c h p r o . c o m


TechPro E-Mail Disclaimer
The information contained in this e-mail and any accompanying documents is 
confidential, may be privileged, and is intended solely for the person and/or 
entity to whom it is addressed (i.e. those identified in the "To" and "Cc" 
box). They are the property of TechPro, Inc. Unauthorized review, use, 
disclosure, or copying of this communication, or any part thereof, is strictly 
prohibited and may be unlawful. If you have received this e-mail in error, 
please return the e-mail and attachments to the sender and delete the e-mail 
and attachments and any copy from your system. TechPro, Inc. Thank you for your 
cooperation.

Re: DANE and DLV

[John]

I assume this list is "best" to "worst"

; Use "3 1 1", the other three are OK, but "3 1 1" is better.
_25._tcp.mx.example.com. IN TLSA 3 1 1 
_25._tcp.mx.example.com. IN TLSA 3 0 1 
_25._tcp.mx.example.com. IN TLSA 3 1 2 
_25._tcp.mx.example.com. IN TLSA 3 0 2 

; Use "2 0 1", the other three are OK, but "2 0 1" is better.
_25._tcp.mx.example.com. IN TLSA 2 0 1 
_25._tcp.mx.example.com. IN TLSA 2 1 1 
_25._tcp.mx.example.com. IN TLSA 2 0 2 
_25._tcp.mx.example.com. IN TLSA 2 1 2 

I am not sure I understand this. Why are you linking the two?

 * Do understand how to coordinate DANE TLSA record updates with
   key rotation, and never forget to update DANE TLSA records
   as part of that process.
Has anybody published any recommendations as to timing for the life 
cycle of a ZSK  (and KSK for that matter)? So far the only 
recommendation I have seen was a footnote in a paper on DNSSEC. It 
recommended 1yr for KSK and 4Yrs for KSKs. I think these number are 
unrealistic for a couple of reasons 1) with the growth of hacker nets i 
do not think keys can survive that long. 2) on a much more mundane level 
- with staff turn over etc., rollover is  liable to slip between the cracks.


Are there any know tools to automate rollover? I have not found any and 
have been writing my own script but being a lazy s.. i would prefer to 
use somebody elses work!


Victor - I have a question and a suggestion which I would like to 
explore offline. May I contact you at IETF, or at any other address you 
like, you may contact me a j...@klam.ca.


--
John Allen
KLaM
--
You are off the edge of the map, mate. Here there be monsters!

Re: DANE and DLV

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 01:00:10PM -0500, John wrote:

> I assume this list is "best" to "worst"

Roughly speaking yes, though none are a disaster.  Pick usage "3"
in most cases, but if you known what you're doing, want to operate
an internal CA and have lots of hosts to secure, usage 2 might be
right for you.

> > ; Use "3 1 1", the other three are OK, but "3 1 1" is better.
> > _25._tcp.mx.example.com. IN TLSA 3 1 1  > public key in X.509 SPKI format>
> > _25._tcp.mx.example.com. IN TLSA 3 0 1  > cert>
> > _25._tcp.mx.example.com. IN TLSA 3 1 2  > public key in X.509 SPKI format>
> > _25._tcp.mx.example.com. IN TLSA 3 0 2  > cert>
> >
> > ; Use "2 0 1", the other three are OK, but "2 0 1" is better.
> > _25._tcp.mx.example.com. IN TLSA 2 0 1  > certificate>
> > _25._tcp.mx.example.com. IN TLSA 2 1 1  > public key in X.509 SPKI format>
> > _25._tcp.mx.example.com. IN TLSA 2 0 2  > certificate>
> > _25._tcp.mx.example.com. IN TLSA 2 1 2  > public key in X.509 SPKI format>
>
> I am not sure I understand this. Why are you linking the two?

I am not linking anything.

> > * Do understand how to coordinate DANE TLSA record updates with
> >   key rotation, and never forget to update DANE TLSA records
> >   as part of that process.
>
> Has anybody published any recommendations as to timing for the life cycle of
> a ZSK  (and KSK for that matter)? So far the only recommendation I have seen
> was a footnote in a paper on DNSSEC. It recommended 1yr for KSK and 4Yrs for
> KSKs. I think these number are unrealistic for a couple of reasons 1) with
> the growth of hacker nets i do not think keys can survive that long. 2) on a
> much more mundane level - with staff turn over etc., rollover is  liable to
> slip between the cracks.

I'll leave DNSSEC ops for others to describe,  I'm relatively new to that.

> Victor - I have a question and a suggestion which I would like to explore
> offline. May I contact you at IETF, or at any other address you like, you
> may contact me a j...@klam.ca.

OK.

-- 
Viktor.

Re: Issues using Postfix behind a load balancer

[Wietse Venema]

Brad Riemann:
> The issue, if you don't see it, is that postfix seems to be using
> the load balancer ip as the last hop, and because the load balancer
> is just pushing content through it is not recording the previous
> hop to the headers, which is causing some issues..

Postfix can get the client IP address from haproxy (uses haproxy
protocol, supported in postscreen and smtpd) and from nginx (uses
XCLIENT, supported in smtpd only).

The client IP address is needed to for access decisions and for
audit trail information (logging, headers, etc.).

If your load balancer can provide that information, then I can try
to add a driver to Postfix to use that information.

Wietse

RE: Issues using Postfix behind a load balancer

[Brad Riemann]

Thanks Wietse, I figured that was where I was at, but was hoping there were 
other options I hadn't uncovered..

Brad

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Wietse Venema
Sent: Wednesday, January 07, 2015 12:32 PM
To: Postfix users
Subject: Re: Issues using Postfix behind a load balancer

Brad Riemann:
> The issue, if you don't see it, is that postfix seems to be using the 
> load balancer ip as the last hop, and because the load balancer is 
> just pushing content through it is not recording the previous hop to 
> the headers, which is causing some issues..

Postfix can get the client IP address from haproxy (uses haproxy protocol, 
supported in postscreen and smtpd) and from nginx (uses XCLIENT, supported in 
smtpd only).

The client IP address is needed to for access decisions and for audit trail 
information (logging, headers, etc.).

If your load balancer can provide that information, then I can try to add a 
driver to Postfix to use that information.

Wietse

Re: Issues using Postfix behind a load balancer

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 01:31:45PM -0500, Wietse Venema wrote:

> Brad Riemann:
> > The issue, if you don't see it, is that postfix seems to be using
> > the load balancer ip as the last hop, and because the load balancer
> > is just pushing content through it is not recording the previous
> > hop to the headers, which is causing some issues..
> 
> Postfix can get the client IP address from haproxy (uses haproxy
> protocol, supported in postscreen and smtpd) and from nginx (uses
> XCLIENT, supported in smtpd only).
> 
> The client IP address is needed to for access decisions and for
> audit trail information (logging, headers, etc.).
> 
> If your load balancer can provide that information, then I can try
> to add a driver to Postfix to use that information.

With F5/A10 load balancers it is common to configure them to inject
XCLIENT commands into the SMTP stream and then splice in the real
client EHLO/HELO after returning the server's banner.

Some folks using these at present might post a suitable connection
script or point you at a HOWTO for same.

-- 
Viktor.

Re: DANE and DLV

[John]

On 1/7/2015 1:22 PM, Viktor Dukhovni wrote:

I am not sure I understand this. Why are you linking the two?
I am not linking anything.
I am not sure what TLSA updates has to do with key rotation, other than 
they might be a good idea to do them at the same time. May be its my odd 
ball way of reading it.

 * Do understand how to coordinate DANE TLSA record updates with
   key rotation, and never forget to update DANE TLSA records
   as part of that process.




--
John Allen
KLaM
--
A day without sunshine is like, night?

Re: DANE and DLV

[Jean Bruenn]

On 07/01/15 02:07, Jim Reid wrote:
BTW, it's particularly unwise to adopt DLV to kludge around TLD 
registries or registrars who can't/won't support DNSSEC properly. This 
was the OP's rationale for going down that path. IMO the OP should 
switch to another registrar and let the slacker registrar know why 
they've lost the OP's business.


I don't want to go offtopic but there seem to be still "many"
registrars which do not support dnssec. I for example asked
three different registrars in germany and got the same
answer - they're working on it, due to the little demand
they haven't implemented anything for that now. I am
sure that I'll be able to find a registrar in germany with the
same prices, a similar realtime API and dnssec support.
Still I would not like to switch after 10+ years without any
trouble, to another registrar - call me lazy if you want.

Currently I am testing and "playing around" with dnssec,
dane and such stuff to learn more about it - I am not in pressure
to implement it neither do I need it cuz' its cool or something.
When implementing DNSSEC in my own nameservers I
noticed (due to forwarders I was using) that three different
(one of them is quite big) datacenters in germany don't
support dnssec - the public orsn nameserver does not,
neither. 3 is not a representative number, might be that
I picked the 3 that cannot while the other 97 can.

Would be pretty interesting to see some country-statistic
about dnssec usage. Actually the only public dns that
supports dnssec I found at a first glance was google and
I'd rather not use that (I am not using forwarders anymore
anyway) :^)

Re: DANE and DLV

[Jean Bruenn]

On 07/01/15 02:01, Viktor Dukhovni wrote:

Of the approximately 800 domains that I found to have published
DANE TLSA records for SMTP to date, too many had various problems.

We'll announce a testing site soon that will help detect problems
early, but it won't prevent them if the site's administrator is
not sufficiently disciplined about ongoing operational requirements.

If you understand DNS and email well, are ready to implement DNSSEC
and are good at not losing track of details, please implement DANE,
otherwise, please wait, or use a professionally operated hosting
service that will do it for you.



Thanks a lot for all information that was pretty helpful. I'd be
glad to hear from you once that testing page is ready to be
used.

I will continue to read about that topic and continue to try
in a test-environment.

Jean

Re: DANE and DLV

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 01:47:06PM -0500, John wrote:

> >I am not sure I understand this. Why are you linking the two?
> >I am not linking anything.
>
> I am not sure what TLSA updates has to do with key rotation, other than they
> might be a good idea to do them at the same time. May be its my odd ball way
> of reading it.

I am talking about SMTP server TLS key/cert rotation, not DNSSEC
key rotation.  

And not at the same time, the TLSA RRs for new certs/keys need to
be published before the keys are deployed concurrently with the
live keys.  Let the combination age a few TTLs, then deploy the
new keys.

https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.4

With DNSSEC it is the other way around.  Publish old and new DNSKEY
records first, let that bake in for a few TTLs, then publish new
DS RRs.  When removing keys, drop corresponding DS RR first, let
than RRset age a bit, then remove the keys.

Invariants:

DNSSEC:  For each not yet expired (TTL) DS RRset there is
always a corresponding DNSKEY published at the zone apex.

DANE:  At all times the server's live certificate chain
matches at least one TLSA record in every not yet expired
(TTL) TLSA RRset.

Key rotation must maintain these invariants.

No extant DS RRsets that contain records with no matching DNSKEY.

No TLS certificate chains that fail to match some record in
every extant TLSA RRset.

-- 
Viktor.

Re: DANE and DLV

[Thomas Leuxner]

* Jean Bruenn  2015.01.07 19:54:

> I don't want to go offtopic but there seem to be still "many"
> registrars which do not support dnssec. I for example asked
> three different registrars in germany and got the same
> answer - they're working on it, due to the little demand
> they haven't implemented anything for that now.

They actually DO exist. I can make recommendations off-list if you are still 
searching...


signature.asc
Description: Digital signature

Re: DANE and DLV

[Jean Bruenn]

On 07/01/15 20:09, Thomas Leuxner wrote:

* Jean Bruenn  2015.01.07 19:54:


I don't want to go offtopic but there seem to be still "many"
registrars which do not support dnssec. I for example asked
three different registrars in germany and got the same
answer - they're working on it, due to the little demand
they haven't implemented anything for that now.

They actually DO exist. I can make recommendations off-list if you are still 
searching...


Feel free to do so.

Re: DANE and DLV

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 07:54:03PM +0100, Jean Bruenn wrote:

> I am
> sure that I'll be able to find a registrar in germany with the
> same prices, a similar realtime API and dnssec support.
> Still I would not like to switch after 10+ years without any
> trouble, to another registrar - call me lazy if you want.

You're lazy. :-)  Take your time, no need to rush.

> Currently I am testing and "playing around" with dnssec,
> dane and such stuff to learn more about it - I am not in pressure
> to implement it neither do I need it cuz' its cool or something.

That's what I'm looking for, people who take the time to do it
right, rather than rush into it half-baked as a fashion statement.

> Would be pretty interesting to see some country-statistic
> about dnssec usage.

The SMTP DANE adoption by TLD breakdown is:

 794 TOTAL
 -
 231 de
 132 net
  96 com
  80 org
  29 eu
  25 ch
  21 nl
  21 cz
  12 me
  12 dk
  11 uk
  11 fr
  10 io
   9 se
   9 info
   9 be
   8 email
   6 at
   5 is
   4 us
 ...

And many of the .net/.com/.org/.eu domains are really German domains
"in disguise".  So despite the registrar barriers, .DE is by far
the biggest early adopter.

-- 
Viktor.

Re: DANE and DLV

[James B. Byrne]

On Wed, January 7, 2015 13:54, Jean Bruenn wrote:
>
> On 07/01/15 02:07, Jim Reid wrote:
>> BTW, it's particularly unwise to adopt DLV to kludge around TLD
>> registries or registrars who can't/won't support DNSSEC properly.
>> This was the OP's rationale for going down that path. IMO the
>> OP should switch to another registrar and let the slacker
>> registrar know why they've lost the OP's business.
>
> I don't want to go offtopic but there seem to be still "many"
> registrars which do not support dnssec. I for example asked
> three different registrars in germany and got the same
> answer - they're working on it, due to the little demand
> they haven't implemented anything for that now. I am
> sure that I'll be able to find a registrar in germany with the
> same prices, a similar realtime API and dnssec support.
> Still I would not like to switch after 10+ years without any
> trouble, to another registrar - call me lazy if you want.
>

This is exactly our situation.  We presently use DLV.  I can get our
upstream registrar to manually add DS RRs for our .com, .net; and I
believe our .org tlds. But they will not do so for our principal tlds
that belong to .ca. Nonetheless, as we have many domains registered
with them, and have been using them since 2000 March 26, we are
reluctant to change providers.

CIRA's answer is to change registrars. That is the easy out, for them.
The difficulty being the administrative and financial costs of doing
so for us.

So, we await developments and in the meantime employ DLV.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: DANE and DLV

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 02:44:11PM -0500, James B. Byrne wrote:

> This is exactly our situation.  We presently use DLV.  I can get our
> upstream registrar to manually add DS RRs for our .com, .net; and I
> believe our .org tlds. But they will not do so for our principal tlds
> that belong to .ca.

Paul Wouters has a perfectly good DNSSEC .ca domain:

nohats.ca. IN MX 10 mx.nohats.ca. ; NOERROR AD=1
_25._tcp.mx.nohats.ca. IN TLSA 3 1 1 
462573195c86e861abab8eccfbc7f0486958efdff9449ac10729b3a0f906f388 ; passed

Domain name:   nohats.ca
Domain status: registered
Creation date: 2011/11/28
Expiry date:   2015/11/28
Updated date:  2014/10/30
DNSSEC:Signed

Registrar:
Name:  Tucows.com Co.

> Nonetheless, as we have many domains registered
> with them, and have been using them since 2000 March 26, we are
> reluctant to change providers.
> 
> CIRA's answer is to change registrars. That is the easy out, for them.
> The difficulty being the administrative and financial costs of doing
> so for us.
> 
> So, we await developments and in the meantime employ DLV.

The "value" of DLV is rather limited, I personally would not bother.
If you actually want DNSSEC, switch registrars.  Otherwise, wait for
yours to get on-board.

Anyway, this is somewhat off-topic for Postfix, so we should delve
into too deeply.

-- 
Viktor.

Re: DANE and DLV

[John Hascall]

I've been watching this thread with interest.

Assume I have a domain with DNSSEC and inbound mail servers behind a
(load-balanced) MX which support TLS.

If I've been following along correctly, if I publish a DNS record of the
form:

  _25._tcp.*mx.mydomain.org *. IN TLSA 3 1 1 **

this will make some (currently smallish?) set of mail servers sending to me
have a better assurance they are really talking to me.

Is this correct?

And does "*leaf public key" *refer to the public key associated with the
cert used for STARTTLS or ...something else...?


Thanks,
John



--
John Hascall 
Team Lead, Network Infrastructure, Authentication, & Directory Services
IT Services, The Iowa State University of Science and Technology

On Wed, Jan 7, 2015 at 1:12 PM, Viktor Dukhovni 
wrote:

> On Wed, Jan 07, 2015 at 07:54:03PM +0100, Jean Bruenn wrote:
>
> > I am
> > sure that I'll be able to find a registrar in germany with the
> > same prices, a similar realtime API and dnssec support.
> > Still I would not like to switch after 10+ years without any
> > trouble, to another registrar - call me lazy if you want.
>
> You're lazy. :-)  Take your time, no need to rush.
>
> > Currently I am testing and "playing around" with dnssec,
> > dane and such stuff to learn more about it - I am not in pressure
> > to implement it neither do I need it cuz' its cool or something.
>
> That's what I'm looking for, people who take the time to do it
> right, rather than rush into it half-baked as a fashion statement.
>
> > Would be pretty interesting to see some country-statistic
> > about dnssec usage.
>
> The SMTP DANE adoption by TLD breakdown is:
>
>  794 TOTAL
>  -
>  231 de
>  132 net
>   96 com
>   80 org
>   29 eu
>   25 ch
>   21 nl
>   21 cz
>   12 me
>   12 dk
>   11 uk
>   11 fr
>   10 io
>9 se
>9 info
>9 be
>8 email
>6 at
>5 is
>4 us
>  ...
>
> And many of the .net/.com/.org/.eu domains are really German domains
> "in disguise".  So despite the registrar barriers, .DE is by far
> the biggest early adopter.
>
> --
> Viktor.
>

Re: DANE and DLV

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 02:07:25PM -0600, John Hascall wrote:

> Assume I have a domain with DNSSEC and inbound mail servers behind a
> (load-balanced) MX which support TLS.

With All of the MX hosts having the same private key and certificate:

> If I've been following along correctly, if I publish a DNS record of the
> form:
> 
>   _25._tcp.mx.example.org. IN TLSA 3 1 1 * key in X.509 SPKI format>*

Or else multiple such TLSA RRs one per real MX host behind the load-balancer,
if the number of back-end hosts is reasonably small.

> this will make some (currently smallish?) set of mail servers sending to me
> have a better assurance they are really talking to me.
> Is this correct?

Yes, and definitely smallish.  Basically folks running Postfix 2.11 with:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

and a validating resolver on 127.0.0.1 as the only entry in /etc/resolv.conf

I have no count of sites that implement client-side DANE, I can
only survey the domains that publish TLSA RRs for such sites to
use.

> And does "*leaf public key" *refer to the public key associated with the
> cert used for STARTTLS or ...something else...?

The former:

printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
$(uname -n) \
$(openssl x509 -in cert.pem -noout -pubkey |
openssl pkey -pubin -outform DER |
openssl dgst -sha256 -binary |
hexdump -ve '/1 "%02x"')

-- 
Viktor.

Re: DANE and DLV

[John Hascall]

Thanks. very helpful.

One more question, though.  You say:

With All of the MX hosts having the same private key and certificate:
*(this is true for us)*
...
Or else multiple such TLSA RRs one per real MX host behind the
load-balancer,
if the number of back-end hosts is reasonably small.

*(this number is currently 9 for us)*

On what what basis would we decide between a single TLSA record for the MX
vs. individual TLSA records for each actual host?  Is it that there some
intrinsic advantage in having individual records vs. the effort of creating
N records?  Or is it something else?

Thanks again,
John



--
John Hascall 
Team Lead, Network Infrastructure, Authentication, & Directory Services
IT Services, The Iowa State University of Science and Technology

On Wed, Jan 7, 2015 at 2:16 PM, Viktor Dukhovni 
wrote:

> On Wed, Jan 07, 2015 at 02:07:25PM -0600, John Hascall wrote:
>
> > Assume I have a domain with DNSSEC and inbound mail servers behind a
> > (load-balanced) MX which support TLS.
>
> With All of the MX hosts having the same private key and certificate:
>
> > If I've been following along correctly, if I publish a DNS record of the
> > form:
> >
> >   _25._tcp.mx.example.org. IN TLSA 3 1 1 * public key in X.509 SPKI format>*
>
> Or else multiple such TLSA RRs one per real MX host behind the
> load-balancer,
> if the number of back-end hosts is reasonably small.
>
> > this will make some (currently smallish?) set of mail servers sending to
> me
> > have a better assurance they are really talking to me.
> > Is this correct?
>
> Yes, and definitely smallish.  Basically folks running Postfix 2.11 with:
>
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane
>
> and a validating resolver on 127.0.0.1 as the only entry in
> /etc/resolv.conf
>
> I have no count of sites that implement client-side DANE, I can
> only survey the domains that publish TLSA RRs for such sites to
> use.
>
> > And does "*leaf public key" *refer to the public key associated with the
> > cert used for STARTTLS or ...something else...?
>
> The former:
>
> printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
> $(uname -n) \
> $(openssl x509 -in cert.pem -noout -pubkey |
> openssl pkey -pubin -outform DER |
> openssl dgst -sha256 -binary |
> hexdump -ve '/1 "%02x"')
>
> --
> Viktor.
>

Re: DANE and DLV

[Viktor Dukhovni]

On Wed, Jan 07, 2015 at 02:29:51PM -0600, John Hascall wrote:

> On what what basis would we decide between a single TLSA record for the MX
> vs. individual TLSA records for each actual host?

Frankly, I don't see much point in load-balancers in front of
inbound port 25 MX hosts.  So I'd publish a multi-host MX RRset,
and use the load-balancer for some other protocol that needs it.

example.com. IN MX 0 mx1.example.com.
mx1.example.com. IN A 192.0.2.1
_25._tcp.mx1.example.com. IN TLSA 3 1 1 
;
example.com. IN MX 0 mx2.example.com.
mx2.example.com. IN A 192.0.2.2
_25._tcp.mx2.example.com. IN TLSA 3 1 1 
;
...
;
example.com. IN MX 0 mx9.example.com.
mx9.example.com. IN A 192.0.2.9
_25._tcp.mx9.example.com. IN TLSA 3 1 1 

> Is it that there some
> intrinsic advantage in having individual records vs. the effort of creating
> N records?  Or is it something else?

With a single key and TLSA RRset for all the MX hosts, a single
mistake breaks them all.  The load-balancer won't help.  With
separate records for each MX, and decoupled key rotation cycles,
you're much less likely to break all the MX hosts in a single
negligent act.

There is no single right answer, you consider the pros and cons.

-- 
Viktor.

ANN: The missing Cyrus SASL man pages

[Patrick Ben Koetter]

If you need to configure SMTP AUTH in Postfix you either have the choice to
use Cyrus SASL or Dovecot. Cyrus SASL is useful especially on boundary
filters, where you don't want to install Dovecot "just to get authentication".

But Cyrus SASL is a little underdocumented...

Long ago I began to write man pages for Cyrus SASL. During the recent x-mas
holidays I finally found time to finish them and put them online.

I hope they will be useful. Here's the page that links to all man pages:

https://sys4.de/de/blog/2015/01/07/missing-cyrus-sasl-man-pages/

p@rick


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 

Re: ANN: The missing Cyrus SASL man pages

[Wietse Venema]

Patrick Ben Koetter:
> If you need to configure SMTP AUTH in Postfix you either have the choice to
> use Cyrus SASL or Dovecot. Cyrus SASL is useful especially on boundary
> filters, where you don't want to install Dovecot "just to get authentication".
> 
> But Cyrus SASL is a little underdocumented...
> 
> Long ago I began to write man pages for Cyrus SASL. During the recent x-mas
> holidays I finally found time to finish them and put them online.
> 
> I hope they will be useful. Here's the page that links to all man pages:
> 
> https://sys4.de/de/blog/2015/01/07/missing-cyrus-sasl-man-pages/

Thank you, Patrick.

Wietse

max. safe value "postscreen_greet_wait"

[li...@rhsoft.net]

Hi

are there some data which value is acceptable for 
"postscreen_greet_wait" to not end in legit SMTP servers give up and try 
again later?


we see a massive botnet starting with around Dec/27 and daily deliveriy 
attempts rasied from 5000 to 5 - previously i had 10 seconds and 3 
in case of stress - after raise it for testing to 20 seconds i see *a 
lot * more HANGUP logmessages and so that connections ends in no success 
even if they would pass RBL's if the only would wait


cat maillog | grep HANGUP | grep "Jan  7" | wc -l
9883

cat maillog | grep HANGUP | grep "Jan  7 22" | wc -l
599

Re: max. safe value "postscreen_greet_wait"

[Wietse Venema]

li...@rhsoft.net:
> Hi
> 
> are there some data which value is acceptable for 
> "postscreen_greet_wait" to not end in legit SMTP servers give up and try 
> again later?

I would not recommend more than the 6-second default. Legitimate
mailing lists may operate with reduced time limits, and if a client
hangs up before postscreen_greet_wait completes, then they will
never be added to the postscreen whitelist, and therefore they will
never get a chance to deliver mail.

Wietse

> we see a massive botnet starting with around Dec/27 and daily deliveriy 
> attempts rasied from 5000 to 5 - previously i had 10 seconds and 3 
> in case of stress - after raise it for testing to 20 seconds i see *a 
> lot * more HANGUP logmessages and so that connections ends in no success 
> even if they would pass RBL's if the only would wait
> 
> cat maillog | grep HANGUP | grep "Jan  7" | wc -l
> 9883
> 
> cat maillog | grep HANGUP | grep "Jan  7 22" | wc -l
> 599
> 

Re: max. safe value "postscreen_greet_wait"

[li...@rhsoft.net]

Am 07.01.2015 um 22:38 schrieb James B. Byrne:

On Wed, January 7, 2015 16:29, li...@rhsoft.net wrote:

Hi

are there some data which value is acceptable for
"postscreen_greet_wait" to not end in legit SMTP servers give up and
try again later?


Klensin Standards Track[Page 56]

RFC 2821 Simple Mail Transfer ProtocolApril 2001

An SMTP server SHOULD have a timeout of at least 5 minutes while it
is awaiting the next command from the sender.

Of course, some admins do things differently.


thanks!

well, that's the other direction while in general the question goes more 
in the direction of practical expierience of legit 
smtp-*client*-timeouts in the wild


given that we have "postscreen_greet_ttl" the impact for legit mail is 
low *as long* the sending server don't give up the first time it needs 
to pass the tests and with around 3500-5000 legit mail each day there is 
no rush at the moment


BTW: mailgraph in the meantime shows a *dramatical* breakdown in 
delivery attemts from the moment of the config change

Re: max. safe value "postscreen_greet_wait"

[li...@rhsoft.net]

Am 07.01.2015 um 22:46 schrieb Wietse Venema:

li...@rhsoft.net:

Hi

are there some data which value is acceptable for
"postscreen_greet_wait" to not end in legit SMTP servers give up and try
again later?


I would not recommend more than the 6-second default. Legitimate
mailing lists may operate with reduced time limits, and if a client
hangs up before postscreen_greet_wait completes, then they will
never be added to the postscreen whitelist, and therefore they will
never get a chance to deliver mail.


hmm - we had now 10 sceonds for around 4 months
the config change was at 22:03:27

see what happens after that in the logs

Jan  7 22:02:14 mail-gw postfix/postscreen[12964]: HANGUP after 1.7 from 
[72.46.131.60]:50792 in tests after SMTP handshake
Jan  7 22:02:39 mail-gw postfix/postscreen[12964]: HANGUP after 0.25 
from [212.178.231.68]:4764 in tests after SMTP handshake
Jan  7 22:03:32 mail-gw postfix/postscreen[24091]: HANGUP after 0.02 
from [37.133.75.151]:50523 in tests after SMTP handshake
Jan  7 22:03:40 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[62.81.35.228]:2316 in tests before SMTP handshake
Jan  7 22:03:42 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[181.135.235.24]:62334 in tests before SMTP handshake
Jan  7 22:03:45 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[177.227.247.188]:56905 in tests before SMTP handshake
Jan  7 22:03:47 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[189.210.83.109]:61984 in tests before SMTP handshake
Jan  7 22:03:52 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[177.44.232.137]:3258 in tests before SMTP handshake
Jan  7 22:03:57 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[190.145.73.125]:2082 in tests before SMTP handshake
Jan  7 22:03:58 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[77.229.146.142]:53130 in tests before SMTP handshake
Jan  7 22:03:59 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[103.230.222.254]:65419 in tests before SMTP handshake
Jan  7 22:04:02 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[68.190.82.102]:1292 in tests before SMTP handshake
Jan  7 22:04:02 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[186.177.165.79]:26934 in tests before SMTP handshake
Jan  7 22:04:09 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[91.142.239.39]:58970 in tests before SMTP handshake
Jan  7 22:04:09 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[190.105.11.33]:51718 in tests before SMTP handshake
Jan  7 22:04:11 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[84.117.84.132]:57652 in tests before SMTP handshake
Jan  7 22:04:16 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[85.185.130.200]:15881 in tests before SMTP handshake
Jan  7 22:04:16 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[46.55.180.30]:62846 in tests before SMTP handshake
Jan  7 22:04:23 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[177.224.47.142]:58340 in tests before SMTP handshake
Jan  7 22:04:24 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[179.26.157.236]:55688 in tests before SMTP handshake
Jan  7 22:04:25 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[190.234.180.62]:15160 in tests before SMTP handshake
Jan  7 22:04:27 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[187.175.118.96]:24833 in tests before SMTP handshake
Jan  7 22:04:29 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[190.50.122.76]:61259 in tests before SMTP handshake
Jan  7 22:04:33 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[201.249.150.185]:22216 in tests before SMTP handshake
Jan  7 22:04:36 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[85.11.184.57]:3806 in tests before SMTP handshake
Jan  7 22:04:36 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[46.115.141.89]:56896 in tests before SMTP handshake
Jan  7 22:04:36 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[207.93.5.242]:57103 in tests before SMTP handshake
Jan  7 22:04:37 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[46.25.158.137]:55404 in tests before SMTP handshake
Jan  7 22:04:40 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[179.8.145.167]:10762 in tests before SMTP handshake
Jan  7 22:04:41 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[59.176.33.96]:18862 in tests before SMTP handshake
Jan  7 22:04:43 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[111.249.240.79]:56872 in tests before SMTP handshake
Jan  7 22:04:46 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[189.197.5.244]:3474 in tests before SMTP handshake
Jan  7 22:04:47 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[81.137.54.144]:35212 in tests before SMTP handshake
Jan  7 22:04:49 mail-gw postfix/postscreen[24097]: HANGUP after 11 from 
[80.149.55.65]:3499 in tests before SMTP handshake
Jan  7 22:04:51 mail-gw postfix/postscreen[24097]: HANGUP after 11 from

Re: Yet another relay access denied problem

[Jonathan Hermann]

You're right, I'm not the big mail server expert. And sometimes I pose 
basic questions. But I'm asking since I want functionality AND security 
to work. No-one likes spam. So thanks to those who provided valuable 
input I was able to achieve both, according to several open mail relay 
tests (from mailradar and others).


Thanks again :)


Am 31.12.2014 um 09:33 schrieb Thom Miller:


On 12/31/2014 12:49 AM, li...@rhsoft.net wrote:

Am 31.12.2014 um 05:58 schrieb Thom Miller:

On 12/30/2014 09:35 PM, Jonathan Hermann wrote:

Ok, then it's by design. So spamassassin/amavis will have to do.

don't get me wrong but re-consider setup a complex, public reachable
mailserver without have *basic* understanding how email works at all

otherwise you would not wonder that gmail, hotmail and all the others
don't need the auth credentials of each and every user to send him his
mails from their users


Am 28.12.2014 um 21:50 schrieb Wietse Venema:

Jonathan Hermann:

I can send mail from an external source (e.g. mail client on my
notebook) to a local user (local on my mailserver) without
authentication. I'm not sure, is this by design?

By default, *any* system can send mail to a local address. Postfix
normally requires client authentication only when a client wants
to send mail to a remote address.


If you don't want to receive any mail from other mail servers to your
postfix, you could blacklist all ips with postscreen
http://www.postfix.org/postscreen.8.html and make your authenticated
connections to port 587 with Thunderbird or whatever clients you choose.

Not certain if that's what you're looking for but I get the impression
you do not expect incoming mail to Postfix

uhm if you don't want to receive from outside then just don't open port
25 in the firewall or even remove the smtp line from master.cf so that
postfix even don't listen on port 25 - but for no vali dreason start to
configure postscreen

or just require auth in main.cf globally

smtpd_recipient_restrictions = permit_mynetworks
  reject_non_fqdn_recipient
  reject_non_fqdn_sender
  reject_unlisted_sender
  reject_authenticated_sender_login_mismatch
  permit_sasl_authenticated
  reject


I think your solution is much easier, but since he's using Fetchmail
which I believe uses SMTP to talk to his mail server, he'll need to
leave the smtp line in master.cf. Blocking 25 at the firewall is fine.
Requiring auth on 25 would require Fetchmail to be configured to
authenticate to forward what it brings in, which I'm sure it can do.

Postscreen only came to mind as a first thought because I was actively
making changes to it right before I read the message. Blocking at the
firewall is probably the best choice.

-Thom

Re: DANE and DLV

[John Allen]

On 07/01/2015 3:02 PM, Viktor Dukhovni wrote:

On Wed, Jan 07, 2015 at 02:44:11PM -0500, James B. Byrne wrote:


This is exactly our situation.  We presently use DLV.  I can get our
upstream registrar to manually add DS RRs for our .com, .net; and I
believe our .org tlds. But they will not do so for our principal tlds
that belong to .ca.

Paul Wouters has a perfectly good DNSSEC .ca domain:

 nohats.ca. IN MX 10 mx.nohats.ca. ; NOERROR AD=1
 _25._tcp.mx.nohats.ca. IN TLSA 3 1 1 
462573195c86e861abab8eccfbc7f0486958efdff9449ac10729b3a0f906f388 ; passed

 Domain name:   nohats.ca
 Domain status: registered
 Creation date: 2011/11/28
 Expiry date:   2015/11/28
 Updated date:  2014/10/30
 DNSSEC:Signed

 Registrar:
Name:  Tucows.com Co.


Nonetheless, as we have many domains registered
with them, and have been using them since 2000 March 26, we are
reluctant to change providers.

CIRA's answer is to change registrars. That is the easy out, for them.
The difficulty being the administrative and financial costs of doing
so for us.

So, we await developments and in the meantime employ DLV.
I had the same problem, my domain klam.ca (the family site which I use 
for experimenting) was registered with Tucows who could not, would not 
provide DNSSEC support for .ca.  I switched to Gandi for all my domains 
the cost was reasonable and the provide a usable DNSSEC update console.

The "value" of DLV is rather limited, I personally would not bother.
If you actually want DNSSEC, switch registrars.  Otherwise, wait for
yours to get on-board.

Anyway, this is somewhat off-topic for Postfix, so we should delve
into too deeply.

limiting the _occassional_ burst of connections from a bad actor?

[rogt3654]

Hi

What's the correct method in Postfix for preventing this sort of connection 
burst (log below)?

I can sure deal with it AFTER the fact.  But I'm looking for the best way to 
shut it down asap WHILE it's happening, and then prevent from happening again.

I found this section

  http://www.postfix.org/TUNING_README.html#conn_limit

which suggests 'anvil' but it makes a point: "IMPORTANT: These limits must not 
be used to regulate legitimate traffic: mail will suffer grotesque delays if 
you do so. The limits are designed to protect the smtpd(8) server against abuse 
by out-of-control clients."

That seems to say NOT to tweak the settings to generally prevent this but to 
use it after the fact (NOt sure yet how you make it pay attention to specific 
IPs).  Maybe I'm misunderstanding it.  

Just looking for some experience on setting this sort of protection up, and I 
don't want to end up misusing anvil.

Advice?

Rog


log
...
Jan  5 07:23:26 mail postfix/smtpd[31817]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:31 mail postfix/smtpd[31817]: disconnect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:33 mail postfix/smtpd[31817]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:34 mail postfix/smtpd[31826]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31827]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31829]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31830]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31831]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31832]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31833]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31834]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31835]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:36 mail postfix/smtpd[31836]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:37 mail postfix/smtpd[31837]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:37 mail postfix/smtpd[31838]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:38 mail postfix/smtpd[31839]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:38 mail postfix/smtpd[31840]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:39 mail postfix/smtpd[31841]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:39 mail postfix/smtpd[31842]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:39 mail postfix/smtpd[31843]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31844]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31845]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31846]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31847]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31848]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31849]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31850]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:40 mail postfix/smtpd[31851]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31852]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31853]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31854]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31855]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31856]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31857]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix/smtpd[31858]: connect from 
188-220-27-72-br2-STATIC-dsl.cwjamaica.com[72.27.220.188]
Jan  5 07:23:41 mail postfix

Re: limiting the _occassional_ burst of connections from a bad actor?

[Noel Jones]

On 1/7/2015 10:09 PM, rogt3...@proinbox.com wrote:
> Hi
> 
> What's the correct method in Postfix for preventing this sort of connection 
> burst (log below)?
> 
> I can sure deal with it AFTER the fact.  But I'm looking for the best way to 
> shut it down asap WHILE it's happening, and then prevent from happening again.
> 
> I found this section
> 
>   http://www.postfix.org/TUNING_README.html#conn_limit
> 
> which suggests 'anvil' but it makes a point: "IMPORTANT: These limits must 
> not be used to regulate legitimate traffic: mail will suffer grotesque delays 
> if you do so. The limits are designed to protect the smtpd(8) server against 
> abuse by out-of-control clients."
> 
> That seems to say NOT to tweak the settings to generally prevent this but to 
> use it after the fact (NOt sure yet how you make it pay attention to specific 
> IPs).  Maybe I'm misunderstanding it.  
> 
> Just looking for some experience on setting this sort of protection up, and I 
> don't want to end up misusing anvil.

Feel free to adjust the anvil settings to something appropriate for
your site.  The anvil settings you use should be high enough that
legit servers never trigger the limit.  We can't give you much
guidance on what numbers are appropriate for your site.

Some people try to use anvil for traffic shaping, or limiting
normal/legit traffic. Don't do that.   Do review your logs to make
sure legit servers aren't being slowed by anvil -- if they are,
raise your limits.

Looks as if this particular client mostly just connected and then
disconnected after a few seconds.  This in itself is not
particularly harmful, as long as there aren't enough connections to
use up all your smtpd processes.

Consider enabling the postscreen service to help weed out bots
before they can connect to the real smtpd service.
http://www.postfix.org/POSTSCREEN_README.html

I also notice this client sent the AUTH command a few times, but
apparently didn't stay connected long enough to actually try sending
credentials.  You can use fail2ban or similar to temporarily
firewall clients that try to AUTH but fail several times.  Be
generous in your limits so you don't lock out legit users who have a
config problem.




  -- Noel Jones

dkim-milter for postfix

[Selcuk Yazar]

Hi,

i try to implement dkim signature our server postfix (2.6.6)

my dkim-filter config is like this

prog path /usr/sbin/dkim-filter
configuration parameters

# To sign only, use -bs
# EXTRA_FLAGS=-bs
USER=dkim-milter
PORT=inet:20209@localhost
SIGNING_DOMAIN="domain"
SELECTOR_NAME="m1"
KEYFILE="/etc/postfix/dkim/domain._m1.key.pem"
SIGNER=yes
VERIFIER=yes
CANON=simple
SIGALG=rsa-sha1
REJECTION="bad=r,dns=t,int=t,no=a"
EXTRA_ARGS="-h -l -D"

also i add main cf.

smtpd_milters = inet:localhost:20209
non_smtpd_milters = $smtpd_milters
milter_protocol = 6
milter_default_action = accept


when i send email to gmail with these values , i can see signed by domain
tag in gmail. but mails in queue gives error like below. ( line number
change reletavily i think)


Temporary MTA failure on relaying, From MTA() during fwd-connect (Negative
greeting:  at (eval 110) line 464,  line 389171.)

after that i added no_milters value in master.cf 127.0.0.1:10025 inet -o
receive_override_options section but this time signed by domain tag is lost.

thanks in advance

-- 
Selçuk YAZAR