Re: Using TLS for certain domains

[polloxx]

We wanted to test TLS and we've found this one: http://www.checktls.com/

Thanks to the list for all the help.


On Wed, Jun 12, 2013 at 8:05 PM, Noel Jones  wrote:

> On 6/12/2013 10:53 AM, polloxx wrote:
> > Thanks Wietse.
> > Can we test this setup?
> >
>
> If you're asking how to test your TLS, use the openssl s_client.
>
> openssl s_client -connect se.rv.er.ip:port -starttls smtp
>
>
> If it's working, you'll get several screens full of connection info
> and certificate exchange, probably including some "unable to verify"
> messages you should ignore.  The last thing displayed should be:
>
> 250 DSN
>
> which tells that TLS is working.  Type
> quit
> to exit back to your shell.
>
>
>
>   -- Noel Jones
>

Re: Bulk Mailing Performance

[Viktor Dukhovni]

On Wed, Jun 12, 2013 at 03:53:17PM -0700, fletch wrote:

> What do you mean by: "...they can not come close to postfix as far as email
> standards go"?  My understanding is that powermta fully complies with the
> various RFCs.
> 
> Also, I'm sure there are far more spammers using free software like postfix
> rather than paying for a commercial product.

Let's not go down this rabbit-hole.   At this point in the thread we're no
longer talking about Postfix.

-- 
Viktor.

Re: Bulk Mailing Performance

[fletch]

What do you mean by: "...they can not come close to postfix as far as email
standards go"?  My understanding is that powermta fully complies with the
various RFCs.

Also, I'm sure there are far more spammers using free software like postfix
rather than paying for a commercial product.


On Wed, Jun 12, 2013 at 1:57 PM, AFCommerce LLC [via Postfix] <
ml-node+s1071664n5888...@n5.nabble.com> wrote:

> I know powermta as well as postfix and I think I can add to some of the
> comments on here, powermta is not cheap by any means and of course postfix
> is free, however pmta might have some settings out of the box that are
> optimized for bulk but they can not come close to postfix as far as email
> standards go, incoming mail, etc (in my opinion) mainly from how many
> servers are using it, basically postfix, exim and sendmail create the
> standards that a company like pmta has to try to follow.
>
> But the main reason bulk mailers mainly pay for pmta is because it has the
> ability to send on many ips/hostnames far easier than postfix, since
> postfix wasn't built (by choice) to send from 100s of ips and domains
> because that can easily become a tool for a spammer (a spammer could try to
> modify postfix I assume). The commercial support is a 2nd reason, most of
> us on this list wouldn't need that type of support, but a legitimate
> company who doesn't have a decent support staff would be interested in that.
>
>
> On Wed, Jun 12, 2013 at 4:09 PM, Robert Schetterer <[hidden 
> email]
> > wrote:
>
>> Am 12.06.2013 21:17, schrieb fletch:
>> > The postfix performance claims made via this thread are far-fetched to
>> say
>> > the least.  Most postfix users will only see outbound throughput in the
>> > range of ~250,000/hour per instance in a production setting.  Yet,
>> people on
>> > here are claiming 10 million/hour?  I guess that would be possible if a
>> > sender were to run, say, 40 postfix instances which would be a complete
>> > management nightmare of course.
>> >
>> > Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
>> > would not be able to make any sales if the benefits of commercial
>> software
>> > products v. open source were not substantial.
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58873.html
>> > Sent from the Postfix Users mailing list archive at Nabble.com.
>> >
>>
>> however magic jedi software overpower setup you might use for deliver
>> out, you never will reach the higher powered master level , where you
>> can press all others to take your mails at a number in time periods you
>> might like , so using paid services/software for bulk maybe a good idea
>> by many things, comparing it to some default settings of postfix is
>> simply nonsense and typical marketing bla bla
>>
>>
>> Best Regards
>> MfG Robert Schetterer
>>
>> --
>> [*] sys4 AG
>>
>> http://sys4.de, > value="+498930904664">+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, Axel von der Ohe, Marc Schiffbauer
>> Aufsichtsratsvorsitzender: Florian Kirstein
>>
>
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58880.html
>  To unsubscribe from Bulk Mailing Performance, click 
> here
> .
> NAML
>




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58882.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Bulk Mailing Performance

[Roel Wagenaar]

wie...@porcupine.org (Wietse Venema) wrote:

> fletch:
> > The postfix performance claims made via this thread are far-fetched to
say
> > the least.  Most postfix users will only see outbound throughput in the
> > range of ~250,000/hour per instance in a production setting.  Yet,
people on
> > here are claiming 10 million/hour?  I guess that would be possible if a
> > sender were to run, say, 40 postfix instances which would be a complete
> > management nightmare of course.
> > 
> > Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
> > would not be able to make any sales if the benefits of commercial
software
> > products v. open source were not substantial.  
> 
> Is this a troll?



Obviously YES.

 
And quite a lot of feeders too.


> I have documented Postfix performance claims on Wikipedia. Be sure
> to read the cautionary note about factors outside of Postfix that
> in practice limit the delivery performance.
> 
>   Wietse
> 
> 

DFTT


-- 
Roel Wagenaar,

Linux-User #469851 with the Linux Counter; http://linuxcounter.net/

Antw.: Omdat het de volgorde verstoord waarin mensen tekst lezen.
Vraag: Waarom is top-posting een slechte gewoonte?
Antw.: Top-posting.
Vraag: Wat is het meest ergerlijke in e-mail?

Diplomacy is the art of letting someone else get your way.

Re: Bulk Mailing Performance

[AFCommerce LLC]

I know powermta as well as postfix and I think I can add to some of the
comments on here, powermta is not cheap by any means and of course postfix
is free, however pmta might have some settings out of the box that are
optimized for bulk but they can not come close to postfix as far as email
standards go, incoming mail, etc (in my opinion) mainly from how many
servers are using it, basically postfix, exim and sendmail create the
standards that a company like pmta has to try to follow.

But the main reason bulk mailers mainly pay for pmta is because it has the
ability to send on many ips/hostnames far easier than postfix, since
postfix wasn't built (by choice) to send from 100s of ips and domains
because that can easily become a tool for a spammer (a spammer could try to
modify postfix I assume). The commercial support is a 2nd reason, most of
us on this list wouldn't need that type of support, but a legitimate
company who doesn't have a decent support staff would be interested in that.


On Wed, Jun 12, 2013 at 4:09 PM, Robert Schetterer  wrote:

> Am 12.06.2013 21:17, schrieb fletch:
> > The postfix performance claims made via this thread are far-fetched to
> say
> > the least.  Most postfix users will only see outbound throughput in the
> > range of ~250,000/hour per instance in a production setting.  Yet,
> people on
> > here are claiming 10 million/hour?  I guess that would be possible if a
> > sender were to run, say, 40 postfix instances which would be a complete
> > management nightmare of course.
> >
> > Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
> > would not be able to make any sales if the benefits of commercial
> software
> > products v. open source were not substantial.
> >
> >
> >
> > --
> > View this message in context:
> http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58873.html
> > Sent from the Postfix Users mailing list archive at Nabble.com.
> >
>
> however magic jedi software overpower setup you might use for deliver
> out, you never will reach the higher powered master level , where you
> can press all others to take your mails at a number in time periods you
> might like , so using paid services/software for bulk maybe a good idea
> by many things, comparing it to some default settings of postfix is
> simply nonsense and typical marketing bla bla
>
>
> Best Regards
> MfG Robert Schetterer
>
> --
> [*] sys4 AG
>
> http://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, Axel von der Ohe, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
>

Re: Bulk Mailing Performance

[Ben Johnson]

On 6/12/2013 4:40 PM, fletch wrote:
> Peer,
> 
> There's no way that's a production figure.  You may have queued that many,
> but I seriously doubt you got anything close to 3-4 million/hour when
> postfix was actually conducting delivery with the remote gateways...
> 

This point is somewhat moot, quite frankly, because the performance
claims as documented on Wikipedia state:

Postfix has been clocked at ~300 message deliveries/second[6] across the
Internet, running on commodity hardware (a vintage-2003 Dell 1850 system
with battery-backed MegaRAID controller and two SCSI disks). This
delivery rate is an order of magnitude below the "intrinsic" limit of
2500 message deliveries/second[6] that was achieved *with the mail queue
on a RAM disk while delivering to the "discard" transport (with a
dual-core Opteron system in 2007).*

Nobody (besides perhaps Peer) is making any claim with respect to
"real-world" performance. The performance claims as documented assume
factors only within Postfix and the computer on which it's runnings'
control.

-Ben

Re: Bulk Mailing Performance

[fletch]

Peer,

There's no way that's a production figure.  You may have queued that many,
but I seriously doubt you got anything close to 3-4 million/hour when
postfix was actually conducting delivery with the remote gateways...



On Wed, Jun 12, 2013 at 1:02 PM, Peer Heinlein [via Postfix] <
ml-node+s1071664n58876...@n5.nabble.com> wrote:

> Am 12.06.2013 21:17, schrieb fletch:
>
> > here are claiming 10 million/hour?  I guess that would be possible if a
> > sender were to run, say, 40 postfix instances which would be a complete
> > management nightmare of course.
>
> You already lost.
>
> I did this even 5-6 years ago with 3-4 millionen mails / hour in one
> postfix instance on one stupid dual-xeon server with 100 MBit uplink.
>
> > Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
> > would not be able to make any sales if the benefits of commercial
> software
> > products v. open source were not substantial.
>
> They're making sales with people, that believe that people coming from a
> comercial company are always and automatically better then everbody else.
>
>
> Peer
>
>
> --
> Heinlein Support GmbH
> Schwedter Str. 8/9b, 10119 Berlin
>
> http://www.heinlein-support.de
>
> Tel: 030 / 405051-42
> Fax: 030 / 405051-19
>
> Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
> Berlin-Charlottenburg,
> Geschäftsführer: Peer Heinlein -- Sitz: Berlin
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58876.html
>  To unsubscribe from Bulk Mailing Performance, click 
> here
> .
> NAML
>




--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58878.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Bulk Mailing Performance

[Robert Schetterer]

Am 12.06.2013 21:17, schrieb fletch:
> The postfix performance claims made via this thread are far-fetched to say
> the least.  Most postfix users will only see outbound throughput in the
> range of ~250,000/hour per instance in a production setting.  Yet, people on
> here are claiming 10 million/hour?  I guess that would be possible if a
> sender were to run, say, 40 postfix instances which would be a complete
> management nightmare of course.
> 
> Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
> would not be able to make any sales if the benefits of commercial software
> products v. open source were not substantial.  
> 
> 
> 
> --
> View this message in context: 
> http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58873.html
> Sent from the Postfix Users mailing list archive at Nabble.com.
> 

however magic jedi software overpower setup you might use for deliver
out, you never will reach the higher powered master level , where you
can press all others to take your mails at a number in time periods you
might like , so using paid services/software for bulk maybe a good idea
by many things, comparing it to some default settings of postfix is
simply nonsense and typical marketing bla bla


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://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, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Bulk Mailing Performance

[Joe]

On 06/12/2013 12:17 PM, fletch wrote:

The postfix performance claims made via this thread are far-fetched to say
the least.  Most postfix users will only see outbound throughput in the
range of ~250,000/hour per instance in a production setting.  Yet, people on
here are claiming 10 million/hour?  I guess that would be possible if a
sender were to run, say, 40 postfix instances which would be a complete
management nightmare of course.

Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
would not be able to make any sales if the benefits of commercial software
products v. open source were not substantial.



In our experience, postfix can blast out messages at rates which are 
orders of magnitude faster than the other end is willing to receive it. 
The "substantial benefits" you speak of are mainly along the lines of 
easier management tools and integration of same with various other email 
related components in one convenient interface.


Joe

Re: Bulk Mailing Performance

[Wietse Venema]

fletch:
> The postfix performance claims made via this thread are far-fetched to say
> the least.  Most postfix users will only see outbound throughput in the
> range of ~250,000/hour per instance in a production setting.  Yet, people on
> here are claiming 10 million/hour?  I guess that would be possible if a
> sender were to run, say, 40 postfix instances which would be a complete
> management nightmare of course.
> 
> Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
> would not be able to make any sales if the benefits of commercial software
> products v. open source were not substantial.  

Is this a troll?

I have documented Postfix performance claims on Wikipedia. Be sure
to read the cautionary note about factors outside of Postfix that
in practice limit the delivery performance.

Wietse

Re: Bulk Mailing Performance

[Peer Heinlein]

Am 12.06.2013 21:17, schrieb fletch:

> here are claiming 10 million/hour?  I guess that would be possible if a
> sender were to run, say, 40 postfix instances which would be a complete
> management nightmare of course.

You already lost.

I did this even 5-6 years ago with 3-4 millionen mails / hour in one
postfix instance on one stupid dual-xeon server with 100 MBit uplink.

> Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
> would not be able to make any sales if the benefits of commercial software
> products v. open source were not substantial.  

They're making sales with people, that believe that people coming from a
comercial company are always and automatically better then everbody else.


Peer


-- 
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin

Re: Bulk Mailing Performance

[fletch]

The postfix performance claims made via this thread are far-fetched to say
the least.  Most postfix users will only see outbound throughput in the
range of ~250,000/hour per instance in a production setting.  Yet, people on
here are claiming 10 million/hour?  I guess that would be possible if a
sender were to run, say, 40 postfix instances which would be a complete
management nightmare of course.

Obviously, vendors like Port25 (company behind PowerMTA) and GreenArrow
would not be able to make any sales if the benefits of commercial software
products v. open source were not substantial.  



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Bulk-Mailing-Performance-tp50222p58873.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Using TLS for certain domains

[Noel Jones]

On 6/12/2013 10:53 AM, polloxx wrote:
> Thanks Wietse.
> Can we test this setup?
> 

If you're asking how to test your TLS, use the openssl s_client.

openssl s_client -connect se.rv.er.ip:port -starttls smtp


If it's working, you'll get several screens full of connection info
and certificate exchange, probably including some "unable to verify"
messages you should ignore.  The last thing displayed should be:

250 DSN

which tells that TLS is working.  Type
quit
to exit back to your shell.



  -- Noel Jones

Re: Using TLS for certain domains

[Ansgar Wiechers]

On 2013-06-12 Wietse Venema wrote:
> If you mean that "set nowrap" in vim did not put the line breaks
> back, then that is to be expected.
> 
> If you mean that "set nowrap" in vim removes line breaks, then that
> is a question for vim users/faqs/maintainers.

FTR: "set wrap" or "set nowrap" don't add or remove any linebreaks. They
just modify how the text is displayed.

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

Re: is this a postfix bug or an openSUSE bug, or neither?

[Wietse Venema]

Carlos E. R.:
> Apararently, my previous reply has been lost. I resend.
> 
> On 2013-06-12 14:40, Wietse Venema wrote:
> > Carlos E. R.:
> 
> > 
> > Does the machine have a network interface with IP address 127.0.0.2?
> 
> Dunno. I guess not, because it is not listed in ifconfig output.

Then, 127.0.0.2 should not be specified in inet_interfaces.

Wietse

Re: Using TLS for certain domains

[Wietse Venema]

polloxx:
> Thanks to all of you.
> Now it works, although "set nowrap" in vim did not solve the issue. I had
> to add the parameters using "postconf -e".
> Is this normal?

Wietse:
> "set nowrap" has no effect after the text is already wrapped.

polloxx:
> Thanks Wietse.
> Can we test this setup?

If you mean that "set nowrap" in vim did not put the line breaks
back, then that is to be expected.

If you mean that "set nowrap" in vim removes line breaks, then that
is a question for vim users/faqs/maintainers.

Wietse

Re: Using TLS for certain domains

[polloxx]

Thanks Wietse.
Can we test this setup?


On Wed, Jun 12, 2013 at 5:29 PM, Wietse Venema  wrote:

> polloxx:
> > Thanks to all of you.
> > Now it works, although "set nowrap" in vim did not solve the issue. I had
> > to add the parameters using "postconf -e".
> > Is this normal?
>
> "set nowrap" has no effect after the text is already wrapped.
>
> Wietse
>

Re: Using TLS for certain domains

[Wietse Venema]

polloxx:
> Thanks to all of you.
> Now it works, although "set nowrap" in vim did not solve the issue. I had
> to add the parameters using "postconf -e".
> Is this normal?

"set nowrap" has no effect after the text is already wrapped.

Wietse

Re: is this a postfix bug or an openSUSE bug, or neither?

[Carlos E. R.]

Apararently, my previous reply has been lost. I resend.

On 2013-06-12 14:40, Wietse Venema wrote:
> Carlos E. R.:

> 
> Does the machine have a network interface with IP address 127.0.0.2?

Dunno. I guess not, because it is not listed in ifconfig output.
However, they tell me that any address in the entire 127 range is valid,
no need to explicitly create the 127.0.0.2 interface.


> If such an interface does not exist, then it must not be specified
> in inet_interfaces.
> 
> BTW the Postfix built-in default inet_interfaces settting is:
> 
>   inet_interfaces = all
> 
> You might give that a try. It works for everyone else.

Yes, that works. And removing the 127.0.0.2 entry also works, which is
what I do.


> If your distributor changes this and introduces a problem, then
> that is your distributor's problem.

openSUSE default appears to be:

inet_interfaces = localhost

which should be changed by YaST mail module, when "accept remote SMTP
connection" is ticked.


Let me rephrase this.

If I set «inet_interfaces = all», postfix will work with all the
available interfaces, whatever they are. If I set «inet_interfaces =
$myhostname, localhost», then localhost must translate to an existing
interface(s). And 127.0.0.2 is not a valid interface because... why?

That's the part I'm missing. Maybe because it is not listed here:

Telcontar:~ # ifconfig | grep 127
  inet addr:127.0.0.1  Mask:255.0.0.0
Telcontar:~ #


is that it?



-- 
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)

Re: How to check client certifications?

[Viktor Dukhovni]

On Wed, Jun 12, 2013 at 03:02:40PM +0200, Peter Bauer wrote:

> I got a connection from someone with a client certification:
>
> Received: from foo.bar (foo.bar [10.0.0.1])
> (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
> (Client CN "mail.foo.bar", Issuer "StartCom Class 1 Primary 
> Intermediate Server CA" (not verified))
> by myserver.com (Postfix) with ESMTPS id 62A9141C05A4
> for ; Wed, 12 Jun 2013 14:46:07 +0200 (CEST)
> 
> My problem is the following entry in the header:
>
> -> (not verified)

This means the corresponding root CA was not in your CAfile or CApath, or
the client configuration neglected to include the required intermediate CA
certificates.

> I would like to verify the fingerprint of this client certificate
> of the incoming connection.

The fingerprint is always "verified", in the sense that its authenticity
is never in doubt.  What would you like to do with an authentic fingerprint?

> At least it would be fine if the certificate could be checked.

The validity of its trust chain was checked, and verification failed that's
what "not verified" means.

> I have not found any option how to tell postfix to check client
> connection certificates (I mean incoming TLS connections).

Check for what?  See my previous post.

-- 
Viktor.

Re: How to check client certifications?

[Viktor Dukhovni]

On Wed, Jun 12, 2013 at 03:23:38PM +0200, Jeroen Geilman wrote:

> On 06/12/2013 03:02 PM, Peter Bauer wrote:
> >
> >How can I check the certificate of the incoming email? By
> >fingerprint would be nice. And I would like to refuse it if check
> >fails.
> 
> http://www.postfix.org/TLS_README.html#server_vrfy_client

Also

http://www.postfix.org/postconf.5.html#check_ccert_access
http://www.postfix.org/postconf.5.html#reject_plaintext_session

That said, the text below was written around 2005 (for Postfix
2.3), and remains equally applicable today.  The OP's desire to
use TLS fingerprint security for "inbound" mail is largely misguided,
DKIM is likely a better option for message origin authentication
(and even that has limited benefits).  TLS is a hop-by-hop
transmission-channel security mechanism, while origin authentication
is an end-to-end problem.

http://www.postfix.org/TLS_README.html#client_tls_limits

...

An important SMTP-specific observation is that a public MX host
is even more at the mercy of the SMTP client than is an HTTPS
server. Not only can it not enforce due care in the client's
use of TLS, but it cannot even enforce the use of TLS, because
TLS support in SMTP clients is still the exception rather than
the rule. One cannot, in practice, limit access to one's MX
hosts to just TLS-enabled clients. Such a policy would result
in a vast reduction in one's ability to communicate by email
with the world at large.

One may be tempted to try to enforce TLS for mail from specific
sending organizations, but this, too, runs into obstacles. One
such obstacle is that we don't know who is (allegedly) sending
mail until we see the "MAIL FROM:" SMTP command, and at that
point, if TLS is not already in use, a potentially sensitive
sender address (and with SMTP PIPELINING one or more of the
recipients) has (have) already been leaked in the clear. Another
obstacle is that mail from the sender to the recipient may be
forwarded, and the forwarding organization may not have any
security arrangements with the final destination. Bounces also
need to be protected. These can only be identified by the IP
address and HELO name of the connecting client, and it is
difficult to keep track of all the potential IP addresses or
HELO names of the outbound email servers of the sending
organization.

Consequently, TLS security for mail delivery to public MX hosts
is almost entirely the client's responsibility. The server is
largely a passive enabler of TLS security, the rest is up to
the client.

-- 
Viktor.

Re: Using TLS for certain domains

[polloxx]

Thanks to all of you.
Now it works, although "set nowrap" in vim did not solve the issue. I had
to add the parameters using "postconf -e".
Is this normal?

Now I see "250-STARTTLS" when I telnet to the server on port 25.
Is there another way to test if the setup works?


On Wed, Jun 12, 2013 at 2:46 PM, Wietse Venema  wrote:

> polloxx:
> > local_header_rewrite_clients = static:all  smtp_tls_CAfile =
> > /etc/postfix/cacert.pemsmtp_tls_session_cache_database =
> >  btree:/mailout/var/spool/postfix/smtp_tls_session_cache
> >  smtp_tls_security_level = maysmtp_use_tls = yessmtpd_tls_CAfile
> > =
> > /etc/postfix/cacert.pemsmtpd_tls_cert_file =
> > /etc/postfix/company-cert.pemsmtpd_tls_key_file =
> > /etc/postfix/company-key.pemsmtpd_tls_received_header = yes
> >  smtpd_tls_session_cache_database =
> >  btree:/mailin/var/spool/postfix/smtpd_tls_session_cache
> >  smtpd_tls_security_level = maysmtpd_use_tls = yes
>
> Victor:
> > There's your problem, this is all just one big single setting.  Don't
> > edit Postfix configuration files with editors that display  as
> > a new line.
>
> polloxx:
> > I use vim to edit the Postfix config. What should I use?
>
> The above text was word-wrapped. vim does that only when
> you told it to do that.
>
> The above should look be formatted as:
>
> local_header_rewrite_clients = static:all
> smtp_tls_CAfile = /etc/postfix/cacert.pem
> smtp_tls_session_cache_database =
> btree:/mailout/var/spool/postfix/smtp_tls_session_cache
> smtp_tls_security_level = may
> smtp_use_tls = yes
> smtpd_tls_CAfile = /etc/postfix/cacert.pem
> smtpd_tls_cert_file = /etc/postfix/company-cert.pem
> smtpd_tls_key_file = /etc/postfix/company-key.pem
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_database =
> btree:/mailin/var/spool/postfix/smtpd_tls_session_cache
> smtpd_tls_security_level = may
> smtpd_use_tls = yes
>
> Wietse
>

Re: question about postfix queue scheduler

[Wietse Venema]

> If he can just use a (sender-dependent) transport to send his 
> newsletter to, that would take care of the blockage, wouldn't it ?

Yes, provided that he does not saturate the active queue.  There
is, however, no need to cripple this transport with single-recipient
deliveries.  If one delivery transaction can transfer more than one
recipient, then that will shorten the time that this mail occupies
the queue.

Wietse

Re: How to check client certifications?

[Jeroen Geilman]

On 06/12/2013 03:02 PM, Peter Bauer wrote:

I got a connection from someone with a client certification:
Received: from foo.bar (foo.bar [10.0.0.1])
 (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "mail.foo.bar", Issuer "StartCom Class 1 Primary Intermediate 
Server CA" (not verified))
 by myserver.com (Postfix) with ESMTPS id 62A9141C05A4
 for ; Wed, 12 Jun 2013 14:46:07 +0200 (CEST)

My problem is the following entry in the header:
-> (not verified)

I would like to verify the fingerprint of this client certificate of the 
incoming connection.
At least it would be fine if the certificate could be checked.

I have not found any option how to tell postfix to check client connection 
certificates (I mean incoming TLS connections).

How can I check the certificate of the incoming email? By fingerprint would be 
nice. And I would like to refuse it if check fails.



http://www.postfix.org/TLS_README.html#server_vrfy_client

--
J.

Re: question about postfix queue scheduler

[Jeroen Geilman]

On 06/08/2013 08:17 PM, Wietse Venema wrote:

Jeroen Geilman:

On 06/04/2013 02:20 PM, Erwan David wrote:

On Tue, Jun 04, 2013 at 01:44:46PM CEST, Tom Hendrikx  said:

On 06/04/2013 01:22 PM, Antonio Guti?rrez Mayoral wrote:

Hi Wietse,

Yes, its a solution, but these emails should be delivered in
bussines-time :-(
(it doesnt matter if it takes 2 hours... but in bussiness time...)

thank you so much!


You could run a script as a cronjob that queues x messages when the
active queue contains (100 minus x) messages (where 100 is an arbitrary
number). This means that all mails on HOLD trickle out as quick as
possible, while not overloading the active queue...

It means when the queue has 100 messages, you stop sending anything ?


You could check the headers for identifying features (maybe the list ID,
or a subject part, or...whatever works), and instantly DEFER them.

This will put all messages in the deferred queue, guaranteeing they
won't choke incoming: if the deferred queue is not empty, one message
will be taken from incoming and deferred, in turn.

Currently the queue manager can group recipients into jobs when
they share the same queue file, and uses that to prevent a limited
number of many-recipient messages from blocking later email
with fewer recipients.

The fix would be to group recipients into jobs based on the sender
attribute (or size, or whatever) and apply similar logic to prevent
a limited messages from one sender from blocking later email from
other senders (or or to prevent large messages from blocking later
messages that are smaller in size).

However if one sender manages to saturate the queue then it will
take time before other email gets a chance to be scheduled.

Wietse



I thought the queue manager took one message each from deferred and 
incoming if deferred is not empty, keyed on the destination next-hop 
(resulting in one "virtual queue" per destination); this allows one to 
manipulate the way messages are queued by limiting the number of 
recipients per message.


If he can just use a transport with a single-recipient limit to send his 
newsletter to, that would take care of the blockage, wouldn't it ?


The queue manager doesn't combine multiple queue messages AFAIK, so even 
if there are hundreds of large single-recipient messages with the same 
next-hop in the deferred queue, it would only take one message (plus its 
one recipient) every time, and a single message from incoming after that.


--
J.

How to check client certifications?

[Peter Bauer]

I got a connection from someone with a client certification:
Received: from foo.bar (foo.bar [10.0.0.1])
(using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mail.foo.bar", Issuer "StartCom Class 1 Primary 
Intermediate Server CA" (not verified))
by myserver.com (Postfix) with ESMTPS id 62A9141C05A4
for ; Wed, 12 Jun 2013 14:46:07 +0200 (CEST)

My problem is the following entry in the header:
-> (not verified)

I would like to verify the fingerprint of this client certificate of the 
incoming connection.
At least it would be fine if the certificate could be checked.

I have not found any option how to tell postfix to check client connection 
certificates (I mean incoming TLS connections).

How can I check the certificate of the incoming email? By fingerprint would be 
nice. And I would like to refuse it if check fails.

-- 
Best regards,
Peter Bauer
Linux & UNIX developper

Re: Using TLS for certain domains

[Wietse Venema]

polloxx:
> local_header_rewrite_clients = static:all  smtp_tls_CAfile =
> /etc/postfix/cacert.pemsmtp_tls_session_cache_database =
>  btree:/mailout/var/spool/postfix/smtp_tls_session_cache
>  smtp_tls_security_level = maysmtp_use_tls = yessmtpd_tls_CAfile
> =
> /etc/postfix/cacert.pemsmtpd_tls_cert_file =
> /etc/postfix/company-cert.pemsmtpd_tls_key_file =
> /etc/postfix/company-key.pemsmtpd_tls_received_header = yes
>  smtpd_tls_session_cache_database =
>  btree:/mailin/var/spool/postfix/smtpd_tls_session_cache
>  smtpd_tls_security_level = maysmtpd_use_tls = yes

Victor:
> There's your problem, this is all just one big single setting.  Don't
> edit Postfix configuration files with editors that display  as
> a new line.

polloxx:
> I use vim to edit the Postfix config. What should I use?

The above text was word-wrapped. vim does that only when
you told it to do that.

The above should look be formatted as:

local_header_rewrite_clients = static:all  
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_session_cache_database = 
btree:/mailout/var/spool/postfix/smtp_tls_session_cache 
smtp_tls_security_level = may
smtp_use_tls = yes
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_cert_file = /etc/postfix/company-cert.pem
smtpd_tls_key_file = /etc/postfix/company-key.pem
smtpd_tls_received_header = yes 
smtpd_tls_session_cache_database = 
btree:/mailin/var/spool/postfix/smtpd_tls_session_cache 
smtpd_tls_security_level = may
smtpd_use_tls = yes

Wietse

Re: is this a postfix bug or an openSUSE bug, or neither?

[Wietse Venema]

Carlos E. R.:
> Situation:
> 
> When configuring the network in YaST, ifup method (openSUSE Linux), it
> may create an entry like this in /etc/hosts (the very last line):
> 
> 127.0.0.1  localhost
> 192.168.1.2some_host.some_domain some_host
> 127.0.0.2  some_host.some_domain some_host
> 
> 
> The /etc/postfix/main.cf contains this entry:
> 
> inet_interfaces = $myhostname, localhost
> 
> 
> 
> This combination produces this error in the mail log, repeatedly:
> 
> > <2.2> 2013-06-09 20:02:43 Telcontar postfix 13109 - -  fatal:
> > parameter inet_interfaces: no local interface found for 127.0.0.2
> > <2.2> 2013-06-09 20:02:44 Telcontar postfix 13112 - -  fatal:
> > parameter inet_interfaces: no local interface found for 127.0.0.2
> > <2.2> 2013-06-09 20:02:45 Telcontar postfix 13117 - -  fatal:
> > parameter inet_interfaces: no local interface found for 127.0.0.2

Does the machine have a network interface with IP address 127.0.0.2?

If such an interface does not exist, then it must not be specified
in inet_interfaces.

BTW the Postfix built-in default inet_interfaces settting is:

inet_interfaces = all

You might give that a try. It works for everyone else.

If your distributor changes this and introduces a problem, then
that is your distributor's problem.

Wietse

Wietse

Re: Using TLS for certain domains

[polloxx]

I use vim to edit the Postfix config. What should I use?


On Tue, Jun 11, 2013 at 10:28 PM, Viktor Dukhovni <
postfix-us...@dukhovni.org> wrote:

> On Tue, Jun 11, 2013 at 09:34:38PM +0200, polloxx wrote:
>
> > no luck yet.
> >
> > local_header_rewrite_clients = static:all  smtp_tls_CAfile =
> > /etc/postfix/cacert.pemsmtp_tls_session_cache_database =
> >  btree:/mailout/var/spool/postfix/smtp_tls_session_cache
> >  smtp_tls_security_level = maysmtp_use_tls = yessmtpd_tls_CAfile
> =
> > /etc/postfix/cacert.pemsmtpd_tls_cert_file =
> > /etc/postfix/company-cert.pemsmtpd_tls_key_file =
> > /etc/postfix/company-key.pemsmtpd_tls_received_header = yes
> >  smtpd_tls_session_cache_database =
> >  btree:/mailin/var/spool/postfix/smtpd_tls_session_cache
> >  smtpd_tls_security_level = maysmtpd_use_tls = yes
>
> There's your problem, this is all just one big single setting.  Don't
> edit Postfix configuration files with editors that display  as
> a new line.
>
> --
> Viktor.
>

is this a postfix bug or an openSUSE bug, or neither?

[Carlos E. R.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

new here.


Situation:

When configuring the network in YaST, ifup method (openSUSE Linux), it
may create an entry like this in /etc/hosts (the very last line):

127.0.0.1  localhost
192.168.1.2some_host.some_domain some_host
127.0.0.2  some_host.some_domain some_host


The /etc/postfix/main.cf contains this entry:

inet_interfaces = $myhostname, localhost



This combination produces this error in the mail log, repeatedly:

> <2.2> 2013-06-09 20:02:43 Telcontar postfix 13109 - -  fatal:
> parameter inet_interfaces: no local interface found for 127.0.0.2 
> <2.2> 2013-06-09 20:02:44 Telcontar postfix 13112 - -  fatal:
> parameter inet_interfaces: no local interface found for 127.0.0.2 
> <2.2> 2013-06-09 20:02:45 Telcontar postfix 13117 - -  fatal:
> parameter inet_interfaces: no local interface found for 127.0.0.2


People have requested that YaST behaviour be changed, several years ago:





with several bugzillas opened, none solved. I have reopened the issue.
I got replies that this is not an openSUSE fault, but a postfix fault:

> 
>
> 



Are they right, is this a postfix bug? I'd like an answer (a
categorical answer if possible) so that I can point them to it, or
drop the issue if it is postfix fault. Or neither, a misconfiguration
on my side (no, the /etc/hosts file would not be my fault, that's the
contended openSUSE bug).

Thanks :-)

- -- 
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 "Dartmouth" at Telcontar)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlG4W+sACgkQIvFNjefEBxohQgCgxrJByiBMWsKML+2v7OiWnwEz
iTYAmQFgT27mKluLoX91G/zNjVgvUzEd
=OciE
-END PGP SIGNATURE-

Fingerprint checks in both directions and email header logging?

[Peter Bauer]

I just configured a tls policy map with a fingerprint check on my server to 
communicate securely with the SMTP server of a friend of me.
It works fine. If fingerprint check fails on sending out the mail, it will be 
deferred.

However there are three points which I don't understand:
1. Why my server does not check the fingerprint for incoming emails. Why its 
only checked for outgoing mails?
Normally it could check the fingerprint of my friend SMTP server in both 
directions?

2. Could it be possible to add the fingerprint of any TLS connection in the 
each email header?
Then I could add more fingerprint verifications in my TLS policy map list 
without asking my friends all the time to run complex
openssl commands to get the SHA1 fingerprint.

Like so:
Received: from xyz.tld (xyz.tld [10.0.0.1])
(using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits),
SHA1 fingerprint 
12:54:D1:D4:4F:C9:E3:DC:F3:D7:66:B0:B8:7E:87:0B:01:73:C2:AA)
(No client certificate requested)
by foobar.com (Postfix) with ESMTPS id 014B043C15A6
for ; Wed, 12 Jun 2013 12:00:25 +0200 (CEST)

3. If fingerprint could be checked for incoming connections, could it be 
possible to add in the email header that fingerprint has been
checked? I know that failed checks will be rejected directly then on smtpd side 
with a error code 550 or something like that.
But I would like to be informed if an email has been checked, to be sure that 
the system is configured correctly, and that I did not
forgot a domain.
It could look so in the email header:
TLS-Fingerprint-Check: PASSED

-- 
Best regards,
Peter Bauer
Linux & UNIX developper