Re: procmail as a content_filter with dovecot under postfix

[Viktor Dukhovni]

On Mon, Nov 09, 2015 at 11:02:21PM -0800, Vicki Brown wrote:

> I am using Mac OS X Server. OS X Server uses postfix with dovecot set as 
> mail_transport.
> 
> I want to add procmail to the mix. I cannot use the (typical)
> mailbox_command = procmail -a "$EXTENSION"
> 
> because
> mailbox_transport = dovecot
> 
> overrides any mailbox_command parameter and it is NOT Possible to change, 
> remove, or otherwise vary the
> mailbox_transport on OS X server.
> 
> I'm thinking I should be able to set up a content_filter for procmail,
> but I've found nothing online to tell me if this is possible or how to
> declare it.

With a great deal of care it may well be possible to configure
procmail as a "simple" content_filter (shared by all users and
running as some system account), that reinjects mail back into the
Postfix queue for delivery.  In practice, I think this is unwise,
and would not recommend it.  This is not what procmail is designed
to do.

-- 
Viktor.

Re: TLSA and .mil dns servers

[Phil Stracchino]

On 11/10/15 08:15, Alice Wonder wrote:
> 
> On 11/10/2015 04:30 AM, Phil Stracchino wrote:
>> This is where I admit that I haven't gotten around to DNSSEC signing
>> yet.  But then, mine is a very small domain with only one external IP.
>>
>>
> 
>  From my own personal experience, start with a very short TTL and do not 
> make TLSA records until you have a process down for rotating zone 
> signing keys that works.
[...]
> My DNS servers do DNSSEC validate so I at least get some MITM protection 
> even without postfix running in DANE mode.

I'm not even ready to look at TLSA yet.  I'm actually still working on
finishing up my DKIM setup.  Does anyone have a favorite preferred
information resource for a how-to on getting started with DNSSEC?


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

Re: TLSA and .mil dns servers

[Benny Pedersen]

Phil Stracchino skrev den 2015-11-10 16:51:


I'm not even ready to look at TLSA yet.  I'm actually still working on
finishing up my DKIM setup.  Does anyone have a favorite preferred
information resource for a how-to on getting started with DNSSEC?


here is my story on DNSSEC

when i used junc.org for email it was not possible to have the DS record 
added to registra holder, api missed, so i got the advise from my dns 
server admins to get a eu tld domain, so i got junc.eu, this domain was 
DNSSEC at that stage without doing anything


summary up, it depends on tld, and how much work the selected dns server 
does for domain owners


test points:

dig +trace junc.org
dig +trace junc.eu

https://dane.sys4.de/smtp/junc.org

still learning by reading here

Re: TLSA and .mil dns servers

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 05:15:43AM -0800, Alice Wonder wrote:

> From my own personal experience, start with a very short TTL and do not make
> TLSA records until you have a process down for rotating zone signing keys
> that works.
> 
> I currently use a one hour TTL and I do not feel a need to ever increase
> that, but when I first started playing with DNSSEC I used a 5 minute TTL so
> that when I made mistakes the impact was short.

Yes, keep TTLs sensibly short, and for most (small) sites, 1 hour
seems about right for long-term use.  

Keep in mind that the TTL on the DS (delegation signer) records
published by the parent zone is out of your control and is typically
longer, so changes to DS records must be made with great care.  At
all times, each and every unexpired DS record in some remote cache
must match a corresponding DNSKEY record in your DNSKEY RRset
(whether fresh or cached, obtained from a primary or a slave server).

The upshot is that each DNSKEY record must have been published
sufficiently long before the publication of the corresponding DS
record for any older cached or slaved DNSKEY RRsets to expire, and
must not be deleted until after the corresponding DS record has
been deleted and has expired from all caches.

> Even though all but one of my TLS certificates are signed by a CA, I always
> specify them as Type 3 in the TLSA record, not Type 1, even for https.

That keeps things simpler for verifiers, but note that for SMTP
the choice is between DANE-EE(3) and DANE-TA(2), RFC7672 (DANE for
SMTP) excludes the PKIX-EE(1) and PKIX-TA(0) usages.

> I now am of the opinion that Type 0/1 TLSA records should be depricated as
> there is not, at least to me, a real world value to them. But I am not an
> expert in that area.

There can be limited value to them in applications that only accept
these and do not accept DANE-EE(3) or DANE-TA(2).

https://tools.ietf.org/html/rfc7671#section-4

> Myself, I have TLSA records for my two mail servers, both very low volume,
> but I do not yet run postfix in DANE mode. Soon I will start doing that, but
> I'm waiting for increased DANE adoption and watching for issues, like the
> .mil issue that started this thread, before I take that step.

My advice is to stop waiting.  The problem domains are few, and
for most people not ones that you're likely to send mail to.

> My DNS servers do DNSSEC validate so I at least get some MITM protection
> even without postfix running in DANE mode.

There are more domains with expired RRsigs that become unreachable
due to DNSSEC operational issues than domains with TLSA lookup or
correctness issues.  The ones with persistent issues are also not
"high visibility" domains that you're liable to ever encounter.

DNSSEC protects you from using the wrong MX hostname, or the wrong
IP address, but not from BGP route or on-path wiretap MiTM attacks
that downgrade STARTTLS or do MiTM TLS (easy since opportunistic
TLS for SMTP cannot enforce certificate verification).

-- 
Viktor.

Re: receiving message - checking mx record by postfix

[Noel Jones]

On 11/10/2015 6:29 AM, Zalezny Niezalezny wrote:
> Dear Colleagues, 
> 
> I would like to understand how Postfix receiving message. I expect
> that Postfix has been written base on the RFC rules so maybe
> somebody will be able to explain me how its working inside - how
> this system receiving message and what is going on in the background.
> 
> Our consultant hardly trying to tell us that server during receiving
> phase checking MX record of the domain from which coming the E-mail.
> Does it really working this way ? I always thought that Postfix
> checking first DNS A record (reverse dns), then SPF etc.etc.
> 
> I always thought that MX record is provide clear information about
> the servers to which client needs to send a message. But right now
> I`m completly out of space...
> 
> 
> Does system check mx record when its receiving message or not ?
> 
> 
> Do You know where may I find RFC which fully describing this SMTP
> process ?
> 
> 
> 
> With kind regards
> 
> Zalezny
> 
> 
> 


RFC5321 describes the mechanics of SMTP.

There is no requirement for the receiver to lookup the MX of the
sender domain, but it might be done as part of anti-spam controls.

Postfix MAY lookup the MX of the sender if you've configured
anti-spam controls such as reject_unknown_sender_domain or add-on
software such as an SPF checker.

In particular, there is no requirement that the MX of the sender's
domain match the sending client IP, and they often don't match.



  -- Noel Jones

Re: TLSA and .mil dns servers

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 05:00:03PM +0100, Benny Pedersen wrote:

> Here is my story on DNSSEC

This is but an anecdote, let's not promulgate too many of those...

> When I used junc.org for email it was not possible to have the DS record
> added to registra holder, api missed, so i got the advise from my dns server
> admins to get a eu tld domain, so i got junc.eu, this domain was DNSSEC at
> that stage without doing anything

All the original gTLD domains (edu, gov, mil, org, net, com) are
signed.  With signed TLDs what matters is the choice registrar.
If your current registrar does not support DNSSEC, you can generally
find another that does.

All new gTLDs created under the recent gTLD expansion are signed.
At this time, the unsigned TLDs are 142 of the 247 two-letter ccTLDs:

ae.  ai.  al.  ao.  aq.  as.  ax.  az.  ba.  bb.  bd.  bf.  bh.
bi.  bj.  bm.  bn.  bo.  bs.  bt.  bv.  bw.  cd.  cf.  cg.  ci.
ck.  cm.  cu.  cv.  cw.  cy.  dj.  dm.  do.  dz.  ec.  eg.  er.
et.  fj.  fk.  fm.  ga.  gb.  ge.  gf.  gg.  gh.  gm.  gp.  gq.
gt.  gu.  gw.  gy.  hk.  hm.  ht.  il.  im.  iq.  ir.  it.  je.
jm.  jo.  kh.  km.  kn.  kp.  kw.  kz.  lr.  ls.  ly.  ma.  mc.
md.  mg.  mh.  mk.  ml.  mo.  mp.  mq.  mr.  ms.  mt.  mu.  mv.
mw.  mz.  ne.  ng.  ni.  np.  nr.  om.  pa.  pf.  pg.  ph.  pk.
pn.  ps.  py.  qa.  ro.  rs.  rw.  sa.  sd.  sg.  sk.  sl.  sm.
sn.  so.  sr.  st.  sv.  sy.  sz.  tc.  td.  tg.  tj.  tk.  to.
tr.  uz.  va.  vc.  ve.  vg.  vi.  vn.  ws.  ye.  za.  zw.

and the below:

aero.xn--d1alf.   xn--mgbpl2fh.
coop.xn--fzc2c9e2c.   xn--mgbtx2b.
int. xn--j1amh.   xn--node.
mobi.xn--j6w193g. xn--ogbpf8fl.
pro. xn--lgbbat1ad8j. xn--qxam.
tel. xn--mgb9awbf.xn--wgbl6a.
travel.  xn--mgba3a4f16a. xn--xkc2al3hye2a.
xn--80ao21a. xn--mgbaam7a8h.  xn--yfro4i67o.
xn--90a3ac.  xn--mgbayh7gpa.  xn--ygbi2ammx.
xn--90ais.   xn--mgbc0a9azcg.
xn--clchc0ea0b2g2a9gcd.  xn--mgberp4a5d4ar.

There are 106 IDNA (xn--punycode encoded UTF-8) TLDs, of which 82
are signed and 24 are not.  There are 1103 TLDS in total, of which
930 are signed and 173 are not.  So mostly the laggards are the
ccTLDs.  (At least there's something that ".il", ".ir" and ".sa"
appear to agree on.  Just a joke, no political sub-thread please).

> Summary, it depends on the tld, and how much work the selected dns server
> does for domain owners

Yes, the TLD needs to be signed, but most are.  Choose the right
registrar.

The real obstacle to DNSSEC deployment is coming to grips wit the
tools (which are still improving).  I use BIND's:

auto-dnssec maintain;
inline-signing yes;

in an authoritative-only server.  And I have a monitoring script
that makes noise any time a secondary or master has RRSIGs too
close to expiration, NS records that don't match the parent
delegation, ...

-- 
Viktor.

Re: receiving message - checking mx record by postfix

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 01:29:43PM +0100, Zalezny Niezalezny wrote:

> I would like to understand how Postfix receiving message. I expect that
> Postfix has been written base on the RFC rules so maybe somebody will be
> able to explain me how its working inside - how this system receiving
> message and what is going on in the background.

You need to ask a more concrete question.  It is unlikely that
anyone will post a comprehensive architecture overview of Postfix,
or a detailed walk-through of the multiple relevant email RFCs.

You can read the Postfix book by Patrick Koetter and Ralf Hildebrandt,
and the multiple documents at: .

http://www.postfix.org/OVERVIEW.html
http://www.postfix.org/SMTPD_ACCESS_README.html
http://www.postfix.org/postfix-manuals.html
http://www.postfix.org/smtpd.8.html

> Our consultant hardly trying to tell us that server during receiving phase
> checking MX record of the domain from which coming the E-mail. Does it
> really working this way ? I always thought that Postfix checking first DNS
> A record (reverse dns), then SPF etc.etc.

If you're having a problem receiving mail, post the relevant logs and
information about your configuration as described in:

http://www.postfix.org/DEBUG_README.html#mail

and explained in the Welcome message you received when you joined
the list.

> Does system check mx record when its receiving message or not?

Only if you configure Postfix to do that, directly or indirectly.

> Do You know where may I find RFC which fully describing this SMTP process?

There is no single RFC that describes everything SMTP servers do
behind the scenes when receiving messages, even the entire collection
of email-related RFCs is properly silent on many implementation-specific
and local policy issues.

http://www.faqs.org/rfcs/np.html#SMTP
http://www.faqs.org/rfcs/np.html#Other

-- 
Viktor.

Re: receiving message - checking mx record by postfix

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 09:29:19PM +0100, Zalezny Niezalezny wrote:

> We have two systems which are dedicated only to send E-mails.  Mostly for
> massmailing.  These two machines will not receive any E-mails.  

Don't confuse "systems" (SMTP servers) with email domains (the
domain part of an rfc822 email address).  Your *systems* do not
need MX records.  They just need FQDN hostnames, and their IP
addresses need to a PTR record that provides each system's hostname.

Nor do the MX records of the envelope sender domain of the message
being sent need to point at the sending systems.  It is not unusual
to have separate systems sending and receiving mail.

> Do we realy
> need to configure MX records for that systems if they are not receiving any
> E-mails?

No MX records are required for your *systems* (SMTP servers).

> From my point of view checking MX record from the client which
> sending message is ... strange... if not stupid... In the SPF record we can
> have a lot of systems which are not necesserly configured in the MX record.

If you have SPF records for the envelope sender domain, then the
sending IP addresses should be listed there.  In any case the
envelope sender domain need to resolve to a set of valid public
addresses or a set of MX hosts with valid public addresses.

--
Viktor.

Re: receiving message - checking mx record by postfix

[Zalezny Niezalezny]

Thank You for all previous answers.


We have two systems which are dedicated only to send E-mails. Mostly for
massmailing. These two machines will not receive any E-mails. Do we realy
need to configure MX records for that systems if they are not receiving any
E-mails ? From my point of view checking MX record from the client which
sending message is ... strange... if not stupid... In the SPF record we can
have a lot of systems which are not necesserly configured in the MX record.
Does it realy make sense ?



On Tue, Nov 10, 2015 at 6:32 PM, Viktor Dukhovni  wrote:

> On Tue, Nov 10, 2015 at 01:29:43PM +0100, Zalezny Niezalezny wrote:
>
> > I would like to understand how Postfix receiving message. I expect that
> > Postfix has been written base on the RFC rules so maybe somebody will be
> > able to explain me how its working inside - how this system receiving
> > message and what is going on in the background.
>
> You need to ask a more concrete question.  It is unlikely that
> anyone will post a comprehensive architecture overview of Postfix,
> or a detailed walk-through of the multiple relevant email RFCs.
>
> You can read the Postfix book by Patrick Koetter and Ralf Hildebrandt,
> and the multiple documents at:  >.
>
> http://www.postfix.org/OVERVIEW.html
> http://www.postfix.org/SMTPD_ACCESS_README.html
> http://www.postfix.org/postfix-manuals.html
> http://www.postfix.org/smtpd.8.html
>
> > Our consultant hardly trying to tell us that server during receiving
> phase
> > checking MX record of the domain from which coming the E-mail. Does it
> > really working this way ? I always thought that Postfix checking first
> DNS
> > A record (reverse dns), then SPF etc.etc.
>
> If you're having a problem receiving mail, post the relevant logs and
> information about your configuration as described in:
>
> http://www.postfix.org/DEBUG_README.html#mail
>
> and explained in the Welcome message you received when you joined
> the list.
>
> > Does system check mx record when its receiving message or not?
>
> Only if you configure Postfix to do that, directly or indirectly.
>
> > Do You know where may I find RFC which fully describing this SMTP
> process?
>
> There is no single RFC that describes everything SMTP servers do
> behind the scenes when receiving messages, even the entire collection
> of email-related RFCs is properly silent on many implementation-specific
> and local policy issues.
>
> http://www.faqs.org/rfcs/np.html#SMTP
> http://www.faqs.org/rfcs/np.html#Other
>
> --
> Viktor.
>

Re: Throttling locally generated email

[Donald Bindner]

Yes, the point of my email is that I researched and tried to apply
exactly this configuration, but it did not work.  The
smtpd_recipient_restrictions rule they suggest does not appear to
apply to messages that originate on the server.  Or at least making
that single configuration does not have that effect.  I can verify
that emails originating on the server do not access the policy server
running on port 10040.

Don

On Tue, Nov 10, 2015 at 4:53 PM, Curtis Maurand  wrote:
> And this.
>
> http://serverfault.com/questions/290684/postfix-limiting-the-rate-at-which-a-particular-user-can-send-email
>
> --Curtis

Re: Throttling locally generated email

[Curtis Maurand]

Hello,

I found this link that might be helpful.

http://steam.io/2013/04/01/postfix-rate-limiting/

Cheers,
Curtis

On 11/10/2015 5:42 PM, Donald Bindner wrote:

I've been searching for some time, and what I want seems to be fairly
obscure, because I haven't found clear examples of it (at least I
don't think I have).

I run an Ubuntu server with user accounts, and we use a limited amount
of email on it, which we process with Postfix.  On occasion, a user
will succumb to a phishing attack and their password will get out.
Then a spammer will use that valid account to send a lot of emails.
Naturally this gets caught fairly quickly, the account is suspended,
and so on.

Since we do such a limited amount of email with this server, it would
be nice if I could limit local accounts to, say, 100 originated emails
per day (or 1000 or whatever).  That just keeps the flood smaller
while we respond to it.  It seems that a policy server like postfwd is
the usual way to do something like this, and usually I see examples
suggesting a main.cf rule like:

smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040

However, this kind of rule seems to run only for mail "passing
through" my Postfix server and not for mail originating locally.  In
any event, the service running on port 10040 does not receive
connections from Postfix for mail that is generated locally.

I'd love if someone would show an example that "hooks this up."  I'm
confident that I have postfwd configured correctly to listen on port
10040, I just need Postfix to talk to it.

Don


--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: Throttling locally generated email

[Ken Simpson]

Hi Donald,

Chances are, the problem you're trying to solve (throttling users) is
actually a symptom of the larger problem of runaway spamming accounts. Am I
right? In this case, throttling users with policyd and a relatively
straightforward policyd script is a good option to stem the bleeding. But
you may need to also invest time/resources tracking down and solving the
cause of the excessive volume, such as compromised WordPress scripts or
user accounts.

Ken

On Tue, Nov 10, 2015 at 3:37 PM, Donald Bindner  wrote:

> Yes, the point of my email is that I researched and tried to apply
> exactly this configuration, but it did not work.  The
> smtpd_recipient_restrictions rule they suggest does not appear to
> apply to messages that originate on the server.  Or at least making
> that single configuration does not have that effect.  I can verify
> that emails originating on the server do not access the policy server
> running on port 10040.
>
> Don
>
> On Tue, Nov 10, 2015 at 4:53 PM, Curtis Maurand 
> wrote:
> > And this.
> >
> >
> http://serverfault.com/questions/290684/postfix-limiting-the-rate-at-which-a-particular-user-can-send-email
> >
> > --Curtis
>

RE: receiving message - checking mx record by postfix

[L . P . H . van Belle]

Read :  http://www.sorbs.net/faq/rfc_helo_enforcement.shtml  

I contains also the links to the RFC’s 

 

Greetz, 

 

Louis

 

 

 


Van: zalezny.niezale...@gmail.com [mailto:owner-postfix-us...@postfix.org] 
Namens Zalezny Niezalezny
Verzonden: dinsdag 10 november 2015 13:30
Aan: Postfix users
Onderwerp: receiving message - checking mx record by postfix


 

Dear Colleagues, 

 


I would like to understand how Postfix receiving message. I expect that Postfix 
has been written base on the RFC rules so maybe somebody will be able to 
explain me how its working inside - how this system receiving message and what 
is going on in the background.


 


Our consultant hardly trying to tell us that server during receiving phase 
checking MX record of the domain from which coming the E-mail. Does it really 
working this way ? I always thought that Postfix checking first DNS A record 
(reverse dns), then SPF etc.etc.


 


I always thought that MX record is provide clear information about the servers 
to which client needs to send a message. But right now I`m completly out of 
space...


 


 


Does system check mx record when its receiving message or not ?


 


 


Do You know where may I find RFC which fully describing this SMTP process ?


 


 


 


With kind regards


 


Zalezny


 


 


 

Re: procmail as a content_filter with dovecot under postfix

[Vicki Brown]

I'm sorry but that confused me even more.

I useprocmail to filter content. That's all I've ever used it for.
I send mail through Spamassassin, add some headers, and delete high-scoring 
spam. All in /etc/procmailrc.

That's content filtering.

That's not mail delivery.

Dovecot is doing the delivery.


> On Nov 10, 2015, at 16:48, Viktor Dukhovni  wrote:
> 
> On Tue, Nov 10, 2015 at 04:30:55PM -0800, Vicki Brown wrote:
> 
>> Can you elaborate a bit on why this would be unwise?
>> 
>> All procmail is doing right now (for me) is acting as a content filter, 
>> shared by all users and running suid...
>> It hands the messages off to Dovecot for delivery.
>> 
>> I don't see the difference in doing this from a content_filter perspective.
>> 
>> What am I missing (aside form efficiency of process)?
> 
> Procmail is not designed to understand how to handle multi-recipient
> mail, preserve envelope sender information, or even handle recipients
> that are not system users.
> 
> It is not a content-filter, it is local delivery agent with knobs.
> 
> -- 
>   Viktor.

-- Vicki
  cfcl.com/vlb
  twitter.com/vlb

Re: procmail as a content_filter with dovecot under postfix

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 04:30:55PM -0800, Vicki Brown wrote:

> Can you elaborate a bit on why this would be unwise?
> 
> All procmail is doing right now (for me) is acting as a content filter, 
> shared by all users and running suid...
> It hands the messages off to Dovecot for delivery.
> 
> I don't see the difference in doing this from a content_filter perspective.
> 
> What am I missing (aside form efficiency of process)?

Procmail is not designed to understand how to handle multi-recipient
mail, preserve envelope sender information, or even handle recipients
that are not system users.

It is not a content-filter, it is local delivery agent with knobs.

-- 
Viktor.

Re: Throttling locally generated email

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 04:42:32PM -0600, Donald Bindner wrote:

> smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
> 
> However, this kind of rule seems to run only for mail "passing
> through" my Postfix server and not for mail originating locally.  In
> any event, the service running on port 10040 does not receive
> connections from Postfix for mail that is generated locally.
> 
> I'd love if someone would show an example that "hooks this up."  I'm
> confident that I have postfwd configured correctly to listen on port
> 10040, I just need Postfix to talk to it.

It is not possible to rate-limit local submission.  This is because
local submission must be possible even with the mail system not
running, so all it entails is direct writing of a queue file into
the "maildrop" directory.

If you want rate limits any legitimate sending agent needs to have
the ability to delay and retry mail (an "Outbox" if you like), and
while MUAs like Thunderbird that submit via SMTP can do that, the
command-line sendmail(1) program cannot.

What you can do is deny access to local submission, and require
all mail be submitted via SMTP.  This can make notification from
cron jobs a bit difficult, but if such mail is sent by a system
account to the user, you can allow local submission to just that
account (and a few others).

-- 
Viktor.

Re: procmail as a content_filter with dovecot under postfix

[Vicki Brown]

Can you elaborate a bit on why this would be unwise?

All procmail is doing right now (for me) is acting as a content filter, shared 
by all users and running suid...
It hands the messages off to Dovecot for delivery.

I don't see the difference in doing this from a content_filter perspective.

What am I missing (aside form efficiency of process)?


> On Nov 10, 2015, at 07:41, Viktor Dukhovni  wrote:
> 
> On Mon, Nov 09, 2015 at 11:02:21PM -0800, Vicki Brown wrote:
> 
>> I am using Mac OS X Server. OS X Server uses postfix with dovecot set as 
>> mail_transport.
>> 
>> I want to add procmail to the mix. I cannot use the (typical)
>>mailbox_command = procmail -a "$EXTENSION"
>> 
>> because
>>mailbox_transport = dovecot
>> 
>> overrides any mailbox_command parameter and it is NOT Possible to change, 
>> remove, or otherwise vary the
>> mailbox_transport on OS X server.
>> 
>> I'm thinking I should be able to set up a content_filter for procmail,
>> but I've found nothing online to tell me if this is possible or how to
>> declare it.
> 
> With a great deal of care it may well be possible to configure
> procmail as a "simple" content_filter (shared by all users and
> running as some system account), that reinjects mail back into the
> Postfix queue for delivery.  In practice, I think this is unwise,
> and would not recommend it.  This is not what procmail is designed
> to do.
> 
> -- 
>   Viktor.

-- Vicki
  cfcl.com/vlb
  twitter.com/vlb

Re: Throttling locally generated email

[Donald Bindner]

Yes, of course it's about stemming the bleeding.  We found the problem
account almost right away and shut it down.  It's no longer a problem.
But I'm looking ahead to the next time.

It's just inevitable that new naive users are going to do this again
to the system.  People think, "Who would want my stuff?"  And
consequently they don't protect their credentials, which are then used
to access my server, which is rich in tools.

So for the time 6 months from now when someone doesn't protect their
password adequately, I'd like to have my Postfix setup set to throttle
individual users.  Apparently I'm not saying this well, but no change
that I've made to the Postfix configuration (following examples and
directions around the net) has caused locally originated mail to be
tested against my policy server (postfwd) running on port 10040.

Other people have apparently encountered the same behaviour:

http://serverfault.com/questions/537701/postfix-check-policy-service-only-checking-incoming-mail-ignoring-internal-an

and

https://www.howtoforge.com/community/threads/postfix-seems-to-ignore-check_policy_service.49235/

Don


On Tue, Nov 10, 2015 at 6:04 PM, Ken Simpson  wrote:
> Hi Donald,
>
> Chances are, the problem you're trying to solve (throttling users) is
> actually a symptom of the larger problem of runaway spamming accounts. Am I
> right? In this case, throttling users with policyd and a relatively
> straightforward policyd script is a good option to stem the bleeding. But
> you may need to also invest time/resources tracking down and solving the
> cause of the excessive volume, such as compromised WordPress scripts or user
> accounts.
>
> Ken
>
> On Tue, Nov 10, 2015 at 3:37 PM, Donald Bindner  wrote:
>>
>> Yes, the point of my email is that I researched and tried to apply
>> exactly this configuration, but it did not work.  The
>> smtpd_recipient_restrictions rule they suggest does not appear to
>> apply to messages that originate on the server.  Or at least making
>> that single configuration does not have that effect.  I can verify
>> that emails originating on the server do not access the policy server
>> running on port 10040.
>>
>> Don
>>
>> On Tue, Nov 10, 2015 at 4:53 PM, Curtis Maurand 
>> wrote:
>> > And this.
>> >
>> >
>> > http://serverfault.com/questions/290684/postfix-limiting-the-rate-at-which-a-particular-user-can-send-email
>> >
>> > --Curtis
>
>

Re: procmail as a content_filter with dovecot under postfix

[Wietse Venema]

Vicki Brown:
> I'm sorry but that confused me even more.
> 
> I useprocmail to filter content. That's all I've ever used it for.

As mentioned before, procmail is designed for final delivery to
individual mailboxes, not for handling transit email.

If I may present an analogy, you are trying to use a screwdriver
to pick a lock. While this may be possible under some conditions,
you can expect better results for less effort with the right tool.

Wietse

Re: receiving message - checking mx record by postfix

[Zalezny Niezalezny]

Hi Viktor,

thank You for Your explanation. I searched for some opinion from external
people. I understand how mail system is working. The problem for me and my
team is our consultant which completly do not understand how mail system is
working and he trying to push some strange configurations to our mail
system. With Your E-mail it will be much easier for me to force also some
other topics.

@All, thank You very much for Your efficient (and super fast!) support.

For me topic is closed.

Short summary:

Incoming messages:
a) DNS A, PTR, MX

Outgoing messages:
a) DNS A, PTR, SPF


Once again thanks for Your support.


On Tue, Nov 10, 2015 at 9:49 PM, Viktor Dukhovni  wrote:

> On Tue, Nov 10, 2015 at 09:29:19PM +0100, Zalezny Niezalezny wrote:
>
> > We have two systems which are dedicated only to send E-mails.  Mostly for
> > massmailing.  These two machines will not receive any E-mails.
>
> Don't confuse "systems" (SMTP servers) with email domains (the
> domain part of an rfc822 email address).  Your *systems* do not
> need MX records.  They just need FQDN hostnames, and their IP
> addresses need to a PTR record that provides each system's hostname.
>
> Nor do the MX records of the envelope sender domain of the message
> being sent need to point at the sending systems.  It is not unusual
> to have separate systems sending and receiving mail.
>
> > Do we realy
> > need to configure MX records for that systems if they are not receiving
> any
> > E-mails?
>
> No MX records are required for your *systems* (SMTP servers).
>
> > From my point of view checking MX record from the client which
> > sending message is ... strange... if not stupid... In the SPF record we
> can
> > have a lot of systems which are not necesserly configured in the MX
> record.
>
> If you have SPF records for the envelope sender domain, then the
> sending IP addresses should be listed there.  In any case the
> envelope sender domain need to resolve to a set of valid public
> addresses or a set of MX hosts with valid public addresses.
>
> --
> Viktor.
>

Re: Throttling locally generated email

[Benning, Markus]

On 2015-11-10 23:42, Donald Bindner wrote:
smtpd_recipient_restrictions = check_policy_service 
inet:127.0.0.1:10040


You may want to use a different restriction than recipient.
The recipient restrictions are executed for every recipient.
It gets executed multiple times if the mail has more than one recipient.


However, this kind of rule seems to run only for mail "passing
through" my Postfix server and not for mail originating locally.  In
any event, the service running on port 10040 does not receive
connections from Postfix for mail that is generated locally.


If you mean real local submission by commandline, then you cant limit 
mails sent

this way. The checks are only implemented by smtpd.

If you mean the submission server (port 587) then you may want to check 
your master.cf.

May be it overwrites the option with different value like:

  -o smtpd_recipient_restrictions=


I'd love if someone would show an example that "hooks this up."  I'm
confident that I have postfwd configured correctly to listen on port
10040, I just need Postfix to talk to it.


No postfwd example, but mtpolicyd is also able to add quotas based on 
sasl_username:


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


Markus

--
https://markusbenning.de/

Re: Throttling locally generated email

[Peter]

On 11/11/2015 11:42 AM, Donald Bindner wrote:
> smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040
> 
> However, this kind of rule seems to run only for mail "passing
> through" my Postfix server and not for mail originating locally.  In
> any event, the service running on port 10040 does not receive
> connections from Postfix for mail that is generated locally.

Assuming that is in main.cf, it will work on any service that points to
smtpd that does not override smtpd_recipient_restrictions in master.cf.

> I'd love if someone would show an example that "hooks this up."  I'm
> confident that I have postfwd configured correctly to listen on port
> 10040, I just need Postfix to talk to it.

Check your master.cf file, odds are you have an override for
smtpd_recipient_restrictions in place for the submission service, just
add check_policy_service to the beginning of the override.


Peter

Re: procmail as a content_filter with dovecot under postfix

[Viktor Dukhovni]

On Tue, Nov 10, 2015 at 05:59:55PM -0800, Vicki Brown wrote:

> I'm sorry but that confused me even more.
> 
> I useprocmail to filter content. That's all I've ever used it for.
> I send mail through Spamassassin, add some headers, and delete high-scoring 
> spam. All in /etc/procmailrc.
> 
> That's content filtering.
> 
> That's not mail delivery.
> 
> Dovecot is doing the delivery.

In Postfix a "content filter" is a term of art for software that
can act as an intermediate hop in message delivery, while preserving
envelope sender information, handling non-local recipients, etc.

The procmail program is not such a content filter.  It is
architecturally ill-suited for processing mail that is not addressed
to a single local user account.  Procmail is a local delivery agent,
that looks at message content, but it is not a "content filter".

To use procmail, you must use "mailbox_command" and avoid
"mailbox_transport".  Procmail would then be responsible for
injecting the message into the (Dovecot) mailstore.

I'm afraid I won't be explaining this any further...

-- 
Viktor.

Re: TLSA and .mil dns servers

[Phil Stracchino]

On 11/09/15 22:55, Viktor Dukhovni wrote:
> I would also like to encourage more of the administrators on this
> list to publish TLSA records, but keep in mind that this is an
> operational commitment, not a fashion statement.  Once you publish
> TLSA records you MUST keep them accurate while performing future
> key/certificate updates (or changing issuing CAs if you're using
> DANE-TA(2) TLSA records).

[...]

> If you can do that, please go ahead and publish TLSA records for
> the MX hosts of your DNSSEC signed domains.  If that's too complex
> at this time, wait.  The documentation and tools will improve, and
> it is better to not publish at all than to publish broken records
> that create problems for both senders (other domains) and receivers
> (you).

This is where I admit that I haven't gotten around to DNSSEC signing
yet.  But then, mine is a very small domain with only one external IP.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

receiving message - checking mx record by postfix

[Zalezny Niezalezny]

Dear Colleagues,

I would like to understand how Postfix receiving message. I expect that
Postfix has been written base on the RFC rules so maybe somebody will be
able to explain me how its working inside - how this system receiving
message and what is going on in the background.

Our consultant hardly trying to tell us that server during receiving phase
checking MX record of the domain from which coming the E-mail. Does it
really working this way ? I always thought that Postfix checking first DNS
A record (reverse dns), then SPF etc.etc.

I always thought that MX record is provide clear information about the
servers to which client needs to send a message. But right now I`m
completly out of space...


Does system check mx record when its receiving message or not ?


Do You know where may I find RFC which fully describing this SMTP process ?



With kind regards

Zalezny

Re: receiving message - checking mx record by postfix

[Zalezny Niezalezny]

Hi,

thanks for Your fast feedback. I have found the same document, but to be
honest I didnt found there information what is happening on the server side.
Maybe somebody could explain in detail that part ?

thanks in advance

Zalezny

On Tue, Nov 10, 2015 at 1:36 PM, L.P.H. van Belle  wrote:

> Read :  http://www.sorbs.net/faq/rfc_helo_enforcement.shtml
>
> I contains also the links to the RFC’s
>
>
>
> Greetz,
>
>
>
> Louis
>
>
>
>
>
>
> --
>
> *Van:* zalezny.niezale...@gmail.com [mailto:
> owner-postfix-us...@postfix.org] *Namens *Zalezny Niezalezny
> *Verzonden:* dinsdag 10 november 2015 13:30
> *Aan:* Postfix users
> *Onderwerp:* receiving message - checking mx record by postfix
>
>
>
> Dear Colleagues,
>
>
>
> I would like to understand how Postfix receiving message. I expect that
> Postfix has been written base on the RFC rules so maybe somebody will be
> able to explain me how its working inside - how this system receiving
> message and what is going on in the background.
>
>
>
> Our consultant hardly trying to tell us that server during receiving phase
> checking MX record of the domain from which coming the E-mail. Does it
> really working this way ? I always thought that Postfix checking first DNS
> A record (reverse dns), then SPF etc.etc.
>
>
>
> I always thought that MX record is provide clear information about the
> servers to which client needs to send a message. But right now I`m
> completly out of space...
>
>
>
>
>
> Does system check mx record when its receiving message or not ?
>
>
>
>
>
> Do You know where may I find RFC which fully describing this SMTP process ?
>
>
>
>
>
>
>
> With kind regards
>
>
>
> Zalezny
>
>
>
>
>
>
>

Throttling locally generated email

[Donald Bindner]

I've been searching for some time, and what I want seems to be fairly
obscure, because I haven't found clear examples of it (at least I
don't think I have).

I run an Ubuntu server with user accounts, and we use a limited amount
of email on it, which we process with Postfix.  On occasion, a user
will succumb to a phishing attack and their password will get out.
Then a spammer will use that valid account to send a lot of emails.
Naturally this gets caught fairly quickly, the account is suspended,
and so on.

Since we do such a limited amount of email with this server, it would
be nice if I could limit local accounts to, say, 100 originated emails
per day (or 1000 or whatever).  That just keeps the flood smaller
while we respond to it.  It seems that a policy server like postfwd is
the usual way to do something like this, and usually I see examples
suggesting a main.cf rule like:

smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040

However, this kind of rule seems to run only for mail "passing
through" my Postfix server and not for mail originating locally.  In
any event, the service running on port 10040 does not receive
connections from Postfix for mail that is generated locally.

I'd love if someone would show an example that "hooks this up."  I'm
confident that I have postfwd configured correctly to listen on port
10040, I just need Postfix to talk to it.

Don

Re: Throttling locally generated email

[Curtis Maurand]

And this.

http://serverfault.com/questions/290684/postfix-limiting-the-rate-at-which-a-particular-user-can-send-email

--Curtis

On 11/10/2015 5:42 PM, Donald Bindner wrote:

I've been searching for some time, and what I want seems to be fairly
obscure, because I haven't found clear examples of it (at least I
don't think I have).

I run an Ubuntu server with user accounts, and we use a limited amount
of email on it, which we process with Postfix.  On occasion, a user
will succumb to a phishing attack and their password will get out.
Then a spammer will use that valid account to send a lot of emails.
Naturally this gets caught fairly quickly, the account is suspended,
and so on.

Since we do such a limited amount of email with this server, it would
be nice if I could limit local accounts to, say, 100 originated emails
per day (or 1000 or whatever).  That just keeps the flood smaller
while we respond to it.  It seems that a policy server like postfwd is
the usual way to do something like this, and usually I see examples
suggesting a main.cf rule like:

smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:10040

However, this kind of rule seems to run only for mail "passing
through" my Postfix server and not for mail originating locally.  In
any event, the service running on port 10040 does not receive
connections from Postfix for mail that is generated locally.

I'd love if someone would show an example that "hooks this up."  I'm
confident that I have postfwd configured correctly to listen on port
10040, I just need Postfix to talk to it.

Don


--
Curtis Maurand
cur...@maurand.com 
207-252-7748

Re: TLSA and .mil dns servers

[Alice Wonder]

On 11/10/2015 04:30 AM, Phil Stracchino wrote:

On 11/09/15 22:55, Viktor Dukhovni wrote:

I would also like to encourage more of the administrators on this
list to publish TLSA records, but keep in mind that this is an
operational commitment, not a fashion statement.  Once you publish
TLSA records you MUST keep them accurate while performing future
key/certificate updates (or changing issuing CAs if you're using
DANE-TA(2) TLSA records).


[...]


If you can do that, please go ahead and publish TLSA records for
the MX hosts of your DNSSEC signed domains.  If that's too complex
at this time, wait.  The documentation and tools will improve, and
it is better to not publish at all than to publish broken records
that create problems for both senders (other domains) and receivers
(you).


This is where I admit that I haven't gotten around to DNSSEC signing
yet.  But then, mine is a very small domain with only one external IP.




From my own personal experience, start with a very short TTL and do not 
make TLSA records until you have a process down for rotating zone 
signing keys that works.


I currently use a one hour TTL and I do not feel a need to ever increase 
that, but when I first started playing with DNSSEC I used a 5 minute TTL 
so that when I made mistakes the impact was short.


Even though all but one of my TLS certificates are signed by a CA, I 
always specify them as Type 3 in the TLSA record, not Type 1, even for 
https. It turns out that specifying Type 1 doesn't add any real world 
security at all, applications (like browsers) that want CA signed certs 
still have to verify themselves, so I do not see a benefit to specifying 
a TLSA record as Type 1.


I now am of the opinion that Type 0/1 TLSA records should be depricated 
as there is not, at least to me, a real world value to them. But I am 
not an expert in that area.


It is easier to experiment with a web server with TLSA because a bad 
TLSA record won't cause a loss of service to most people as most (all?) 
browsers don't care about TLSA without an extension.


Myself, I have TLSA records for my two mail servers, both very low 
volume, but I do not yet run postfix in DANE mode. Soon I will start 
doing that, but I'm waiting for increased DANE adoption and watching for 
issues, like the .mil issue that started this thread, before I take that 
step.


My DNS servers do DNSSEC validate so I at least get some MITM protection 
even without postfix running in DANE mode.