Impact of SSL renegotiation attacks on SMTP mail

[Wietse Venema]

Last week there was big news about a security hole in the TLS
protocol that allows a man-in-the-middle to prepend data to a
fully-secure TLS session.

That is, the server certificate verifies, and therefore no-one can
read or modify the network traffic. Or so we thought.

http://www.ietf.org/mail-archive/web/tls/current/msg03928.html
http://www.ietf.org/mail-archive/web/tls/current/msg03942.html

This hole was already known and a consortium of industry partners
was already working on solutions.  Meanwhile, a draft proposal has
been published for a TLS protocol change.

While looking at the possible impact for SMTP mail, I came up with
an attack that redirects and modifies SMTP mail that is sent over
a fully-secure TLS connection; Victor came up with an attack that
changes the first command in a TLS session.

You can find a preliminary analysis at:

http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pdf

It comes with a little tutorial on SMTP over TLS, and on TLS
renegotiation attacks.

The impact of all this should not be over-stated. Presently, most
SMTP clients don't verify the TLS certificates of SMTP servers.
Such clients are already vulnerable to ordinary man-in-the-middle
attacks, and TLS renegotiation introduces no new threats for them.

The Postfix SMTP server with OpenSSL is not affected by the TLS
renegotiation attack that redirects and modifies SMTP mail, due to
accidental details of the Postfix and OpenSSL implementations.
Other SMTP server implementations may be affected (my report
describes some of the requirements).  There may of course be other
attacks that I wasn't aware of when I wrote the analysis.

Most SMTP client implementations will not detect that a TLS
renegotiation attack has happened, including the Postfix SMTP
client.  Victor and I have looked into a number of workarounds
that can be implemented in the SMTP client, pending a bugfix in
the TLS protocol and in TLS implementations.  Some of these
workarounds may end up in Postfix.

Wietse

how to increase throughput of postfix to local user?

[Stan Hoeppner]

devel anaconda put forth on 11/8/2009 11:16 AM:
> 06.11.09, 02:32, "Victor Duchovni" :

>> You are not going to succeed without more spindles and likely more CPUs.
>> Just launching a "Perl" hello-world script takes >10ms on a fast machine,
>> do that 100 times a second and you've burned a CPU, and non-trivial
>> scripts are slower still.

I absolutely agree with Victor WRT to the spindles issue, as I've
already stated.  I don't necessarily agree with his suggestion that you
need more CPUs.  You've got 8 cores at 2.8GHz, and they're XEONs, so
they've got a lot of L2/L3 cache.  That is some really serious
processing horsepower.  Once you get the disk bottleneck solved, I'm
guessing you'll find you have plenty of CPU.  Victor has vastly more
Postfix and Perl experience than me, so I may be talking out of turn
here.  However, short of some HPC workloads, I've not seen any
application stack to date come close to fully saturating a 16 core
system.  I'm eager to be proven wrong. ;)

> As I said above - scripts is not the point at a time. If it will, I'll 
> rewrite them, so my scripts will listen unix socket and I'll put messages 
> directly into sockets.
> 
> I think, that things will go faster, if postfix, instead of saving new 
> messages to queue, will try to deliver it to deliver agent "in memory", and 
> only if that fails, save the message to queue. Don't you think, this will be 
> faster? Is that possible? I can make a patch (not for upstream, only for me).

I don't think keeping them in memory is going help anything.  It will
probably make it worse.  Your example previously mentioned over 100GB
worth of spool files being generated.  You've only got 16GB of RAM.
Using your new idea, keeping the files resident, you'll run out of RAM
and start hammering the swap file.  So, you're in the same situation,
just a different software component hammering the disks, now the kernel
memory manager instead of postfix queue manager.  The big downside to
this is that your swap partition is probably only somewhere around 16GB.
 Due to this, you'll run out of swap space and possibly crash the
kernel.  At least as things currently are, if Postfix runs out of spool
space, it won't crash the kernel, just possibly parts of Postfix.

It seems that your problem is purely one of lack of I/O bandwidth,
basically generating too many files too quickly for the system to
dispose of.  Either the emails need to be delivered out the network
faster to their final destination, or they need to be delivered faster
to local accounts, i.e. local disk.  One way or another, you've got to
deliver them as fast as they come in or you have to spool them in memory
or disk.  If the destinations are over the wire to another host, you're
going to be waiting on downstream MTAs, and emails will have to sit in
memory or in spool files until delivered.  If the emails are destined
locally, then they must be written to local disk quickly.  Either way,
you need more disk bandwidth.

You have three options as I see it:

1.  Cut down on the total volume of email files per time step
2.  Substantially increase disk subsystem bandwidth via spindles
3.  Increase system RAM to 128GB, make 112GB a RAM disk for the spool

Option 3 isn't really a valid option because your server probably
doesn't have enough sockets to support 128GB of RAM, and even if it did,
you could buy 4 or 5 fourteen drive disk arrays for the same money, and
just one such array will solve your problem, for a tiny fraction of the
cost of that much RAM.

So, if you can't accomplish #1 above, you need to accomplish #2, which
you're already testing with two additional drives.  You'll probably need
more.  Keep us posted on your progress.  I find this case very
interesting, given it touches so heavily on hardware performance.  (See
the right hand side of my email address). ;)

--
Stan

Re: How to use direct delivery before relay?

[Mike Gering]

Wietse Venema wrote:

  Mike Gering:
  
  
Is there a way to configure postfix so that it will attempt to use 
direct delivery before relaying to another host?

  
  
Postfix looks up MX records by default, and can be configured to
add an "extra" MX host (with smtp_fallback_relay) that is given
the worst possible MX preference.

Note that if any host replies with a permanent error (5xx code) to
MAIL FROM, RCPT TO, DATA or end-of-data, Postfix will delete the
recipient(s) from the queue file and not try an alternate host for
those recipients.
  



  
However, I see occasional email abuse from EC2, so it is possible
that the EC2 IP address range had a bad email reputation.

In addition, many ISPs reject or silently discard mass mailings
from anywhere unless prior arrangements have been made.

	Wietse

  

Unfortunately, the failures I see are 5xx. I checked the IP address
(174.129.10.202) and AFAIK it is not blacklisted. The site is www.ci.hillsborough.nc.us and is
obviously not a spam source. I'm surprised and disappointed that Amazon
does not provide a solution for legitimate customers. 

Re: How to use direct delivery before relay?

[Wietse Venema]

Mike Gering:
> Is there a way to configure postfix so that it will attempt to use 
> direct delivery before relaying to another host?

Postfix looks up MX records by default, and can be configured to
add an "extra" MX host (with smtp_fallback_relay) that is given
the worst possible MX preference.

Note that if any host replies with a permanent error (5xx code) to
MAIL FROM, RCPT TO, DATA or end-of-data, Postfix will delete the
recipient(s) from the queue file and not try an alternate host for
those recipients.

However, I see occasional email abuse from EC2, so it is possible
that the EC2 IP address range had a bad email reputation.

In addition, many ISPs reject or silently discard mass mailings
from anywhere unless prior arrangements have been made.

Wietse

> I've built my webserver on Amazon EC2 which, even with static IP 
> addresses, does not handle reverse DNS lookup, causing (relatively few) 
> recipient servers reject the mail. We've contracted with a mail relay 
> service, but they are more expensive than the EC2 service itself! Since 
> we're a municipal government, we need to reduce expenses as much as 
> possible. The only solution I can think of is to have postfix attempt to 
> deliver outgoing mail directly, and then for failures due to connection 
> refusals, deliver them via the relay.
> 
> Is there a way to do this? Or maybe there is a better solution. Any help 
> is very welcome!
> 
> Thanks,
> Mike
> 
> 
> 

Re: How to use direct delivery before relay?

[Dhiraj Chatpar]

What i think you can try do is try creating multiple instance of postfix
First Instance: Direct Delivery (If rejected forwarded and tried via
Instance 2)
Second Instance: Configured for only relay host

I guess this should solve the problem.

Rgds
Dhiraj



Stephen 
Leacock
- "I detest life-insurance agents: they always argue that I shall some
day
die, which is not so."

On Mon, Nov 9, 2009 at 03:00, Mike Gering wrote:

> Is there a way to configure postfix so that it will attempt to use direct
> delivery before relaying to another host?
>
> I've built my webserver on Amazon EC2 which, even with static IP addresses,
> does not handle reverse DNS lookup, causing (relatively few) recipient
> servers reject the mail. We've contracted with a mail relay service, but
> they are more expensive than the EC2 service itself! Since we're a municipal
> government, we need to reduce expenses as much as possible. The only
> solution I can think of is to have postfix attempt to deliver outgoing mail
> directly, and then for failures due to connection refusals, deliver them via
> the relay.
>
> Is there a way to do this? Or maybe there is a better solution. Any help is
> very welcome!
>
> Thanks,
> Mike
>
>

How to use direct delivery before relay?

[Mike Gering]

Is there a way to configure postfix so that it will attempt to use 
direct delivery before relaying to another host?


I've built my webserver on Amazon EC2 which, even with static IP 
addresses, does not handle reverse DNS lookup, causing (relatively few) 
recipient servers reject the mail. We've contracted with a mail relay 
service, but they are more expensive than the EC2 service itself! Since 
we're a municipal government, we need to reduce expenses as much as 
possible. The only solution I can think of is to have postfix attempt to 
deliver outgoing mail directly, and then for failures due to connection 
refusals, deliver them via the relay.


Is there a way to do this? Or maybe there is a better solution. Any help 
is very welcome!


Thanks,
Mike

Re: how to increase throughput of postfix to local user?

[devel anaconda]

08.11.09, 12:28, "James MacLachlan" :

> Is your queue disk mounted aysnc?  If so you are in ram for the most 
> part anyway, 

Well, actually - not.
Yes, it's mounted with async. I straced the cleanup daemon. Two things slows 
down HDD's: write() and fsync() on each message. So, I disabled fsync() and 
didn't get any appreciable benefits. So, the write() is the thing.

If moving all queues to RAID0 won't help, I'll change postfix a bit for moving 
only "incoming" queue to RAM disk. "Vanilla" postfix does not allow that.
If that won't help, I'll try to move all queues to RAM and see.
Thanks.

Re: sending notification of new mail to cell phone

[LuKreme]

On 8-Nov-2009, at 10:13, Jon Musselwhite wrote:


Hi, I've been searching everywhere for this and can't seem to find a
solution.

I'm runing a centos 5 server with postfix and cyrus on it and would  
like to
send a notification email to a cell phone email address when new  
mail is
received on a certain account. What is the best way to go about  
doing this?


procmail.


--
Someone's behind this. Someone wants to see a war. [...] I've got to  
remember that. This isn't a war. This is a crime. --Jingo

Re: sending notification of new mail to cell phone

[/dev/rob0]

On Sunday 08 November 2009 11:13:36 Jon Musselwhite wrote:
> Hi, I've been searching everywhere for this and can't seem to find
> a solution.

And your post might make matters worse, as no one can propose any
solution without making wild (and likely wrong) guesses about your
configuration.

> I'm runing a centos 5 server with postfix and cyrus on it and would
> like to send a notification email to a cell phone email address
> when new mail is received on a certain account. What is the best
> way to go about doing this?

"Best" is relative to your configuration and to your comfort level
with various external software. This sounds like a procmail(1) and
mutt(1) job to me. It will sound different to maildrop or sieve
users, I am sure.

> I've tried adding a new service to master.cf that runs a script,
> but it won't run when new mail is received. It will only run if I
> replace an existing service with the script (like spamassassin).

My WAG here would be that you don't understand the concept of
transport(5) as is used in Postfix. Mail comes in by one of several
means, typically smtpd(8) or sendmail(1). Then a routing decision is
made, and it is routed out via a transport:nexthop.

I would suggest DEBUG_README.html#mail and Google the list archives
before you post again. Note that "cell phone" is quite irrelevant as
search term; Postfix makes no distinction as to the ultimate
destination of any email address other than the aforementioned
transport:nexthop determination. What you want is to run a command.

aliases.5.html describes various means for local(8) delivery to pipe
to commands; virtual.5.html (and postconf.5.html#virtual_alias_maps)
offers an easy way to route any particular address to another, such
as to a local alias which or user who might run a command. And
finally there is pipe.8.html to set up a transport to external
software.

Of course all the .html references should be on your own machine;
they can also be found at http://www.postfix.org/ .
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: how to increase throughput of postfix to local user?

[devel anaconda]

06.11.09, 02:32, "Victor Duchovni" :

> > That's why I use postfix and that's why I can't use pre-queued
> > filter. I thought about different scheme, but postfix is the "easy way",
> > so I'm trying speedup things a bit :)

> You are not going to succeed without more spindles and likely more CPUs.
> Just launching a "Perl" hello-world script takes >10ms on a fast machine,
> do that 100 times a second and you've burned a CPU, and non-trivial
> scripts are slower still.

As I said above - scripts is not the point at a time. If it will, I'll rewrite 
them, so my scripts will listen unix socket and I'll put messages directly into 
sockets.

I think, that things will go faster, if postfix, instead of saving new messages 
to queue, will try to deliver it to deliver agent "in memory", and only if that 
fails, save the message to queue. Don't you think, this will be faster? Is that 
possible? I can make a patch (not for upstream, only for me).

sending notification of new mail to cell phone

[Jon Musselwhite]

Hi, I've been searching everywhere for this and can't seem to find a
solution.

I'm runing a centos 5 server with postfix and cyrus on it and would like to
send a notification email to a cell phone email address when new mail is
received on a certain account. What is the best way to go about doing this?
I've tried adding a new service to master.cf that runs a script, but it
won't run when new mail is received. It will only run if I replace an
existing service with the script (like spamassassin).

-Jon

Re: how to increase throughput of postfix to local user?

[devel anaconda]

07.11.09, 13:41, "Stan Hoeppner" :


> > Have you tried a filesystem other than ext3 like Reiser or XFS? The
> > performance of ext3 really, really sucks if you have a lot of files in
> > one directory as a mail spool is bound to have.
> I'd stay away from Reiser, for multiple reasons, but XFS would
> definitely be an improvement over ext3.  However, changing file systems
> alone isn't going to solve his problem--it won't even double his
> throughput, and he needs something like at least a 3x increase in disk
> throughput at a minimum.
> Unless he changes his filters so as to not write so darn many spool
> files, he will absolutely require more spindles.  SSD is an option for
> speed, but I doubt he'd want to spend the money required for 100+ GB of
> SSD.  I'd say he needs at least 3 more SCSI drives in a Linux RAID 0
> setup, or 6 more drives in a Linux RAID 10 setup, with XFS atop those.
> IMHO, his next step should be adding a couple of 74GB 10K or 15K RPM
> drives into his two empty disk bays, configure for RAID 0 with XFS atop
> that, and test.  If that's still not enough, then he should go with
> something like that cheap 14 drive external array I previously
> mentioned, or SSD if he's flush with cash.


The problem is not in filters. It's not the bottleneck for now. The bottleneck 
for now is moves messages from incoming to active queue. I'll try to use two 
other HDD's for RAID0. Thank you.

Re: sending an email message based on a subject keyword to an external program

[mouss]

John Haggerty a écrit :
> I was wondering if there is a possibility of using postfix to send a
> message that has some Keyword in the subject line and send it to an
> external program like gpg? I'm envisioning getting a sensitive set of
> system messages to want to make them automated and encrypted at the same
> time (like maybe cron jobs/etc).
> 
> Is this possible? and if so how?

you can use the FILTER statement in header_checks

/^Subject:.*CONFIDENTIAL/   FILTER yourfilterdescriptionhere

See FILTER README for how to setup a filter.

Re: Postfix header_checks and HOLD queue

[Magnus Bäck]

On Saturday, November 07, 2009 at 21:10 CET,
 waltari2001  wrote:

> Brian Evans - Postfix List wrote:
>
> > Suggestion:
> >
> > Look at the postsuper manual again and focus on the -H parameter.
> > This assumes (maximal|bounce)_queue_lifetime is set much further
> > than the HOLD time.
>
> I've tried that. It will still put it back in the HOLD queue. Here are
> my settings.
>
> bounce_queue_lifetime = 1d
> maximal_queue_lifetime = 1d
>
> I've run postsuper -H MSGID 2 min after being help then postsuper -r
> a min later. It's still showing up in the HOLD queue with a different
> MSGID.

Stop requeueing the message. The whole point of "postsuper -H" is to
release the message without requeueing it.

Do not top-post. Place your response below the quoted text.

-- 
Magnus Bäck
mag...@dsek.lth.se

Re: Virtual aliases and "Delivered-To:" header

[mouss]

Aleš Krajník a écrit :
> Hi guys,
> 
> I have a problem setting up my postfix so it records all (virtual) aliases'
> expansions into e-mail headers.
> 
> I have a postfix 2.6.5, amavis 2.6.3 and (virtual) delivery to dovecot 1.2.6
> (on Gentoo which is probably not important).
> 
> The thing is that I want e-mail headers to contain all aliases expansions,
> for example:
>   * i have an alias my...@example.com redirected to ser...@example.com
>   * i have an alias ser...@example.com redirected to my personal
> e-mail, a...@example.com
>   * i have a virtual mail box, in dovecot, a...@example.com
> 
> These are only examples (of course) and there are more aliases than
> my...@example.com (otherwise it would not make any sense).
> 
> I would like to setup filtering rules in dovecot's sieve so it moves all
> e-mails sent to ser...@example.com (and all aliases that expand to this one)
> to some folder.
> 

if your goal is to ease sieve filtering, consider using extensions in
your aliases. for example, redirect my...@example.com to
server+my...@example.com, ... etc.


> I searched through all the Postfix documentation but did not found how to
> achieve this. My e-mail headers contain the "Delievered-To:" headers only
> for the first and the last e-mail in the aliases' expansion cycle (that is
> my...@example.com and a...@example.com).
> 
> It seems that some daemon, that does the aliases' expansion (cleanup?), logs
> only the first and the last e-mail address in the expansion cycle. So I
> tried adding "frozen_delivered_to=no" to main.cf, local daemon in master.cf,
> trivial-rewrite daemon in master.cf and some others but the result is always
> the same.
> 
> So... is there a way how to record all aliases' expansions in the e-mail
> headers? Using directly the ser...@example.com e-mail address is an option
> but not much good for me.
> 
> Thanks for your advice!
> Ales Krajnik
> 

Re: outbound spam filtering

[mouss]

Phill Macey a écrit :
> 2009/11/7 mouss :
>> 
>> Most statistical anti-spam filters assume an inbound model. you can use
>> a "global" bayes setup, but then I don't think you'll benefit from
>> dspam/bogo/...
>>
> 
> Could you turn the outgoing mail around and make it inbound mail as
> well? [snip]

no, the problem is related to training. in the case of inbound mail,
statistical filters use the fact that a given user (or a given set of
users) receive mail which characteristics can be learned if you have a
sufficient corpus (of ham and spam).

you can still use this for outbound mail, with a global "dictionary"
(site wide setup). but
- nobody is going to feed back "false negatives" (missed spam)
- who is going to feed back "false positives"? how? while feasible, this
is not a simple problem.

that said, you can still run spamassin and have a log parser to detect
problems: some user suddenly sends a lot of mail that gets tagged as
spam... etc.

definitely not a simple problem...

Re: Problem using Postfix, saslauthd and pam_krb5

[Ali Majdzadeh]

Viktor,
Thanks a lot, I managed to solve the problem. I can now authenticate users
using SASL, saslauthd, PAM and pam_krb5.so (and of cource Kerberos!)
Thanks again.

Kind Regards
Ali Majdzadeh Kohbanani

2009/11/8 Ali Majdzadeh 

> Viktor,
> Thanks a lot. You are very helpful.
>
>
> Kind Regards
> Ali Majdzadeh Kohbanani
>
> 2009/11/8 Victor Duchovni 
>
> On Sat, Nov 07, 2009 at 11:11:36PM +0330, Ali Majdzadeh wrote:
>>
>> > Viktor,
>> > Hi
>> > I managed to test the configuration using the sample programs provided
>> by
>> > Cyrus. But I can not test the configuration using Postfix. Sample users
>> > which are defined as principles are successfully authenticated using
>> PLAIN
>> > authentication mechanism, pam_krb5.so and saslauthd, but the similar
>> > configuration for Postfix, always fails.
>>
>> Turn up the debug level in saslauthd, and find out what queries it is
>> handling and why it believes the password to be incorrect.
>>
>> --
>> Viktor.
>>
>> Disclaimer: off-list followups get on-list replies or get ignored.
>> Please do not ignore the "Reply-To" header.
>>
>> To unsubscribe from the postfix-users list, visit
>> http://www.postfix.org/lists.html or click the link below:
>> 
>>
>> If my response solves your problem, the best way to thank me is to not
>> send an "it worked, thanks" follow-up. If you must respond, please put
>> "It worked, thanks" in the "Subject" so I can delete these quickly.
>>
>
>