[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy

[Emmanuel Fusté via Postfix-users]

Le 22/05/2024 à 12:35, Greg Sims via Postfix-users a écrit :

Thank you again for your feedback on this issue.

I watched the workload in real time this morning and now have more
insight into what is happening.  It appears the large ISPs are using
TLS connection as a way to throttle incoming traffic.  I looked at the
inbound mail queue and found most of the traffic going to gmail.com.
I believe this is because of the 20 & 25 seconds delays google.com is
injecting into the TLS connection.  I can also see no delays for the
smaller ISPs with little traffic.  Please see some data below.

Best, Greg

This is a sample of delays= for google.com -- 20 and 25 second delays:

   0.01/11/20/0.73,
   0.01/9.5/20/0.77,
   0.01/0/25/0.74,
   0.01/7.6/25/0.91,
   0.01/6.9/25/1.1,
   0.01/13/20/4.6,
   0.01/14/25/0.56,
   0.01/14/25/1.1,
   0.01/0/0.22/0.72,
   0.01/0/0.39/0.79,

Here are delays= from yahoo -- 5.3 second delays:

   0.01/0/10/4.1,
   0.05/0/5.1/0.95,
   0.01/0/5.2/0.68,
   0.01/0/5.3/0.57,
   0.01/0/0.45/0.42,
   0.01/0/5.3/0.42,
   0.01/0/5.3/0.34,
   0.01/0.39/5.1/0.73,
   0.01/0/1.2/2,
   0.01/0/5.3/0.34,

And from icloud -- little delay:

   0.01/0/0.14/2.5,
   0.01/0.02/0.15/2.7,
   0.01/0/0.34/11,
   0.01/0/0.13/4.9,
   0.01/0/0.06/4.1,
   0.01/0/0.13/1.5,

Check all your public DNS records/config  which concern you outboud 
server : PTR, A  of your public IP, A and possibly PTR of your EHLO name 
if different. SPF/DKIM/DMARC record of the outgoing Mail From 
envelope/From header.


Could be caused by bad records or DNS missconfiguration/blackhole or DNS 
interoperability issues when distant check your configuration. For the 
TCP session establishment check PTR/A/and A of the returned PTR if 
different first.


But it could be a client issue too. So a complete hosts tcpdump or 
debug_peer_list session for selected test email (use a user defined 
specific test transport to enable debug_peer on a specific email 
address) would produce more interesting timing trace.


Emmanuel.___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix using proxy protocol outbound?

[Emmanuel Fusté via Postfix-users]

Le 21/12/2023 à 10:03, Joachim Lindenberg via Postfix-users a écrit :

Emmanuel,
please read the thread 
https://www.mail-archive.com/postfix-users@postfix.org/msg100852.html  from the 
beginning. SOCKS5 was already considered as an alternative to proxy protocol.
If you want to bash nginx then please provide some substance. I am running 
multiple instances of web servers and proxies in and out to my satisfaction.
And it is my decision what level of security I want and also how to achieve 
that. There are reasons why I am not using gmail and also why I don´t want to 
run an external relay, mostly because I consider my emails private to the 
extend I can influence.

Hello,
Yes I closely following the list. I have read all the thread.
I don't bash nginx. I use nginx at very big scale all days a week for my 
work for what it is design to.
Having worked for years for governmental organizations, I perfectly 
understand your security/privacy concern too.
What I am saying is that your problem could be solved today at the 
network level or by using a relay. Each having pros and cons.
What you want need some development in postfix and good design choice 
should be taken.


What you need is a "TCP" proxy. What I am saying is that nginx is not a 
good candidate. Nginx is mainly a buffering HTTP proxy/reverse proxy 
and/or a HTTP TLS termination endpoint or raw N to 1 TCP proxy.
You don't want a relay because of privacy so you don't want TLS 
termination you want nginx acting as a pure raw tcp relay for outbound 
SMTP (1 to N) for which no standard/protocol exist (proxy CONNECT is 
clearly too coarse).
There is a standard for pure raw tcp relaying: SOCKS5. That why I think 
that IF something should be developed/implemented in postfix for 
outbound, SOCKS5 is one of the best candidate, better than HTTP proxy 
protocol.


I think that I have said all of what I could to help about this subject. 
Take it for what it is or not.


Regards,
Emmanuel.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix using proxy protocol outbound?

[Emmanuel Fusté via Postfix-users]

Le 20/12/2023 à 21:25, Joachim Lindenberg via Postfix-users a écrit :

Emmanuel :

That's crazy, If you're able to run a dedicated proxy instance, you're able to 
run an outboud postfix instance too: the perfect proxy software for 
smtp/postfix is postfix.
Otherwise it means that you're trying to solve your use-case at the wrong level 
and that should be dealt at the network firewall/advanced routing level.

It is not. As I wrote earlier:

The key benefit to guys like me is that one doesn´t have to manage two 
instances, considering setup and maintenance, configuration (like tls 
policies), backup or just trust in your provider.
No I persist, your supposed simplification is pure nightmare. Do proper 
setup one time and your maintenance will be minimal. You will have to do 
the same postfix maintenance locally if your "tcp" proxy is in place.



I only need to solve a networking issue. And I wrote that before as well:
On this too. If it is a networking issue, deal with it at the network 
level. Do tunneling to your VPS, do IPv6 routing do whatever is need.
Yes it could be complicated, but if maintaining a simple outbound only 
postfix is too complicated for you, the cause is already lost.
Proxy is not a magic word. This is a concept. In the SMTP world the 
"proxy" is a SMTP relay.
Don't try to transpose what you see in the HTTP world to SMTP, that is 
not because proxy/reverse proxy are common tools in the HTTP world that 
the same tool could apply as is in another protocol proxying scenario.

HTTP is/support stateless end to end synchronous operations.
SMTP is a statefull protocol oriented for asynchronous end to end 
operations.


What you want is a pure dedicated TCP proxy protocol. It is the only 
viable solution for robust outbound traffic. Forget nginx hacks. What 
you really want is full SOCKS5 support in the postfix smtp client.


Inbound problem is very simple, the hard one as you see is the outbound one.

Emmanuel.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Postfix using proxy protocol outbound?

[Emmanuel Fusté via Postfix-users]

Le 20/12/2023 à 20:53, Joachim Lindenberg via Postfix-users a écrit :

Wietse:

Obviously, nginx will not know the Postfix SMTP client protocol stage, and the 
nginx settings will have to match the largest
Postfix timeouts to avoid persistent mail delivery problems with some sites.
Settings optimal for Postfix may conflict with 'web' proxy usage.

There is no need to share the same proxy configuration for smtp delivery and 
web access. Setting up multiple proxies is only few lines of configuration and 
each can have their own timeouts.
That's crazy, If you're able to run a dedicated proxy instance, you're 
able to run an outboud postfix instance too: the perfect proxy software 
for smtp/postfix is postfix.
Otherwise it means that you're trying to solve your use-case at the 
wrong level and that should be dealt at the network firewall/advanced 
routing level.


Emmanuel.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: new waves of connect/disconnect from *.outlook.com; any add'l pfx configs useful for further remediation?

[Emmanuel Fusté via Postfix-users]

Le 15/08/2023 à 23:12, Viktor Dukhovni via Postfix-users a écrit :

On Tue, Aug 15, 2023 at 04:14:58PM -0400, pgnd via Postfix-users wrote:


2023-08-14T13:11:53.782611-04:00 svr01 postfix/postscreen[27910]: CONNECT from 
[52.101.56.17]:32607 to [209.123.234.54]:25
2023-08-14T13:11:59.860098-04:00 svr01 postfix/postscreen[27910]: PASS NEW 
[52.101.56.17]:32607
2023-08-14T13:12:00.058029-04:00 svr01 
postfix/postscreen-internal/smtpd[27907]: connect from 
mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]
2023-08-14T13:12:00.118201-04:00 svr01 
postfix/postscreen-internal/smtpd[27907]: Anonymous TLS connection established 
from mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17]: 
TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
2023-08-14T13:12:00.131049-04:00 svr01 
postfix/postscreen-internal/smtpd[27907]: disconnect from 
mail-eastus2azon11020017.outbound.protection.outlook.com[52.101.56.17] ehlo=1 
starttls=1 quit=1 commands=3

Perhaps they don't like your certificate and disconnect once the
handshake completes.


I second that.
But as outbound policy could be personalized by client/tenant hosted on 
O365 you're lost until someone start winning at you by another channel 
or retract the offending specific configuration, all conditioned by logs 
inspections and/or end user complains on their side.

Already run into here.

Emmanuel.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: MX load balancing

[Emmanuel Fusté via Postfix-users]

Le 30/05/2023 à 16:07, Benny Pedersen via Postfix-users a écrit :

Viktor Dukhovni via Postfix-users skrev den 2023-05-30 14:30:


There's no good reason to have mail sent to mx2 unless mx1 is down.


and subject says load balancing, not backup mx

imho OP asked not to have mx backup, but load balancing, in with case 
HA-Proxy would help more


also if load balancing it makes no sense to add one more mx, but add 
one more ip to first mx, if OP don't have expansive hardware load 
balances



Off-topic or not, your advice is BAD.
Adding one more IP to first MX completely defeat the build-in native HA 
and LB mechanism provided by SMTP since ages.
If one IP is down and the client try to connect to it the MX will be 
declared dead and you will be subject to queue retry timer, potentially 
multiple time with back-off with DNS RR unluck.
With two MX with same weight you will get instant delivery to the other 
MX and natural LB nominally.
With two MX with different weight you will get instant delivery to the 
next MX if the lower one is down.
No need HA-proxy, no need of expensive hw lb. They are only needed in 
high volumes, high SMTP front end count (LB backends) scenario.

Multiple IP on a MX target FQDN is a really bad practice.

Emmanuel.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: invalid and non-fqdn hostname

[Emmanuel Fusté via Postfix-users]

Le 06/04/2023 à 16:44, Emmanuel Fusté a écrit :

Le 06/04/2023 à 14:09, Emmanuel Fusté a écrit :

Le 06/04/2023 à 13:35, Ken Peng via Postfix-users a écrit :

On 2023-04-06 19:07, Jaroslaw Rafa via Postfix-users wrote:



I just now learned about the UTF8 thing, I would never think of using
non-ASCII characters in host/domain names :)


You can dig the UTF8 hostname, they are valid for query.

$ dig 腾讯.公司 ns +short
ns1.brandcloudns.com.
ns2.brandcloudns.com.
ns3.brandcloudns.com.

:)

Yes but no your UTF8 hostname is punicoded on your back before 
going to the dns system.


dig 腾讯.公司 +noidnout +noall +question +answer ns
;xn--r70as2s.xn--55qx5d.    IN  NS
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns1.brandcloudns.com.
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns3.brandcloudns.com.
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns2.brandcloudns.com.

They are in fact plain acsii fully qualified hostnames, the utf8 is 
just a displaying game.
As SMTP preclude idn, a conservative approach is that a client 
wanting to pass utf8 fqdn hostname should encode it with idn as for 
the DNS/as it get it from DNS.
In the context of HELO/EHLO, the DNS processed hostname should still 
be plain ascii.
If we are ignoring the remaining IDNA2003 UTF8 domains corner case 
(which are practically unusable in real world if there is still 
sommes), there is no good reason to see utf8 fqdn in the HELO/EHLO 
context.
And this corner case does not exist ... see Vicktor message. I should 
had verified the content of IDNA2003 vs 2008.

Viktor, sorry ...



Postfix is right.



___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: invalid and non-fqdn hostname

[Emmanuel Fusté via Postfix-users]

Le 06/04/2023 à 14:09, Emmanuel Fusté a écrit :

Le 06/04/2023 à 13:35, Ken Peng via Postfix-users a écrit :

On 2023-04-06 19:07, Jaroslaw Rafa via Postfix-users wrote:



I just now learned about the UTF8 thing, I would never think of using
non-ASCII characters in host/domain names :)


You can dig the UTF8 hostname, they are valid for query.

$ dig 腾讯.公司 ns +short
ns1.brandcloudns.com.
ns2.brandcloudns.com.
ns3.brandcloudns.com.

:)

Yes but no your UTF8 hostname is punicoded on your back before 
going to the dns system.


dig 腾讯.公司 +noidnout +noall +question +answer ns
;xn--r70as2s.xn--55qx5d.    IN  NS
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns1.brandcloudns.com.
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns3.brandcloudns.com.
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns2.brandcloudns.com.

They are in fact plain acsii fully qualified hostnames, the utf8 is 
just a displaying game.
As SMTP preclude idn, a conservative approach is that a client wanting 
to pass utf8 fqdn hostname should encode it with idn as for the DNS/as 
it get it from DNS.
In the context of HELO/EHLO, the DNS processed hostname should still 
be plain ascii.
If we are ignoring the remaining IDNA2003 UTF8 domains corner case 
(which are practically unusable in real world if there is still 
sommes), there is no good reason to see utf8 fqdn in the HELO/EHLO 
context.
And this corner case does not exist ... see Vicktor message. I should 
had verified the content of IDNA2003 vs 2008.



Postfix is right.


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: invalid and non-fqdn hostname

[Emmanuel Fusté via Postfix-users]

Le 06/04/2023 à 13:35, Ken Peng via Postfix-users a écrit :

On 2023-04-06 19:07, Jaroslaw Rafa via Postfix-users wrote:



I just now learned about the UTF8 thing, I would never think of using
non-ASCII characters in host/domain names :)


You can dig the UTF8 hostname, they are valid for query.

$ dig 腾讯.公司 ns +short
ns1.brandcloudns.com.
ns2.brandcloudns.com.
ns3.brandcloudns.com.

:)

Yes but no your UTF8 hostname is punicoded on your back before going 
to the dns system.


dig 腾讯.公司 +noidnout +noall +question +answer ns
;xn--r70as2s.xn--55qx5d.    IN  NS
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns1.brandcloudns.com.
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns3.brandcloudns.com.
xn--r70as2s.xn--55qx5d. 3600    IN  NS ns2.brandcloudns.com.

They are in fact plain acsii fully qualified hostnames, the utf8 is just 
a displaying game.
As SMTP preclude idn, a conservative approach is that a client wanting 
to pass utf8 fqdn hostname should encode it with idn as for the DNS/as 
it get it from DNS.
In the context of HELO/EHLO, the DNS processed hostname should still be 
plain ascii.
If we are ignoring the remaining IDNA2003 UTF8 domains corner case 
(which are practically unusable in real world if there is still sommes), 
there is no good reason to see utf8 fqdn in the HELO/EHLO context.

Postfix is right.

Emmanuel.


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: none SRS issues

[Emmanuel Fusté]

Le 12/01/2023 à 19:45, post...@ptld.com a écrit :
No SPF is OK, but as long as the domain of RFC822 MAIL FROM address 
has a SPF, this SPF must pass.


DMARC will pass as long as either SPF or DMARC passes.
DMARC will still pass if SPF fails and DKIM passes.

I think you might be misinterpreting what you are reading.
Regardless, in practice in the real world, that is how it works.
That is what the OpenDMARC software does. That is what gmail does.


    https://www.rfc-editor.org/rfc/rfc7489#section-4.2
    A message satisfies the DMARC checks if at least ONE OF the 
supported authentication mechanisms: produces a "pass" result, and ... 
is in alignment



Ok, checked in the code.
The described behavior is in my case caused by other reasons (even not 
SPF enforcement at the SPF level).


Emmanuel.

Re: none SRS issues

[Emmanuel Fusté]

Le 12/01/2023 à 18:17, Emmanuel Fusté a écrit :

Le 12/01/2023 à 17:51, Wietse Venema a écrit :

Emmanuel Fust?:

Le jeu. 12 janv. 2023, 17:15,  a ?crit :

Since I am using SPF as a validation method, the non-srs messages 
from
those big providers will have possibility to break SPF and be 
rejected by

our systems.

Do you reject based on solely the SPF result? It would be better to 
use
DMARC, have SPF only create the auth header and not reject, then 
let DMARC

evaluate and decide to reject or not.

DMARC will look for any DKIM signatures and if a signature is valid 
DMARC

will accept the email even when SPF fails due to forwarding.


No. If SPF fail DMARC will fail too.

No. If DKIM passes then DMARC should too (ncessary and sufficient).

Wietse
Yes, necessary and sufficient, but any fail will result in a final 
fail : If SPF none & DKIM pass => pass. If SPF fail, it will fail even 
if DKIM passes.

RFC7489, section 6.6.2, 4) an 5)
Especially "All other conditions (authentication failures, identifier 
mismatches) are considered to be DMARC mechanism check failures."


No SPF is OK, but as long as the domain of RFC822 MAIL FROM address 
has a SPF, this SPF must pass.
On top of that DMARC will check the alignment of this domain with the 
domain of the RFC5322 From address with the published DMARC policy SPF 
requirement (aspf) strict or relaxed.
For to address the forwarding problem, you should add ARC to the sending 
and verifying stack, It was designed specifically for that, but not 
widely used, it is pretty experimental.


Emmanuel.

Re: none SRS issues

[Emmanuel Fusté]

Le 12/01/2023 à 17:51, Wietse Venema a écrit :

Emmanuel Fust?:

Le jeu. 12 janv. 2023, 17:15,  a ?crit :


Since I am using SPF as a validation method, the non-srs messages from

those big providers will have possibility to break SPF and be rejected by
our systems.

Do you reject based on solely the SPF result? It would be better to use
DMARC, have SPF only create the auth header and not reject, then let DMARC
evaluate and decide to reject or not.

DMARC will look for any DKIM signatures and if a signature is valid DMARC
will accept the email even when SPF fails due to forwarding.


No. If SPF fail DMARC will fail too.

No. If DKIM passes then DMARC should too (ncessary and sufficient).

Wietse
Yes, necessary and sufficient, but any fail will result in a final fail 
: If SPF none & DKIM pass => pass. If SPF fail, it will fail even if 
DKIM passes.

RFC7489, section 6.6.2, 4) an 5)
Especially "All other conditions (authentication failures, identifier 
mismatches) are considered to be DMARC mechanism check failures."


No SPF is OK, but as long as the domain of RFC822 MAIL FROM address has 
a SPF, this SPF must pass.
On top of that DMARC will check the alignment of this domain with the 
domain of the RFC5322 From address with the published DMARC policy SPF 
requirement (aspf) strict or relaxed.


Emmanuel.

Re: none SRS issues

[Emmanuel Fusté]

Le jeu. 12 janv. 2023, 17:15,  a écrit :

> > Since I am using SPF as a validation method, the non-srs messages from
> those big providers will have possibility to break SPF and be rejected by
> our systems.
>
> Do you reject based on solely the SPF result? It would be better to use
> DMARC, have SPF only create the auth header and not reject, then let DMARC
> evaluate and decide to reject or not.
>
> DMARC will look for any DKIM signatures and if a signature is valid DMARC
> will accept the email even when SPF fails due to forwarding.
>
No. If SPF fail DMARC will fail too.

Emmanuel.

Re: Dumping effective postfix configuration

[Emmanuel Fusté]

Le 06/01/2023 à 21:03, Demi Marie Obenour a écrit :

On 1/6/23 07:15, Wietse Venema wrote:

Peter Wienemann:

Hi,

is there a way to dump the effective postfix configuration rather than
the one specified in main.cf/master.cf? It seems that changes to
main.cf/master.cf have an immediate impact on the output of postconf
regardless of whether a reload/restart of the service was performed.

How would that work? Different Postfix processes start at different
times, and some processes (qmgr, master) run forever.

What about using inotify/kqueue to determine when a config file has
changed and reload accordingly?

Too dangerous and useless.
I want to issue reload for long running processes only when I want.
Periodically recycled process will take automatically the new conf when 
they restarts, inotify/kqueue is not needed for that. That is something 
you must know as a postfix user to not inadvertently crash your running 
config with half edited but saved config files.

Same expectations and warning for maps (according to their type).
For the conf files, one interesting change would be to do the opposite : 
Process only run with copies of validated conf files and new copies (+ 
process reload) are done only when explicit reload command is issued to 
avoid new conf taken by surprise on process recycling.


Emmanuel.

Re: parent_domain_matches_subdomains && smtpd_access_maps

[Emmanuel Fusté]

Le 02/01/2023 à 20:38, Laurent Frigault a écrit :

Hi,

Is there any way to have some smtpd_access_maps with
parent_domain_matches_subdomains and some other without it ?

I have :
smtpd_recipient_restrictions =
permit_mynetworks
 reject_non_fqdn_sender
 reject_unknown_sender_domain
 reject_unauth_destination
 check_sender_access hash:$config_directory/sender_access
 check_recipient_access hash:$config_directory/rcpt_recipient_access


I would like to have parent_domain_matches_subdomains in
rcpt_recipient_access and not in sender_access

Without parent_domain_matches_subdomains matching property, subdomains 
of mydomain.net are expressed as .mydomain.net.
So in parent_domain_matches_subdomains put two lines for domains for 
witch you want subdomain matching.


For sane behavior I always disable parent_domain_matches_subdomain 
matching and always use explicit subdomain matching where needed. That 
is a personal preference.


Emmanuel.

Re: no shared cipher revisited

[Emmanuel Fusté]

Le 02/10/2022 à 11:51, Matus UHLAR - fantomas a écrit :

On 10/1/22 16:16, Viktor Dukhovni wrote:

4096-bit RSA certificates mostly work, but are pointless crypto
exhibitionism, waste CPU, can run into client implementation
limitations, and so are not a good idea.


On 01.10.22 17:20, Shawn Heisey wrote:

My cert from letsencrypt is 4096 bit.


yes, Let's Encrypt clients generate 4096 keys by default, which is 
silly because intermediate R3 certificate is only 2048-bit.


Silly, yes for the common usage and totally pointless.
But keep in mind that key generation/primality test are not definitive 
primatily answer.
A very extensively tested 2048 key is more secure than a very basically 
and lightly tested  4096 key.

Key generation/test is something that is often badly neglected...

Emmanuel.

Re: Subject encoding; logs not matching header

[Emmanuel Fusté]

Le 26/08/2022 à 16:54, Emmanuel Fusté a écrit :

Le 26/08/2022 à 15:52, post...@ptld.com a écrit :

Check RFC5322, section 2.2.1 "Unstructured Header Field Bodies".
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

where 2.2.3 ("Long Header Fields") explains the "folding", e.g.

Subject: This is a test

can be represented as:

Subject: This
 is a test

After "This" you have a (quoted) space, not a CR/LF.



In RFC5322 2.2.3 it says;
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding".  Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP.  Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.  An unfolded header field has no length restriction and
therefore may be indeterminately long.


When the subject was split (folded) they did it correctly, after the 
CRLF the next line started with a WSP. So according to 2.2.3 the 
"unfolding" is accomplished by simply removing the CRLF turning


    Subject: 
=?UTF-8?B?8J+YsSBTSE9QIE5PVzogR2V0IDAlIElOVEVSRVNUIERlYWxzIHBs?=

=?UTF-8?B?dXMgZXhjbHVzaXZlIHZvdWNoZXJzIHdpdGggU1BheUxhdGVyISDwn5GJ?=

into

    Subject: 
=?UTF-8?B?8J+YsSBTSE9QIE5PVzogR2V0IDAlIElOVEVSRVNUIERlYWxzIHBs?= 
=?UTF-8?B?dXMgZXhjbHVzaXZlIHZvdWNoZXJzIHdpdGggU1BheUxhdGVyISDwn5GJ?=


I still don't understand where the extra '?' came from, nor do I see 
in RFC5322 2.2.3 where it says anything about adding or replacing 
characters. I am also still confused by what Wietse said when he 
confirmed postfix does not add characters. Then where did the extra 
'?' come from in the postfix log? How is it not a bug?




After "This" you have a (quoted) space, not a CR/LF.


I'm not getting your point. Why do you keep talking about a "quoted 
space"? The first line ends with CRLF and the second line has to 
start with a space to indicate it is a continuation of the previous 
line (folding). Why are you saying that means an '?' has to be inserted?


What you're asking for is a folding variant of the INFO target.
As stated by Wietse, Posfix will not alter the content but will 
replace non printable character (CRLF in this case) with ? in logs.

So it will not do by defaut any folding for you.

Replace folding by unfolding in my previous email 

Emmanuel.

Re: Subject encoding; logs not matching header

[Emmanuel Fusté]

Le 26/08/2022 à 15:52, post...@ptld.com a écrit :

Check RFC5322, section 2.2.1 "Unstructured Header Field Bodies".
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

where 2.2.3 ("Long Header Fields") explains the "folding", e.g.

Subject: This is a test

can be represented as:

Subject: This
 is a test

After "This" you have a (quoted) space, not a CR/LF.



In RFC5322 2.2.3 it says;
The process of moving from this folded multiple-line representation
of a header field to its single line representation is called
"unfolding".  Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP.  Each header field should be
treated in its unfolded form for further syntactic and semantic
evaluation.  An unfolded header field has no length restriction and
therefore may be indeterminately long.


When the subject was split (folded) they did it correctly, after the 
CRLF the next line started with a WSP. So according to 2.2.3 the 
"unfolding" is accomplished by simply removing the CRLF turning


    Subject: 
=?UTF-8?B?8J+YsSBTSE9QIE5PVzogR2V0IDAlIElOVEVSRVNUIERlYWxzIHBs?=

=?UTF-8?B?dXMgZXhjbHVzaXZlIHZvdWNoZXJzIHdpdGggU1BheUxhdGVyISDwn5GJ?=

into

    Subject: 
=?UTF-8?B?8J+YsSBTSE9QIE5PVzogR2V0IDAlIElOVEVSRVNUIERlYWxzIHBs?= 
=?UTF-8?B?dXMgZXhjbHVzaXZlIHZvdWNoZXJzIHdpdGggU1BheUxhdGVyISDwn5GJ?=


I still don't understand where the extra '?' came from, nor do I see 
in RFC5322 2.2.3 where it says anything about adding or replacing 
characters. I am also still confused by what Wietse said when he 
confirmed postfix does not add characters. Then where did the extra 
'?' come from in the postfix log? How is it not a bug?




After "This" you have a (quoted) space, not a CR/LF.


I'm not getting your point. Why do you keep talking about a "quoted 
space"? The first line ends with CRLF and the second line has to start 
with a space to indicate it is a continuation of the previous line 
(folding). Why are you saying that means an '?' has to be inserted?


What you're asking for is a folding variant of the INFO target.
As stated by Wietse, Posfix will not alter the content but will replace 
non printable character (CRLF in this case) with ? in logs.

So it will not do by defaut any folding for you.

Emmanuel.

Re: Mail and mail traces lost (?)

[Emmanuel Fusté]

Le 30/03/2022 à 18:36, Viktor Dukhovni a écrit :

On Wed, Mar 30, 2022 at 06:11:33PM +0200, Michael Ströder wrote:


Or simply set in /etc/systemd/journald.conf:

[Journal]
Storage=none
ForwardToSyslog=yes

That does not fully solve the problem, since IIRC rate limits and
performance limitations still apply, perhaps somewhat improved for the
latter.


Rate limiting is out of the picture.
ForwardToSyslog and other similar journald options activate raw message 
forwarding before any journald processing. This is pure socket to socket 
forwarding without any processing. No rate limiting or other processing.
I've used to use rsyslog on top of journald forwarding since years on 
Ubuntu on low end and high end machines with very high smtp/postfix 
workloads on both without any trouble.


Systemd/journald is far from perfect, but clearly not the culprit here.

Emmanuel.

Re: destination_concurrency_limit after while moving from Postfix 3.1.15 to Postfix 3.5.6

[Emmanuel Fusté]

Le 03/12/2021 à 14:48, Yves-Marie Le Pors Chauvel a écrit :

Hi folks,

I moved from Postfix 3.1.15 to 3.5.6... It was mandatory to upgrade it 
in order to remove any legacy version (OS and Postfix) !


Before that everything was perfect : respecting the limit of 
connections for a specific route per IP with connection reuse without 
TLS ! Since moving from 3.1.15 to 3.5.6, we are receiving a lot of 
‘too many connections’ deferred : 421 mwinf5c42 ME Trop de connexions, 
veuillez verifier votre configuration. Too many connections, slow 
down. OFR004_104 [104]


Here is my transport map :
#ORANGE orange.fr  orange: csp-audit.com 
 orange: franceadhesif.fr 
 orange: rgr-avocats.com 
 orange: fermedevilliers.fr 
 orange: abex-ec.fr  
orange: pyrcarto.fr  orange: agencecharles.fr 
 orange: emballagedigest.eu 
 orange: da-conseil.com 
 orange: somaris.com  
orange: auto3000sa.fr  orange: batee.fr 
 orange: dynamelec.fr  orange: 
a4architectes.com  orange: 
transports-fronton.fr  orange: 
fruitaliance.com  orange: exp-automoto.com 
 orange: aaformation.com 
 orange: aer-sa.fr  orange: 
atalentec.com  orange: bst.fr  
orange: cabinetec.fr  orange: cabinetsecom.com 
 orange: dhalluin-peny.fr 
 orange: gescomm-fr.com 
 orange: gsf-am.com  orange: 
kalyseo.fr  orange: mattholding.fr 
 orange: mktool.com  orange: 
quilico-archi.com  orange: tea-cefi.com 
 orange: tramobus.com  
orange: #WANADOO wanadoo.fr  wanadoo:

Here is part of my main.cf  :
smtp_tls_connection_reuse = yes smtp_connection_reuse_time_limit = 
100s smtp_connection_cache_time_limit = 1s
# Orange policy orange_initial_destination_concurrency =1 
orange_destination_concurrency_limit = 1 orange_destination_rate_delay 
= 0 orange_destination_recipient_limit = 10 # Wanadoo policy 
wanadoo_initial_destination_concurrency = 1 
wanadoo_destination_concurrency_limit = 1 
wanadoo_destination_rate_delay = 0 wanadoo_destination_recipient_limit 
= 10

Here is part of my master.cf  :

# 
== 
# service type private unpriv chroot wakeup maxproc command + args # 
(yes) (yes) (yes) (never) (100) # 
== 
orange unix - - y - 2 smtp wanadoo unix - - y - 1 smtp


/As you can notice maxproc = 2 for orange route, but as you know (I 
won’t learn you anything) Orange + Wanadoo is a 3 connection limit 
(recommended 2 for Orange and 1 for Wanadoo)./


I’ve asked the MBP and he confirmed that we have more than 3 
connexions at the exact same time... Does anyone know if Postfix 
changed the way it is managing connections (something like moving from 
connection limit to active connection limit ? that could be an 
explanation ==> active + idles > 3) ? For information, adding TLS or 
not, does not change this issue...


Does anyone have any advice to tune my conf in order to avoid such 
issues ? If you need more elements, feel free to ask !


Regards,


Hello,

Orange/Wanadoo setup is a mess for SMTP servers.
Take in mind that all their rate limiting is implemented at the IP/TCP 
level, not SMTP level.
Orange and Wanadoo are behind the same IPs so do not use two transport 
but only one or you will trigger the simultaneous max TCP session quota.
Use aggressive SMTP session reuse for SMTP  AND for SMTP TLS or you will 
trigger the max session per hour.


So relevant part of my config is:
main.cf : (no need to touch other default values)
slow_destination_concurrency_limit=1
smtp_tls_connection_reuse = yes

master.cf:(yes 30s is insane, but their setup too)
slow  unix  -   -   n   -   -   smtp
    -o { smtp_connection_cache_destinations = wanadoo.fr, orange.fr }
    -o smtp_connection_cache_time_limit=30

Fix your transport table :
Many entries are no longer hosted on "Orange" system.
All entries but  wanadoo.fr and orange.fr are on a different MX : 
smtppromx.orange.fr for which the rate limiting is less problematic.
So limiting your transport table with only an entry for wanadoo.fr and 
and entry for orange.fr poining to the "slow" transport should be 
sufficient.
Postfix will not exactly honor the max simultaneous connection 

Re: Fwd: Issue with Postfix and GSSAPI Authentication

[Emmanuel Fusté]

Hello,

Le 01/10/2021 à 16:17, Sam R a écrit :

Hello,

I want to set up a Postfix SMTP server with cyrus-sasl in GSSAPI mode. 
I have two Samba4 servers in AD mode, and my clients are in windows 10.

I removed the execution of Posfix in chroot to simplify.
I added two keytab in /etc/krb5.keytab smtp/smtptest.domain.fr 
 and host/smtptest.domain.fr 

Currently I can authenticate with windows credentials from a windows 
client under Thunderbird with the "normal password" settings.
But if I try to switch from LOGIN to GSSAPI ( in 
/etc/postfix/sasl/smtpd.conf ) it doesn't work.

.
on another server I just testedThunderbird for GSSAPI authentication 
against GSSAPI Dovecot imap service and it works.


As you are already familiar with the GSSAPI SASL Dovecot provider, why 
did you not try to use it with postfix ? (smtpd_sasl_type = dovecot)


Emmanuel.

Re: DANE TLSA lookup "whitelist"

[Emmanuel Fusté]

Le 05/08/2021 à 16:48, Matteo Cazzador a écrit :


Hi everybody,  i've this configuration active in postfix:

smtp_dns_support_level=dnssec
smtp_tls_security_level = dane

Is it possible to exclude some check for specific domain name ?

Something like whitelist domain name and lookup.

I use a local domain "*example.local*" i want to exclude it from dane 
check because i obtain this error:


warning: DANE TLSA lookup problem: Host or domain name not found. Name 
service error for name=_*25._tcp.example.local *type=TLSA: Host not 
found, try again


thanks


That is something that should be handled at the resolver level, not at 
the postfix level.


Emmanuel.

Re: Null sender rewrite from a specified host.

[Emmanuel Fusté]

Le 07/07/2021 à 15:41, Emmanuel Fusté a écrit :

Le 07/07/2021 à 15:36, Emmanuel Fusté a écrit :

Le 07/07/2021 à 15:26, Wietse Venema a écrit :

Emmanuel Fust?:

Le 07/07/2021 ? 15:06, Wietse Venema a ?crit?:

Viktor Dukhovni:

On Tue, Jul 06, 2021 at 12:56:50PM +0200, Xavier Beaudouin wrote:


I currently have an appliance that misuse the null sender (mail
from:<>) to send mail.

Unfortunatly, this appliance is closed source
and we can only setup : fixed ip address and recipient address 
on GUI

(nothing else, even if I try to h4x0r the configuration file).

Is there any good advice I can have to make the internal relay 
server

which is postfix based to rewrite the null sender to something
cleaner... but ONLY for the device that use postfix as internal 
relay

server?

This requires a content filter or milter, that replaces the envelope
sender address for messages from the client IP address in question.

There is no built-in feature that performs sender address rewrites
conditional on the client IP address.

The milter should be easy to implement.

There is another option:

1 - Configure a Postfix smtpd process on an additional IP addresss
  or TCP port that only this client will connect to.

2 - Configure that smtpd process with an smtpd_command_filter that
  replaces "MAIL FROM:<>" with the preferred address.

  # Listen on port 1234
  /etc/postfix/master.cf:
1234   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

  # Listen on IP address 1.2.3.4
  /etc/postfix/master.cf:
1.2.3.4:smtp   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

  /etc/postfix/command_filter:
 /^(MAIL FROM:)\s*<>/    MAIL FROM:

Wietse

And use a client_access map in smtpd_client_restriction
check_client_access with a filter action and you will transparently 
get

the intended behavior without specific client configuration.

NO FILTER is needed for the stated purpose: replace
the null sender address.

Sorry, I did not explain properly :

1 - Configure a Postfix smtpd process on an additional
 TCP port.

2 - Configure that smtpd process with an smtpd_command_filter that
 replaces "MAIL FROM:<>" with the preferred address.

 # Listen on port 1234 on localhost
 /etc/postfix/master.cf:
127.0.0.1:1234   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}
     /etc/postfix/command_filter:
    /^(MAIL FROM:)\s*<>/    MAIL FROM:

3 - Use this smtpd process as a filter for clients coming from IP 
address w.x.y.z

/etc/postfix/main.cf:
smtpd_client_restriction= check_client_access 
/etc/postfix/client_acess, .


/etc/postfix/client_acess:
    w.x.y.z    FILTER localhost:1234

And you get "null sender address rewrites conditional on the client 
IP address"




arghh no, sorry, smtp client must be added in between.
A little more complex


1 - Configure a Postfix smtpd process on an additional
 TCP port.

2 - Configure that smtpd process with an smtpd_command_filter that
 replaces "MAIL FROM:<>" with the preferred address.

 # Listen on port 1234 on localhost
 /etc/postfix/master.cf:
127.0.0.1:1234   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}
     /etc/postfix/command_filter:
    /^(MAIL FROM:)\s*<>/    MAIL FROM:

3 - Use this smtpd process as a filter for clients coming from IP 
address w.x.y.z

/etc/postfix/main.cf:
smtpd_client_restriction= check_client_access 
/etc/postfix/client_acess, .


/etc/postfix/client_acess:
    w.x.y.z    FILTER smtp:[127.0.0.1]:1234

With that, no need to change the w.x.y.z client configuration and you 
get "null sender address rewrites conditional on the client IP address"
But yes, totally useless if you change the client configuration to point 
to the new listener directly.


Emmanuel.

Re: Null sender rewrite from a specified host.

[Emmanuel Fusté]

Le 07/07/2021 à 15:36, Emmanuel Fusté a écrit :

Le 07/07/2021 à 15:26, Wietse Venema a écrit :

Emmanuel Fust?:

Le 07/07/2021 ? 15:06, Wietse Venema a ?crit?:

Viktor Dukhovni:

On Tue, Jul 06, 2021 at 12:56:50PM +0200, Xavier Beaudouin wrote:


I currently have an appliance that misuse the null sender (mail
from:<>) to send mail.

Unfortunatly, this appliance is closed source
and we can only setup : fixed ip address and recipient address on GUI
(nothing else, even if I try to h4x0r the configuration file).

Is there any good advice I can have to make the internal relay server
which is postfix based to rewrite the null sender to something
cleaner... but ONLY for the device that use postfix as internal relay
server?

This requires a content filter or milter, that replaces the envelope
sender address for messages from the client IP address in question.

There is no built-in feature that performs sender address rewrites
conditional on the client IP address.

The milter should be easy to implement.

There is another option:

1 - Configure a Postfix smtpd process on an additional IP addresss
  or TCP port that only this client will connect to.

2 - Configure that smtpd process with an smtpd_command_filter that
  replaces "MAIL FROM:<>" with the preferred address.

  # Listen on port 1234
  /etc/postfix/master.cf:
1234   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

  # Listen on IP address 1.2.3.4
  /etc/postfix/master.cf:
1.2.3.4:smtp   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

  /etc/postfix/command_filter:
 /^(MAIL FROM:)\s*<>/    MAIL FROM:

Wietse

And use a client_access map in smtpd_client_restriction
check_client_access with a filter action and you will transparently get
the intended behavior without specific client configuration.

NO FILTER is needed for the stated purpose: replace
the null sender address.

Sorry, I did not explain properly :

1 - Configure a Postfix smtpd process on an additional
 TCP port.

2 - Configure that smtpd process with an smtpd_command_filter that
 replaces "MAIL FROM:<>" with the preferred address.

 # Listen on port 1234 on localhost
 /etc/postfix/master.cf:
127.0.0.1:1234   inet ..   ..   ..   ..   ..   smtpd
    -o {smtpd_command_filter = pcre:/etc/postfix/command_filter}
     /etc/postfix/command_filter:
    /^(MAIL FROM:)\s*<>/    MAIL FROM:

3 - Use this smtpd process as a filter for clients coming from IP 
address w.x.y.z

/etc/postfix/main.cf:
smtpd_client_restriction= check_client_access 
/etc/postfix/client_acess, .


/etc/postfix/client_acess:
    w.x.y.z    FILTER localhost:1234

And you get "null sender address rewrites conditional on the client IP 
address"




arghh no, sorry, smtp client must be added in between.
A little more complex

Emmanuel.

Re: Null sender rewrite from a specified host.

[Emmanuel Fusté]

Le 07/07/2021 à 15:26, Wietse Venema a écrit :

Emmanuel Fust?:

Le 07/07/2021 ? 15:06, Wietse Venema a ?crit?:

Viktor Dukhovni:

On Tue, Jul 06, 2021 at 12:56:50PM +0200, Xavier Beaudouin wrote:


I currently have an appliance that misuse the null sender (mail
from:<>) to send mail.

Unfortunatly, this appliance is closed source
and we can only setup : fixed ip address and recipient address on GUI
(nothing else, even if I try to h4x0r the configuration file).

Is there any good advice I can have to make the internal relay server
which is postfix based to rewrite the null sender to something
cleaner... but ONLY for the device that use postfix as internal relay
server?

This requires a content filter or milter, that replaces the envelope
sender address for messages from the client IP address in question.

There is no built-in feature that performs sender address rewrites
conditional on the client IP address.

The milter should be easy to implement.

There is another option:

1 - Configure a Postfix smtpd process on an additional IP addresss
  or TCP port that only this client will connect to.

2 - Configure that smtpd process with an smtpd_command_filter that
  replaces "MAIL FROM:<>" with the preferred address.

  # Listen on port 1234
  /etc/postfix/master.cf:
1234   inet ..   ..   ..   ..   ..   smtpd
-o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

  # Listen on IP address 1.2.3.4
  /etc/postfix/master.cf:
1.2.3.4:smtp   inet ..   ..   ..   ..   ..   smtpd
-o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

  /etc/postfix/command_filter:
 /^(MAIL FROM:)\s*<>/ MAIL FROM:

Wietse

And use a client_access map in smtpd_client_restriction
check_client_access with a filter action and you will transparently get
the intended behavior without specific client configuration.

NO FILTER is needed for the stated purpose: replace
the null sender address.

Sorry, I did not explain properly :

1 - Configure a Postfix smtpd process on an additional
 TCP port.

2 - Configure that smtpd process with an smtpd_command_filter that
 replaces "MAIL FROM:<>" with the preferred address.

 # Listen on port 1234 on localhost
 /etc/postfix/master.cf:
127.0.0.1:1234   inet ..   ..   ..   ..   ..   smtpd
-o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

 /etc/postfix/command_filter:

/^(MAIL FROM:)\s*<>/  MAIL FROM:

3 - Use this smtpd process as a filter for clients coming from IP address 
w.x.y.z
/etc/postfix/main.cf:
smtpd_client_restriction= check_client_access 
/etc/postfix/client_acess, .

/etc/postfix/client_acess:
w.x.y.z FILTER localhost:1234

And you get "null sender address rewrites conditional on the client IP address"

Emmanuel.

Re: Null sender rewrite from a specified host.

[Emmanuel Fusté]

Le 07/07/2021 à 15:06, Wietse Venema a écrit :

Viktor Dukhovni:

On Tue, Jul 06, 2021 at 12:56:50PM +0200, Xavier Beaudouin wrote:


I currently have an appliance that misuse the null sender (mail
from:<>) to send mail.

Unfortunatly, this appliance is closed source
and we can only setup : fixed ip address and recipient address on GUI
(nothing else, even if I try to h4x0r the configuration file).

Is there any good advice I can have to make the internal relay server
which is postfix based to rewrite the null sender to something
cleaner... but ONLY for the device that use postfix as internal relay
server?

This requires a content filter or milter, that replaces the envelope
sender address for messages from the client IP address in question.

There is no built-in feature that performs sender address rewrites
conditional on the client IP address.

The milter should be easy to implement.

There is another option:

1 - Configure a Postfix smtpd process on an additional IP addresss
 or TCP port that only this client will connect to.

2 - Configure that smtpd process with an smtpd_command_filter that
 replaces "MAIL FROM:<>" with the preferred address.

 # Listen on port 1234
 /etc/postfix/master.cf:
1234   inet ..   ..   ..   ..   ..   smtpd
-o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

 # Listen on IP address 1.2.3.4
 /etc/postfix/master.cf:
1.2.3.4:smtp   inet ..   ..   ..   ..   ..   smtpd
-o {smtpd_command_filter = pcre:/etc/postfix/command_filter}

 /etc/postfix/command_filter:
/^(MAIL FROM:)\s*<>/  MAIL FROM:

Wietse
And use a client_access map in smtpd_client_restriction 
check_client_access with a filter action and you will transparently get 
the intended behavior without specific client configuration.


A little bit convoluted but should work.

Emmanuel.

Re: TLS client certificates and auth external

[Emmanuel Fusté]

Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :

Something else, maybe.
I do not understand why my (stupid) config

   smtpd_sender_restrictions =
   check_ccert_access hash:/etc/postfix/relay_clientcert,
   permit_tls_clientcerts,
   reject_unknown_sender_domain,
 #reject_sender_login_mismatch,
   permit_sasl_authenticated,
 reject

succeeds only if reject_sender_login_mismatch is commented out
_unless_  i pass a valid client certificate.  I.e., even if
anything is ok except for with/out client certificate:
Just for this part : what is your content of the map configured by 
smtpd_sender_login_maps ?


Emmanuel.

Re: Connection reuse and tlsproxy

[Emmanuel Fusté]

Le 27/09/2019 à 17:01, Emmanuel Fusté a écrit :

Hello,

I started to deploy TLS connection reuse on some non trivial outboud 
gateway setups.


First I was hit by an non obvious configuration behavior:
On my gateway I have:
smtpd_tls_security_level=none
smtp_tls_security_level=dane

If I switch to TLS session reuse with
smtp_tls_connection_reuse=yes

I get:
tlsproxy: warning: TLS service is requested, but disabled with 
tlsproxy_tls_security_level or tlsproxy_use_tls

smtp: warning: private/tlsproxy service role "client" is not available.

By default tlsproxy_tls_security_level=$smtpd_tls_security_level
I overwrite it with tlsproxy_tls_security_level=may and it worked.

But as tlsproxy_client_level = $smtp_tls_security_level (=dane) why I 
need to enable tlsproxy "server" part to get the "client" part working 
? Overlook/Bug ?



Yeahh, fixed in 3.5.2/3.4.12

Thank you !

Emmanuel.

Re: Connection reuse and tlsproxy

[Emmanuel Fusté]

Le 27/09/2019 à 18:07, Viktor Dukhovni a écrit :

On Fri, Sep 27, 2019 at 05:01:03PM +0200, Emmanuel Fusté wrote:


Next, more a feature request: I have some custom transports defined for
different/custom client side TLS certs and conf.

Client-side TLS certs typically have private keys that only root
can read, but tlsproxy(8) (optionally) chroots and then drops privs
at startup, after loading any default client-side keys/certs.

For this, we'd need a variant of the server-side SNI code, with the
keys and certs for various destinations are stored in a table that
is opened in "pre-jail" initialization while the process is still
running as root.  The client code would then load appropriate
destination-specific keys from the table.

Just to be on the safe side with chroot, the CAfile and CApath are
also required to be the same for all tlsproxy clients, perhaps
this can be relaxed, as these files don't contain secrets, and
should be readable by unprivileged processes.  With chroot jails,
it would be the administrator's responsibility to ensure that
suitable CAfile/CApath exist in the jail ($queue_directory).

Yes, that would be great.
Actually, custom transports (with it customs tlsproxy) fit my needs 
without to much burden, so it is ok for now.


As usual, thank you for your detailed answer.

Emmanuel.

Re: Connection reuse and tlsproxy

[Emmanuel Fusté]

Le 27/09/2019 à 17:39, Wietse Venema a écrit :

Emmanuel Fust?:

I have some custom transports defined for different/custom client side
TLS certs and conf.
But we presently have no way to specify a different tlsproxy instance
for smtp as for cleanup for smtpd. So for now I must disable TLS
connection reuse on these transports.

http://www.postfix.org/postconf.5.html#tlsproxy_service_name

tlsproxy_service_name (default: tlsproxy)
The name of the tlsproxy(8) service entry in master.cf. This
service performs plaintext <=> TLS ciphertext conversion.

This feature is available in Postfix 2.8 and later.

Wietse

Perfect ! it work as intended.
I always have difficulties to find theses in the doc as for the cleanup 
service
Perhaps a reference in smtp/smtpd/postscreen manpage would help as many 
are asking regularly for cleanup on the mailing list.


Thank you.
Emmanuel.

Connection reuse and tlsproxy

[Emmanuel Fusté]

Hello,

I started to deploy TLS connection reuse on some non trivial outboud 
gateway setups.


First I was hit by an non obvious configuration behavior:
On my gateway I have:
smtpd_tls_security_level=none
smtp_tls_security_level=dane

If I switch to TLS session reuse with
smtp_tls_connection_reuse=yes

I get:
tlsproxy: warning: TLS service is requested, but disabled with 
tlsproxy_tls_security_level or tlsproxy_use_tls

smtp: warning: private/tlsproxy service role "client" is not available.

By default tlsproxy_tls_security_level=$smtpd_tls_security_level
I overwrite it with tlsproxy_tls_security_level=may and it worked.

But as tlsproxy_client_level = $smtp_tls_security_level (=dane) why I 
need to enable tlsproxy "server" part to get the "client" part working ? 
Overlook/Bug ?


Next, more a feature request:
I have some custom transports defined for different/custom client side 
TLS certs and conf.
But we presently have no way to specify a different tlsproxy instance 
for smtp as for cleanup for smtpd. So for now I must disable TLS 
connection reuse on these transports.
Is adding such a possibility something doable ? My customs transports 
would greatly benefit from connection reuse as there is a permanent 
sustained mail flow on them.


Emmanuel.

Re: authenticate o365 users with postfix without smtp auth

[Emmanuel Fusté]

Le 17/06/2019 à 20:29, Wietse Venema a écrit :

Emmanuel Fust?:

Le 17/06/2019 ? 12:05, Emmanuel Fust? a ?crit?:

Le 16/06/2019 ? 22:37, Viktor Dukhovni a ?crit?:

On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote:


Some of our users use o365 but would like to use our service for
outgoing
mails.? We are offering smtp sending services.? Integrating our
service in
o365 is tricky, as one can only specify a smarthost but microsoft
does not
offer any kind of authentication for smarthosts.

Are these individual users or cloud-hosted domains?? Who's authorized
to ask Microsoft to route their outbound traffic through your relay?
Can you distinguish one such Office365 sender from another? ...

What's the point (if I may ask) of having their mail sent through
your relay?? I assume that Microsoft could quite easily send their
outbound traffic directly to its destination.


Cloud-hosted domains is "hosting" service. You have the control on the
outbound routing.
There is many reason why you want your outbound traffic not directly
delivered to its destination.
Some want to provide "value added services". In my case is is because
the o365 users are only a fraction of my users (hybrid cloud mode) and
that inboud/ouboud internet mails policy/routing/delivery is under the
control of another infrastructure.

Microsoft is always? presenting a client certificate. That the only
way to authenticate O365. (the experimental certificate matching will
help you)

I suppose that Postfix should not accept arbitrary client certificates,
so this certificate check will need to be configurable.

Yes.
In the o365 case, the certificate CN is unique and the same for all o365 
servers and not differentiated by hosted customers.


A global map is need to announce or not XOORG based on the client 
certificate (verified and matching by CN in the o365 case).
Next, to be generic (and not o365 only/hybrid o365 only) you need a way 
to be able if needed to filter which ccert is tied to which oorg with 
something like reject_*_sender_ccert-oorg_mismatch.
It's different from the case where we want to use the same map 
irrespective from the used mechanisms (sasl -> from email, ccert -> from 
email, oorg-> from email) and for witch I would overload/generalize the 
SASL login to reuse reject_*_sender_login_mismatch.


More in my other answer.

Emmanuel.

Re: authenticate o365 users with postfix without smtp auth

[Emmanuel Fusté]

Le 17/06/2019 à 21:31, Wietse Venema a écrit :

Viktor Dukhovni:

On Mon, Jun 17, 2019 at 02:29:05PM -0400, Wietse Venema wrote:
I suppose that Postfix will need to forward the OORG information 
that it received from the Microsoft server, not a name that is 
hard-coded in main.cf, and that Postfix will need to send that 
information only to systems that should receive it, not to random 
systems on the Internet. 
Really no need to forward OORG. It was not designed as an end to end 
mechanism.
It its only stamping email from coming from this or this hosted 
organization without guaranties that they are doing sane things.
OORG value has no meaning downstream, but need to be used in the access 
and relay policy: dedicated family of restrictions or SASL mapping to 
reuse some (reject_*_login_mismatch).
Cloud/hosting providers could be trusted but without OORG information, 
it is the same as blindly thrusting the Internet.
The cloud/hosting provider is acting as a multiplexer and we need to 
de-multiplex the flow, without presuming or relying on any inner in-band 
mechanism (DKIM).


If going further, OORG must not be passed downstream but a way to tag 
some flow should be provided. With that, nothing prevent you to put the 
same tag as inbound (if there was any).


I'm not a networking expert, but it could be view as an MPLS mechanism 
for SMTP
It could help to solve a lots of thing in classic SAS/Cloud scenario, 
and is unavoidable in "hybrid" configurations.


For the o365 hybridization case, destination domain is sufficient to 
determine the OORG to put for downstream Exchange servers as o365<->on 
premise emails use a "technical SMTP routing domain" 
(xxx.onmicrosoft.com) and custom transport fit well and keep the 
implementation minimal.


My case for inbound emails: -> Exchange
Office365-> inbound postfix   -> routing, filtering layers etc-> 
internal outbound postfix -> Exchange
       (OORG access control)    (o365 
OORG spoofing) -> 

|_||___|
  Internet         Big Corp trusted central 
zone        Big corp branches/societies


With the OORG replaying at the oubound, Exchange will promote these 
emails as internal, enabling the use/trust of all the specific Exchange 
headers coming from o365.


XOORG would need to be accepted only from suitably authenticated and 
authorized clients (those trusted to deliver authentic information). 
XOORG feels clumsy, a cleaner choice would be DKIM, which supports 
passage through untrusted relays, ... but at the cost of breaking 
when the content is modified. XOORG on the other admits content 
modification, ... but at the cost of requiring trusted relays. If 
we're willing to generally forward DKIM signatures, I am not sure 
that XOORG needs censoring on the outbound leg, when trusted on the 
inbound leg. 
The latter is simply conservative design. There is no need to forward 
this information, and a receiving system might object to receiving 
XOORG from a Postfix machine that isn't authorized to send it.

Yes, XOORG is not a end to end mechanism.
It is actually supposed to be used only in o365->MS Exchange Edge case.
Following their use, you should provide the XOORG capability only to a 
trusted server which is for Microsoft a server presenting a validated 
certificate with a specific CN.


Emmanuel.

Re: authenticate o365 users with postfix without smtp auth

[Emmanuel Fusté]

Le 17/06/2019 à 13:08, Stefan Bauer a écrit :

Emmanuel,

thank you. That was of great help to see, that others have same isses 
with o365.


Do you have any more infos how you do the experimental certificate 
matching part with postifx?




In the official experimental release from Wietse.

Emmanuel.

Re: authenticate o365 users with postfix without smtp auth

[Emmanuel Fusté]

Le 17/06/2019 à 12:05, Emmanuel Fusté a écrit :

Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit :

On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote:

Some of our users use o365 but would like to use our service for 
outgoing
mails.  We are offering smtp sending services.  Integrating our 
service in
o365 is tricky, as one can only specify a smarthost but microsoft 
does not

offer any kind of authentication for smarthosts.

Are these individual users or cloud-hosted domains?  Who's authorized
to ask Microsoft to route their outbound traffic through your relay?
Can you distinguish one such Office365 sender from another? ...

What's the point (if I may ask) of having their mail sent through
your relay?  I assume that Microsoft could quite easily send their
outbound traffic directly to its destination.

Cloud-hosted domains is "hosting" service. You have the control on the 
outbound routing.
There is many reason why you want your outbound traffic not directly 
delivered to its destination.
Some want to provide "value added services". In my case is is because 
the o365 users are only a fraction of my users (hybrid cloud mode) and 
that inboud/ouboud internet mails policy/routing/delivery is under the 
control of another infrastructure.


Microsoft is always  presenting a client certificate. That the only 
way to authenticate O365. (the experimental certificate matching will 
help you)
For the next part, the complete missing of outbound SMTP AUTH (under 
the control of Microsoft or the client organization) is the 
difficult/crazy part.


The easy/lame way is to match the "under Microsoft control" 
X-MS-Exchange-CrossTenant-id header and the SMTP From domains to 
filter/differentiate o365  customers.


The "proper" Microsoft way is to use their proprietary XOORG SMTP 
extension used in their hybrid cloud scenario.
=> after having authenticated o365 with the presented client 
certificate, if you announce the XOORG extension in the EHLO, o365 
will provide you the remote o365 organization (in the "MS Exchange" 
sense) as part of the MAIL FROM verb.

MAIL FROM:  OORG=my-organization.com

I have implemented the client part in postfix to not have to deploy 40 
Microsoft Exchange Edge servers in a multi-tenant hybrid cloud 
scenario and use only my existing postfix infrastructure between o365 
and all my Exchange platforms. It is the easy part. A few simple lines 
of code. I don't know what Wietse and Viktor will think about it, so I 
did not submit it yet... Will do. Would be great if it could  be 
integrated in one form or another.



Replying to myself, attached is the client patch for Postfix.
Configure your Exchange with the proper TlsCapability and X509 authority
Present the configured client certificate on the postfix smtp side.
Exchange will announce the XOORG in the post TLS handshake EHLO.
Postfix will pass the configured XOORG to Exchange during the "MAIL FROM:"
Use debug_peer_list to observe the complete smtp transaction.

Emmanuel.

diff -u -r postfix-3.4.5-cert-auto/src/global/ehlo_mask.c 
postfix-3.4.5-xoorg/src/global/ehlo_mask.c
--- postfix-3.4.5-cert-auto/src/global/ehlo_mask.c  2018-11-07 
01:34:26.0 +0100
+++ postfix-3.4.5-xoorg/src/global/ehlo_mask.c  2019-06-05 15:12:38.386204490 
+0200
@@ -21,6 +21,7 @@
 /* #define EHLO_MASK_SMTPUTF8  (1<<12)
 /* #define EHLO_MASK_CHUNKING  (1<<13)
 /* #define EHLO_MASK_SILENT(1<<15)
+/* #define EHLO_MASK_XOORG (1<<16)
 /*
 /* int ehlo_mask(keyword_list)
 /* const char *keyword_list;
@@ -86,6 +87,7 @@
 "SMTPUTF8", EHLO_MASK_SMTPUTF8,
 "CHUNKING", EHLO_MASK_CHUNKING,
 "SILENT-DISCARD", EHLO_MASK_SILENT,/* XXX In-band signaling */
+"XOORG", EHLO_MASK_XOORG,
 0,
 };
 
diff -u -r postfix-3.4.5-cert-auto/src/global/ehlo_mask.h 
postfix-3.4.5-xoorg/src/global/ehlo_mask.h
--- postfix-3.4.5-cert-auto/src/global/ehlo_mask.h  2018-08-27 
23:54:59.0 +0200
+++ postfix-3.4.5-xoorg/src/global/ehlo_mask.h  2019-06-05 15:11:10.176862868 
+0200
@@ -30,6 +30,7 @@
 #define EHLO_MASK_SMTPUTF8 (1<<12)
 #define EHLO_MASK_CHUNKING (1<<13)
 #define EHLO_MASK_SILENT   (1<<15)
+#define EHLO_MASK_XOORG(1<<16)
 
 extern int ehlo_mask(const char *);
 extern const char *str_ehlo_mask(int);
diff -u -r postfix-3.4.5-cert-auto/src/global/mail_params.h 
postfix-3.4.5-xoorg/src/global/mail_params.h
--- postfix-3.4.5-cert-auto/src/global/mail_params.h2019-04-09 
16:17:03.47123 +0200
+++ postfix-3.4.5-xoorg/src/global/mail_params.h2019-06-05 
15:05:32.571358595 +0200
@@ -1620,6 +1620,12 @@
 #define DEF_SMTP_TLS_INSECURE_MX_POLICY "dane"
 extern char *var_smtp_tls_insecure_mx_policy;
 
+#define VAR_SMTP_XOORG "smtp_xoorg"
+#define DEF_SMTP_XOORG ""
+#define VAR

Re: authenticate o365 users with postfix without smtp auth

[Emmanuel Fusté]

Le 17/06/2019 à 13:14, Wietse Venema a écrit :

Emmanuel Fust?:

The "proper" Microsoft way is to use their proprietary XOORG SMTP
extension used in their hybrid cloud scenario.

- Is there a protocol definition for this, or is there only
implementation by trial and error?
The only official statements by Microsoft about these are in this recent 
blog post:

https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Advanced-Office-365-Routing-Locking-Down-Exchange-On-Premises/ba-p/609238
Otherwise you will find some random informations on random blogs from 
anonymous or "value added" vendors.


We verified these by reversing the exchange 2016 code, do tests with 
openssl s_client after proper configuration of our Exchange testing 
platform and add the client support in postfix. No fancy config, just 
define a smtp_xoorg parameter on a specific transport using a specific 
client certificate.



- How is the XOORG information verified against other information
(certificate, header) that is passed in a mail transaction?
XOORG capability is announced and accepted by the (Exchange) server only 
for a valid (authority wise) client certificate matching a specific CN. 
(could be customized with the TlsCapability on the Exchange side).
In the standard O365 cloud scenario, you authenticate the SMTP session 
with the classic validation of the certificate : You know that it is 
Microsoft and that it is O365 (cn= sorry bad memory, enable 
smtpd_tls_ask_ccert and you will get it, it is what the "hybridation 
wizard" will configure in the TlsCapability of your Exchange edge server).
At this point, the XOORG value is know to be genuine, it is under 
Microsoft control, not tenant owner.
All the other 'could/o365" informations passed as headers to Microsoft 
Exchange (cross-tenant-ID, X-OriginatorOrg etc...) are now trusted.
Your Exchange server will now flag the email as "internal" (hybrid 
cloud") if the XOORG value passed during the SMTP transaction is a 
recognised/configured one.


On the other side, when our are on O365, the headers are 
generated/sanitized by Microsoft and you base your policy on it. For 
on-premise -> o365, they don't use the XOORG extension (it is never 
announced). On your tenant, you configure an specific "inboud connector" 
which should match a specific client certificate CN (which should 
publicly validate)  or a list of IPs  No SMTP-AUTH 




It would be unsafe to accept XOORG from anyone without further
verification.
Exactly. XOORG is totally moot without client certificate validation and 
matching.


Emmanuel.

Re: authenticate o365 users with postfix without smtp auth

[Emmanuel Fusté]

Le 16/06/2019 à 22:37, Viktor Dukhovni a écrit :

On Sun, Jun 16, 2019 at 05:46:52PM +0200, Stefan Bauer wrote:


Some of our users use o365 but would like to use our service for outgoing
mails.  We are offering smtp sending services.  Integrating our service in
o365 is tricky, as one can only specify a smarthost but microsoft does not
offer any kind of authentication for smarthosts.

Are these individual users or cloud-hosted domains?  Who's authorized
to ask Microsoft to route their outbound traffic through your relay?
Can you distinguish one such Office365 sender from another? ...

What's the point (if I may ask) of having their mail sent through
your relay?  I assume that Microsoft could quite easily send their
outbound traffic directly to its destination.

Cloud-hosted domains is "hosting" service. You have the control on the 
outbound routing.
There is many reason why you want your outbound traffic not directly 
delivered to its destination.
Some want to provide "value added services". In my case is is because 
the o365 users are only a fraction of my users (hybrid cloud mode) and 
that inboud/ouboud internet mails policy/routing/delivery is under the 
control of another infrastructure.


Microsoft is always  presenting a client certificate. That the only way 
to authenticate O365. (the experimental certificate matching will help you)
For the next part, the complete missing of outbound SMTP AUTH (under the 
control of Microsoft or the client organization) is the difficult/crazy 
part.


The easy/lame way is to match the "under Microsoft control" 
X-MS-Exchange-CrossTenant-id header and the SMTP From domains to 
filter/differentiate o365  customers.


The "proper" Microsoft way is to use their proprietary XOORG SMTP 
extension used in their hybrid cloud scenario.
=> after having authenticated o365 with the presented client 
certificate, if you announce the XOORG extension in the EHLO, o365 will 
provide you the remote o365 organization (in the "MS Exchange" sense) as 
part of the MAIL FROM verb.

MAIL FROM:  OORG=my-organization.com

I have implemented the client part in postfix to not have to deploy 40 
Microsoft Exchange Edge servers in a multi-tenant hybrid cloud scenario 
and use only my existing postfix infrastructure between o365 and all my 
Exchange platforms. It is the easy part. A few simple lines of code. I 
don't know what Wietse and Viktor will think about it, so I did not 
submit it yet... Will do. Would be great if it could  be integrated in 
one form or another.


The hard part is the server part. Will do it some day to simplify our 
tenants authentication, but I think that it will be more controversial 
and will understand if Wietse and Viktor do not want such thing in Postfix.
As it is a SMTP extension, I did not find a generic  mechanism in which 
XOORG would fit and which could be added to postfix.
For my use case, as I've done for another reason for the certificate 
case, I will add the possibility to silently map an XOORG value to a 
SASL id to do proper source domain ownership filtering 
(reject_xx_login_mismatch mumbles).


Emmanuel.

Re: TLS client certificates and auth external

[Emmanuel Fusté]

Le 18/04/2019 à 21:45, Viktor Dukhovni a écrit :

On Apr 18, 2019, at 12:01 PM, Wietse Venema  wrote:

Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).

I am not convinced that stuffing arbitrary PKI identities into a
SASL identity is necessarily a good idea. Maybe it is safer to solve
this problem without PKI-to-SASL cross-talk.

I would expect the mapping to be indirect.  That is, a table lookup
key of either the client public key fingerprint to a SASL name (roughly
what we have now, but with an explicit RHS indicating the desired SASL
identity), or else the client's subject name in a standard (likely
RFC2254) form, again mapped to the desired identity, provided the
client certificate is from a trusted PKI issuer.

Yes I agree. The proposed sasl provider dance is for a quick hack to not 
have to implement the client subject name table lookup.


Emmanuel.

Re: TLS client certificates and auth external

[Emmanuel Fusté]

Le 18/04/2019 à 12:05, lst_ho...@kwsoft.de a écrit :


Zitat von Emmanuel Fusté :


Hello,

Great piece of work ! It solve a big part of my problem, but sadly I 
need to go deeper.


Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and 
Victor, which adds an option smtpd_sasl_tls_ccert_username.

As the patch is rather small, I also attached it to this message.

This smtpd_sasl_tls_ccert_username option can be used in the 
following way:


Using smtpd_sasl_tls_ccert_username = commonName
After providing a verified client certificate, postfix advertises 
auth external and the user can authenticate with the username being 
the commonName of the certificate. This is for users having control 
over the CA issuing the certificates and resembles the way cyrus 
imap handles the situation.


Using smtpd_sasl_tls_ccert_username = relay_clientcerts
When a client presents a certificate, where the fingerprint matches 
in relay_clientcerts, the lookup value (previously unused) is used 
to get the username for sasl. The client can then perform an auth 
external with this username successfully. This is a solution for 
users, which cannot control the CAs or do not want to trust them or 
cope with crls, ... It fits in the way postfix currently handles 
client certificates.


I have to deal with products that do not support SMTP AUTH (big email 
security appliance provider .) but are able to present a TLS 
certificate.
On my platform, the use of the smtpd_sender_login_maps and associated 
restrictions (reject_sender_login_mismatch) is mandatory to achieve 
our goal.
At first, I was thinking about using the lookup value of 
relay_clientcerts to map a sasl username.
It is nicely done with your patch with smtpd_sasl_tls_ccert_username 
= relay_clientcerts, but I need to go one step further:
I need to completely bypass the sasl provider call and act as if the 
mapped user successfully authenticate.
It would be something like "smtpd_sasl_tls_ccert_username = 
relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other 
(I'm not good at finding good option naming ...)


The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announce 
AUTH support, the auth and identity mapping is already done by the 
relay_clientcerts map


I think it is not a big code complexity addition on top of your work, 
but before going further I would like to request for comments about 
this.

Viktor, Wietse, would you accept such addition ?

Emmanuel.


I tested this with a patched postfix for my usage scenario (relaying 
based on validated CN) but i fail to get it work. Note that i don't 
need a sasl username at all, but also tested with sasl username and 
check_sasl_access.


The config basically looks like this:

smtpd_relay_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   check_sasl_access hash://etc/postfix/check_sasl_access,
   defer_unauth_destination

# tested both
#smtpd_sasl_tls_ccert_username = commonName
smtpd_sasl_tls_ccert_username = relay_clientcerts_auto
#relay_clientcerts = hash://etc/postfix/relay_clientcerts

You need the relay_clientcerts map with relay_clientcerts_auto mode.
Put the fingerprint or pkey_fingerprint and the mapped SASL identity in 
the file and it will work

For example:
43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6    xxx.kwsoft.de


smtpd_tls_loglevel = 2
smtpd_tls_ask_ccert = yes
smtpd_sasl_auth_enable = yes

smtpd_use_tls=yes
smtpd_tls_CApath = /etc/ssl/certs

But this leads to
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: 
kw-tools.hq.kwsoft.de[10.1.7.15]: subject_CN=xxx.kwsoft.de, 
issuer=SwissSign Server Silver CA 2014 - G22, 
fingerprint=B8:D9:ED:1F:33:FE:DB:36:11:A6:D9:3F:BA:B5:1D:44, 
pkey_fingerprint=43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: Trusted TLS connection 
established from kw-tools.hq.kwsoft.de[10.1.7.15]: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: NOQUEUE: reject: RCPT 
from kw-tools.hq.kwsoft.de[10.1.7.15]: 454 4.7.1 : 
Relay access denied; from= to= 
proto=ESMTP helo=
Apr 18 11:46:05 linux-test postfix/smtpd[4257]: disconnect from 
kw-tools.hq.kwsoft.de[10.1.7.15] ehlo=2 starttls=1 mail=1 rcpt=0/1 
data=0/1 rset=1 quit=1 commands=6/8


What i actually need is relaying based on validated certificate CN 
without forcing the client to use some form of authentication, so this 
would basically mean relay_clientcerts with CN lookup key or a 
relay_clientcerts_auto_cn to always skip AUTH and use the CN as 
username i guess.


Yes, if you don't want fingerprint to something maps, you need a 
"commonName_auto" mode which rely on SASL external provider to validate 
the user (provide the map of valid users) but auto triggered

Re: TLS client certificates and auth external

[Emmanuel Fusté]

Le 27/03/2019 à 18:10, Emmanuel Fusté a écrit :

Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :

On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:


The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announce
AUTH support, the auth and identity mapping is already done by the
relay_clientcerts map

I believe you're asking Postfix to (when configured to do that)
simulate "AUTH EXTERNAL" when the client has presented a client
certificate, but proceeds from "EHLO" to "MAIL FROM" with no
intevening explicit "AUTH".
Yes exactly, if a hash to sasl id/username mapping is found in the 
relay_clientcerts


The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
yields an authenticated user or proceeds with the user unauthenticated,
and acts accordingly.

Does that sound right?
Yes, in case of unauthenticated (not present in relay_clientcerts), 
the simulated "AUTH EXTERNAL" must ideally not be performed and AUTH 
support be announced as usual as this is perhaps a client with proper 
AUTH support (otherwise it would be listed with a mapping in 
relay_clientcerts).


Ok, patch attached.
Need to be applied on top of Bastian one.
Work well here, thanks to the hard part done by Bastian !
Please comment.

Emmanuel.
--- postfix-3.4.5/src/smtpd/smtpd_sasl_glue.c   2019-04-10 12:26:39.571554576 
+0200
+++ postfix-3.4.5-cert-auto/src/smtpd/smtpd_sasl_glue.c 2019-04-10 
12:35:26.189153746 +0200
@@ -201,6 +201,7 @@
 static const NAME_CODE sasl_tls_user[] = {
SASL_TLS_USER_NAME_COMMON_NAME, SASL_TLS_USER_COMMON_NAME,
SASL_TLS_USER_NAME_RELAY_CLIENTCERTS, SASL_TLS_USER_RELAY_CLIENTCERTS,
+   SASL_TLS_USER_NAME_RELAY_CLIENTCERTS_AUTO, 
SASL_TLS_USER_RELAY_CLIENTCERTS_AUTO,
0, SASL_TLS_USER_NONE
 };
 #endif
@@ -236,6 +237,7 @@
verified_user = TLS_CERT_IS_TRUSTED(state->tls_context) ? 
state->tls_context->peer_CN : 0;
break;
case SASL_TLS_USER_RELAY_CLIENTCERTS:
+   case SASL_TLS_USER_RELAY_CLIENTCERTS_AUTO:
if ( TLS_CERT_IS_PRESENT(state->tls_context) ) {
int i;
char *prints[2];
@@ -262,6 +264,15 @@
 #endif
 #define ADDR_OR_EMPTY(addr, unknown) (strcmp(addr, unknown) ? addr : "")
 #define REALM_OR_NULL(realm) (*(realm) ? (realm) : (char *) 0)
+   
+if ((name_code(sasl_tls_user, NAME_CODE_FLAG_NONE,
+ var_smtpd_sasl_tls_ccert_username) == 
SASL_TLS_USER_RELAY_CLIENTCERTS_AUTO)
+&& verified_user) {
+
+   smtpd_sasl_login(state, verified_user, "RELAY_CLIENTCERTS_AUTO"); 
+   state->sasl_mechanism_list = mystrdup("");
+   return;
+}
 
 if ((state->sasl_server =
 XSASL_SERVER_CREATE(smtpd_sasl_impl, _args,
--- postfix-3.4.5/src/smtpd/smtpd_sasl_glue.h   2019-04-10 12:26:39.571554576 
+0200
+++ postfix-3.4.5-cert-auto/src/smtpd/smtpd_sasl_glue.h 2019-04-10 
11:10:49.054873903 +0200
@@ -26,10 +26,12 @@
 /* for SASL external auth */
 #define SASL_TLS_USER_NAME_COMMON_NAME "commonName"
 #define SASL_TLS_USER_NAME_RELAY_CLIENTCERTS "relay_clientcerts"
+#define SASL_TLS_USER_NAME_RELAY_CLIENTCERTS_AUTO "relay_clientcerts_auto"
 
 #define SASL_TLS_USER_NONE 0
 #define SASL_TLS_USER_COMMON_NAME 1
 #define SASL_TLS_USER_RELAY_CLIENTCERTS 2
+#define SASL_TLS_USER_RELAY_CLIENTCERTS_AUTO 3
 
 /* LICENSE
 /* .ad

Re: TLS client certificates and auth external

[Emmanuel Fusté]

Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :

On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:


The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announce
AUTH support, the auth and identity mapping is already done by the
relay_clientcerts map

I believe you're asking Postfix to (when configured to do that)
simulate "AUTH EXTERNAL" when the client has presented a client
certificate, but proceeds from "EHLO" to "MAIL FROM" with no
intevening explicit "AUTH".
Yes exactly, if a hash to sasl id/username mapping is found in the 
relay_clientcerts


The simulated "AUTH EXTERNAL" would never "fail" (5XX), it either
yields an authenticated user or proceeds with the user unauthenticated,
and acts accordingly.

Does that sound right?
Yes, in case of unauthenticated (not present in relay_clientcerts), the 
simulated "AUTH EXTERNAL" must ideally not be performed and AUTH support 
be announced as usual as this is perhaps a client with proper AUTH 
support (otherwise it would be listed with a mapping in relay_clientcerts).
But I could live with an unconditional simulated "AUTH EXTERNAL" mode  
as clients not normally present a certificate.
I did not already dig in the code to see if it is doable in a "clean" 
manner or if the unconditional simulated "AUTH EXTERNAL" mode is the 
only way to go without too intrusive changes.


Emmanuel.

Re: TLS client certificates and auth external

[Emmanuel Fusté]

Hello,

Great piece of work ! It solve a big part of my problem, but sadly I 
need to go deeper.


Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and 
Victor, which adds an option smtpd_sasl_tls_ccert_username.

As the patch is rather small, I also attached it to this message.

This smtpd_sasl_tls_ccert_username option can be used in the following 
way:


Using smtpd_sasl_tls_ccert_username = commonName
After providing a verified client certificate, postfix advertises auth 
external and the user can authenticate with the username being the 
commonName of the certificate. This is for users having control over 
the CA issuing the certificates and resembles the way cyrus imap 
handles the situation.


Using smtpd_sasl_tls_ccert_username = relay_clientcerts
When a client presents a certificate, where the fingerprint matches in 
relay_clientcerts, the lookup value (previously unused) is used to get 
the username for sasl. The client can then perform an auth external 
with this username successfully. This is a solution for users, which 
cannot control the CAs or do not want to trust them or cope with crls, 
... It fits in the way postfix currently handles client certificates.


I have to deal with products that do not support SMTP AUTH (big email 
security appliance provider .) but are able to present a TLS 
certificate.
On my platform, the use of the smtpd_sender_login_maps and associated 
restrictions (reject_sender_login_mismatch) is mandatory to achieve our 
goal.
At first, I was thinking about using the lookup value of 
relay_clientcerts to map a sasl username.
It is nicely done with your patch with smtpd_sasl_tls_ccert_username = 
relay_clientcerts, but I need to go one step further:
I need to completely bypass the sasl provider call and act as if the 
mapped user successfully authenticate.
It would be something like "smtpd_sasl_tls_ccert_username = 
relay_clientcerts_nosasl" or relay_clientcerts_saslbypass or other (I'm 
not good at finding good option naming ...)


The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announce 
AUTH support, the auth and identity mapping is already done by the 
relay_clientcerts map


I think it is not a big code complexity addition on top of your work, 
but before going further I would like to request for comments about this.

Viktor, Wietse, would you accept such addition ?

Emmanuel.

Re: permit_tls_clientcerts with CN matching

[Emmanuel Fusté]

Le 27/03/2019 à 15:15, Wietse Venema a écrit :

lst_ho...@kwsoft.de:

Hello,

we need to authenticate a SMTP client connection base on the CN of the
(trusted) client certificate. The client is not under our control
(O365 connector), so we will get no notification if the key
fingerprint will change. As far as i can see Postfix is only able to
use certificate fingerprints to allow relaying, not the CN string, no?

Have i missed something or is this not considered a valid use case?

CN-based access checks are not built into Postfix, but the CN is
available in the policy delegation protocol's ccert_subject attribute,
if the client certificate can be verified with PKI.

There is a patch-in-progress (thread: TLS client certificates and
auth external) that provides the option to permit relaying based
on certificate info.

Wietse

Hello,

I missed this thread too ! I need to go one step further. Will develop 
in the tread.


Emmanuel.

Re: best practice for HA cluster

[Emmanuel Fusté]

Le 08/02/2019 à 15:58, Harald Koch a écrit :

On Fri, Feb 8, 2019, at 06:40, Emmanuel Fusté wrote:

Never use shared storage. It will be your main source of problems.

Recognizing that shared storage is always a headache:

How do you handle the situation where your active node crashes with queued, 
undelivered messages?

No, fix the problem or at last move and rebuild the queue on another 
node. What are you calling crashes ?

After 15 years of postfix exploitation, I never have to do it.
And the only time we lost emails was on a shared storage, so we killed 
it usage nine years ago.

More cheap, more simple, more serviceable, more robust.

Emmanuel.

Re: best practice for HA cluster

[Emmanuel Fusté]

Le 08/02/2019 à 11:35, De Petter Mattheas a écrit :


Hello

Which work method do you guys prefer for ha with postfix?

2 postfix nodes with f5 load balancer active passive and shared 
storage for the que


How can you share config between active and passive ? can we use my 
sql cluster for configuration sharing between the two nodes?


Ha proxy or ha cluster with two nodes?



Complete over engineering.
For two node :
- two independent node
- MX DNS entries
- your preferred conf tool to maintain config

Never use shared storage. It will be your main source of problems.
Use properly sized and resilient nodes (raid 1/10)
I never use load balancer under 4 nodes and always a minimum of two MX 
and up to four.

I always separate inbound and outbound nodes.

KISS design is the base rule for robust design.

Emmanuel.

Re: SMTP session caching

[Emmanuel Fusté]

Le 19/03/2018 à 17:32, Msd a écrit :

Le 19/03/2018 à 16:28, Wietse Venema a écrit :

Please provide quantitative evidence that connection reuse is
necessary to get mail into the 'big providers' (i.e. they punish
connection rate and message rate differently).

Hi Wietse,

The biggest email service provider in France : Orange/Wanadoo.

We needed to disable TLS to reuse connections :
postconf -P "orange/unix/smtp_tls_security_level=none"

Here are their rules, got from ab...@orange.fr and confirmed by our logs :
- Maximum 1000 connections per hour
- Maximum 100 emails by connection
- Maximum 3 simultaneous connections

Yes and as they count connection at the IP level and have two domains 
behind the same MX, you should reduce the 
transport_destination_concurrency_limit to 1 to not exceed the 3 
simultaneous connections limit. (you could theoretically reach 6 with 
local transport trick because the single MX for these domains has two IP 
address...)


---
Emmanuel.

Re: SMTP session caching

[Emmanuel Fusté]

Le 19/03/2018 à 16:42, Emmanuel Fusté a écrit :

Le 19/03/2018 à 16:28, Wietse Venema a écrit :

Emmanuel Fust?:

Is there any document that describe how interprocess notification is
done in postfix ? More precisely the scheduler -> delivery agent
notification ?

There is no public documentation for *internal* Postfix interfaces,
so that I can change that without breaking non-Postfix software
that depends on Postfix internals.

I agree with Viktor that updating the TLS proxy is the more feasible
approach (caching the TLS sessions outside delivery agents). I also
don't believe in changing the scheduler-to-delivery agent protocol.
The Postfix approach is not to make an existing thing more complex,
but by combining less complex things together.

Please provide quantitative evidence that connection reuse is
necessary to get mail into the 'big providers' (i.e. they punish
connection rate and message rate differently).

Ok I will try to collect data with/without con reuse and get back here.
While reviewing logs, I see that for thousand email being delivered to 
the two offending domains, each time the same smtp process will pick the 
next mail for the same domain.
So in this particular case, for the most part of the traffic, simply 
delaying the closing of the connection (of ~2s max)  while taking the 
next email would be sufficient to opportunistically reuse the connection 
most the time without any inter-process  notification modification or 
delivery agent TLS refactoring.


I will collect data for TLS vs clear with conn reuse for next week.

---
Emmanuel.

Re: SMTP session caching

[Emmanuel Fusté]

Le 19/03/2018 à 16:28, Wietse Venema a écrit :

Emmanuel Fust?:

Is there any document that describe how interprocess notification is
done in postfix ? More precisely the scheduler -> delivery agent
notification ?

There is no public documentation for *internal* Postfix interfaces,
so that I can change that without breaking non-Postfix software
that depends on Postfix internals.

I agree with Viktor that updating the TLS proxy is the more feasible
approach (caching the TLS sessions outside delivery agents). I also
don't believe in changing the scheduler-to-delivery agent protocol.
The Postfix approach is not to make an existing thing more complex,
but by combining less complex things together.

Please provide quantitative evidence that connection reuse is
necessary to get mail into the 'big providers' (i.e. they punish
connection rate and message rate differently).

Ok I will try to collect data with/without con reuse and get back here.

---
Emmanuel.

Re: SMTP session caching

[Emmanuel Fusté]

Le 18/03/2018 à 19:23, Viktor Dukhovni a écrit :

On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas  wrote:


* Caching open TLS connections in the smtp(8) delivery agent for
reuse by scheduling repeated deliveries to the same delivery
agent runs into complex scheduling difficulties.  The presence
of open connections don't, and should not IMHO alter scheduler
priority.  Messages should still leave in approximately FIFO
order (subject to (n)qmgr's periodic preemption of messages that
split into many envelopes).

I believe routing multiple messages for the same destination through an
array of currently open connections (held by different processes) should
not be slower than opening new connection for each message.


This would be a rather non-trivial effort.  And downstream MTAs
at major providers seem to frown on connection re-use these days.

is there an evidence about this?


While traffic to smaller destinations is typically less
performance-critical.  So while having TLS connection caching
would be nice, it is not clear that it is a high priority given
the high cost and possibly only moderate benefit.

that is imho still the question. But I'm more curious about questions above

Sorry, no cycles to dissect this point by point.  My view is as stated in
the previous message:

   * I believe that support for this requires proxy processes to handle TLS
 on behalf of (multiple) SMTP delivery agents.  The connection cache
 would then hold a connection to the proxy, rather than a connection to
 the remote destination.

   * The feature is attractive, but not urgently compelling.  It is complex
 to implement, so I cannot predict when work in that direction might begin.

Ok, this is for the connection reuse in the traditional postfix 
sense.Some "opportunistic" reuse.


But would it be difficult to implement something for the case when the 
connection reuse could be planned by the scheduler before submission to 
the agents ?


The most problematic case (and the case for which we would gain a lot) 
is when we cross by a factor the transport_destination_concurrency_limit 
of mail waiting to be delivered to a destination in the mailq.


In this case, instead of pushing/notifying smtp one mail at time, could 
the notifying scheme be extended to be able to push a list of mail to be 
processed by one smtp agent ?
With purely static parameters (crossing factor and fixed queue length) 
it could be a huge step forward for the most common case, even with low 
queue length and could be later enhanced if wanted (dynamic or adaptive 
queue length for example).


In my case, I already have transport_destination_concurrency_limit=1 for 
the problematic destinations and many parallels servers with their own 
public IP. At the scale of my country, the problematic destination is 
like google or yahoo for the world. Without connection reuse for 
lowering my tcp connexion rate, my servers are always throttled 
(temporary blacklisted).
Now my only option would be to disable TLS for these domains, but my 
client will put me on fire or more in that case |-)).


Is there any document that describe how interprocess notification is 
done in postfix ? More precisely the scheduler -> delivery agent 
notification ?


---
Emmanuel.

Re: SMTP session caching

[Emmanuel Fusté]

Matus UHLAR - fantomas:

a smtp client that able to process multiple mails in a single run is not
planned, correct?

On 15.03.18 09:22, Wietse Venema wrote:

Wasn't a dedicated per-destination delivery agent one of the possible
solutions?

if you mean this one:


- For each destination, use dedicated SMTP clients that handle all
TLS sessions with that destination (no inter-process migration),
and cache TCP+TLS state in those processes. Unfortunately, that
does not scale to thousands of destinations.

... which does not scale, I was under impression that it requires site
configuration, or keeping multiple clients alive.

what I meant, is that if SMTP client connecting to destination couldn't
try to deliver multiple (all) mail directed to the destination and then
quit, the only difference would be it could deliver more than just one mail.

I have some problems with big local provider and their crazy (tcp) rate 
limiting rules and ugly smtp conf (only one MX, a big LB).

The problem is worse now that all connections are TLS.
(for the detail, their rate limiting is accounted at the LB level and 
they host multiple domains).
When I have big mailing running (each Monday), even with 
destination_concurrency_limit=1 for a dedicated transport, I get some 
gateways temporary blacklisted.


As I understand, by design the scheduler had no way to push "some 
destination domain emails" to "some already running delivery agents for 
that domain".
Is it a big departure from the current design, but could the protocol 
between the scheduler and the delivery agent be augmented with some 
"destination_concurrency" over-commit notification containing the domain 
for which a to be scheduled email is pending? Before closing the 
connection, the agent could check if such a mail is pending.

Yes it is overly complex.
Perhaps we should wait the landing of Linux TLS kernel app sockets which 
will perhaps simplify the connection reuse.
I hate to see Exchange be able to push to me multiple emails in a SMTP 
TLS connection and not be able to do it with Postfix. ;-)


Emmanuel.

Re: cleanup Adds From: Using Comment Syntax for GECOS Name.

[Emmanuel Fusté]

Le 07/01/2018 à 02:49, Wietse Venema a écrit :

Quick update: I've done a brain-dead simple, but correct, implementation
that always quotes the name (just like qmail, BTW). If needed, it
can be made smarter later.

There 's some draft documentation below.

Wietse

header_from_format (default: standard)
The format of the Postfix-generated From: header. By  default,  Postfix
generates  this header only for clients that match the local_header_re-
write_clients setting.

This setting affects the appearance of email from programs that  submit
messages  without  From:  header,  such  as some /bin/mail command-line
implementations.

Specify one of the following:

standard (default)
   Produce a header formatted as From: "name" .   This  is
   the default as of Postfix 3.3.

legacy Produce  a header formatted as From: address (name). This is the
   behavior prior to Postfix 3.3.

This feature is available in Postfix 3.3 and later.

Hello,

As I've been hit by "local_header_rewrite_client" a lots of time because 
of local content filter, could you consider to change the default of 
"local_header_rewrite_client" from "permit_inet_interface" to "" for the 
next compatibility_level bump too ?
As you previously note, by default we should today mandate sane MUA 
behavior regarding From: header.


Emmanuel.

Re: Is not honoring bounces-to violation of RFC?

[Emmanuel Fusté]

Le 29/06/2016 17:02, Chip a écrit :

If Return-path is added by receiving MTA, as you say, below, and that it
contains the MAIL FROM, then why do I see the following in source code
of received message in which return-path does not match From?


X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-path: 
From: "Sears" 


X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-Path: 
From: lucky 


MAIL FROM/envelope from and header From are two different beast.
Return-Path: is MAIL FROM/envelope from.
From: lucky  in your example is header from, 
witch is data and and not directly related to MAIL FROM/envelope from.




On 06/29/2016 10:50 AM, Kris Deugau wrote:

Chip wrote:

My mistake NOT "bounces-to" rather "return-path"

Return-path is a header added by the receiving MTA (usually on final
delivery) that contains the envelope sender (MAIL FROM) used by the
sending system.

Re: SMTP AUTH issue

[Emmanuel Fusté]

Le 14/03/2015 09:15, Viktor Dukhovni a écrit :

On Fri, Mar 13, 2015 at 06:13:56PM +0100, Emmanuel Fust? wrote:


Ok, what do you think about this one ?
I added XSASL_AUTH_TEMP in case of crashed / stopped dovecot auth server
too.

Looks fine to me.

What SMTP client is it by the way that treats a 535 in response to
AUTH as a reason to bounce the message, and would retry with a 4XX?
Postfix these days defers mail when authentication fails whether
the error is 4XX or 5XX.

 http://www.postfix.org/postconf.5.html#smtp_sasl_auth_soft_bounce

The patch may be more correct, but if MTAs generally understand
that SASL failure is always transient (either the client is
misconfigured and should not be using SASL, or authentication is
requirement and the details are misconfigured) then the patch is
perhaps unnecessary.

This is only a safety measure as now upstream servers use  postfix even 
if they are out of my control.
But later I will have to cope with more exotics ones like a lot of 
different  Exchange versions, and other unknown MTA.

So all correct and cheap safety guards are not superfluous in this case.

Thank you for your support.

Emmanuel.

Re: SMTP AUTH issue

[Emmanuel Fusté]

Le 13/03/2015 17:14, Emmanuel Fusté a écrit :

Le 11/03/2015 16:54, Emmanuel Fusté a écrit :

Le 11/03/2015 16:39, Viktor Dukhovni a écrit :

On Wed, Mar 11, 2015 at 01:41:00PM +0100, Emmanuel Fust? wrote:


Hello,

On a heavy i/o loaded Postfix (2.11.0) server, i've got this behavior:

535 5.7.8 Error: authentication failed: Connection lost to authentication server
Mar 10 16:37:08 x postfix/smtpd[20613]: warning: x.x.x[x.x.x.x]: SASL 
CRAM-MD5 authentication failed: Connection lost to authentication server

Ok, I have an i/o load problem with this server, but a 535 error code is too 
much, I was expecting a 454 error code as stated in RFC2554.

A complete solution would require handling similar problems for
Cyrus SASL, but I never got a meaningful response to:

   http://archives.neohapsis.com/archives/postfix/2008-12/0405.html
   https://www.mail-archive.com/postfix-users@postfix.org/msg56129.html

You could try the patch below and report your results (presumably
for Dovecot).  It would be nice to have confirmation for Cyrus
also.


Thank you !

Will test and report the result asap.

Regards,
Emmanuel.

Ok work as expected ! Thank you.
But to be complete, we should change XSASL_AUTH_FAIL - XSASL_AUTH_TEMP
in xsasl_dovecot_server_first (last and perhaps first occurrence too),
in xsasl_dovecot_server_next (last occurrence) .
Isn't it ?

Emmanuel.

Ok, what do you think about this one ?
I added XSASL_AUTH_TEMP in case of crashed / stopped dovecot auth server 
too.


Emmanuel.

diff -r -u postfix-2.11.0.orig/src/smtpd/smtpd_sasl_glue.c 
postfix-2.11.0/src/smtpd/smtpd_sasl_glue.c
--- postfix-2.11.0.orig/src/smtpd/smtpd_sasl_glue.c 2013-12-24 
21:55:03.0 +0100
+++ postfix-2.11.0/src/smtpd/smtpd_sasl_glue.c  2015-03-13 14:19:54.0 
+0100
@@ -316,8 +316,12 @@
 state-namaddr, sasl_method,
 STR(state-sasl_reply));
/* RFC 4954 Section 6. */
-   smtpd_chat_reply(state, 535 5.7.8 Error: authentication failed: %s,
-STR(state-sasl_reply));
+   if (status == XSASL_AUTH_TEMP)
+   smtpd_chat_reply(state, 454 4.7.0 Temporary authentication 
failure: %s,
+STR(state-sasl_reply));
+   else
+   smtpd_chat_reply(state, 535 5.7.8 Error: authentication failed: 
%s,
+STR(state-sasl_reply));
return (-1);
 }
 /* RFC 4954 Section 6. */
diff -r -u postfix-2.11.0.orig/src/xsasl/xsasl_cyrus_server.c 
postfix-2.11.0/src/xsasl/xsasl_cyrus_server.c
--- postfix-2.11.0.orig/src/xsasl/xsasl_cyrus_server.c  2015-03-13 
18:01:50.0 +0100
+++ postfix-2.11.0/src/xsasl/xsasl_cyrus_server.c   2015-03-13 
14:19:54.0 +0100
@@ -477,7 +477,13 @@
if (sasl_status == SASL_NOUSER) /* privacy */
sasl_status = SASL_BADAUTH;
vstring_strcpy(reply, xsasl_cyrus_strerror(sasl_status));
-   return (XSASL_AUTH_FAIL);
+   switch (sasl_status) {
+   case SASL_TRYAGAIN:
+   case SASL_UNAVAIL:
+   return XSASL_AUTH_TEMP;
+   default:
+   return (XSASL_AUTH_FAIL);
+   }
 }
 }
 
diff -r -u postfix-2.11.0.orig/src/xsasl/xsasl_dovecot_server.c 
postfix-2.11.0/src/xsasl/xsasl_dovecot_server.c
--- postfix-2.11.0.orig/src/xsasl/xsasl_dovecot_server.c2011-11-17 
22:53:25.0 +0100
+++ postfix-2.11.0/src/xsasl/xsasl_dovecot_server.c 2015-03-13 
17:43:34.0 +0100
@@ -580,7 +580,7 @@
 }
 
 vstring_strcpy(reply, Connection lost to authentication server);
-return XSASL_AUTH_FAIL;
+return XSASL_AUTH_TEMP;
 }
 
 /* is_valid_base64 - input sanitized */
@@ -637,7 +637,7 @@
 for (i = 0; i  2; i++) {
if (!server-impl-sasl_stream) {
if (xsasl_dovecot_server_connect(server-impl)  0)
-   return (0);
+   return XSASL_AUTH_TEMP;
}
/* send the request */
server-last_request_id = ++server-impl-request_id_counter;
@@ -668,7 +668,7 @@
 
if (i == 1) {
vstring_strcpy(reply, Can't connect to authentication server);
-   return XSASL_AUTH_FAIL;
+   return XSASL_AUTH_TEMP;
}
 
/*
@@ -696,7 +696,7 @@
CONT\t%u\t%s\n, server-last_request_id, request);
 if (vstream_fflush(server-impl-sasl_stream) == VSTREAM_EOF) {
vstring_strcpy(reply, Connection lost to authentication server);
-   return XSASL_AUTH_FAIL;
+   return XSASL_AUTH_TEMP;
 }
 return xsasl_dovecot_handle_reply(server, reply);
 }
diff -r -u postfix-2.11.0.orig/src/xsasl/xsasl.h 
postfix-2.11.0/src/xsasl/xsasl.h
--- postfix-2.11.0.orig/src/xsasl/xsasl.h   2009-04-19 01:39:16.0 
+0200
+++ postfix-2.11.0/src/xsasl/xsasl.h2015-03-13 14:19:54.0 +0100
@@ -121,6 +121,7 @@
 #define XSASL_AUTH_DONE3   /* Authentication completed */
 #define XSASL_AUTH_FORM4   /* Cannot decode response

Re: SMTP AUTH issue

[Emmanuel Fusté]

Le 11/03/2015 16:54, Emmanuel Fusté a écrit :

Le 11/03/2015 16:39, Viktor Dukhovni a écrit :

On Wed, Mar 11, 2015 at 01:41:00PM +0100, Emmanuel Fust? wrote:


Hello,

On a heavy i/o loaded Postfix (2.11.0) server, i've got this behavior:

535 5.7.8 Error: authentication failed: Connection lost to authentication server
Mar 10 16:37:08 x postfix/smtpd[20613]: warning: x.x.x[x.x.x.x]: SASL 
CRAM-MD5 authentication failed: Connection lost to authentication server

Ok, I have an i/o load problem with this server, but a 535 error code is too 
much, I was expecting a 454 error code as stated in RFC2554.

A complete solution would require handling similar problems for
Cyrus SASL, but I never got a meaningful response to:

  http://archives.neohapsis.com/archives/postfix/2008-12/0405.html
  https://www.mail-archive.com/postfix-users@postfix.org/msg56129.html

You could try the patch below and report your results (presumably
for Dovecot).  It would be nice to have confirmation for Cyrus
also.


Thank you !

Will test and report the result asap.

Regards,
Emmanuel.

Ok work as expected ! Thank you.
But to be complete, we should change XSASL_AUTH_FAIL - XSASL_AUTH_TEMP 
in xsasl_dovecot_server_first (last and perhaps first occurrence too), 
in xsasl_dovecot_server_next (last occurrence) .

Isn't it ?

Emmanuel.

Re: SMTP AUTH issue

[Emmanuel Fusté]

Le 11/03/2015 16:39, Viktor Dukhovni a écrit :

On Wed, Mar 11, 2015 at 01:41:00PM +0100, Emmanuel Fust? wrote:


Hello,

On a heavy i/o loaded Postfix (2.11.0) server, i've got this behavior:

535 5.7.8 Error: authentication failed: Connection lost to authentication server
Mar 10 16:37:08 x postfix/smtpd[20613]: warning: x.x.x[x.x.x.x]: SASL 
CRAM-MD5 authentication failed: Connection lost to authentication server

Ok, I have an i/o load problem with this server, but a 535 error code is too 
much, I was expecting a 454 error code as stated in RFC2554.

A complete solution would require handling similar problems for
Cyrus SASL, but I never got a meaningful response to:

 http://archives.neohapsis.com/archives/postfix/2008-12/0405.html
 https://www.mail-archive.com/postfix-users@postfix.org/msg56129.html

You could try the patch below and report your results (presumably
for Dovecot).  It would be nice to have confirmation for Cyrus
also.


Thank you !

Will test and report the result asap.

Regards,
Emmanuel.

SMTP AUTH issue

[Emmanuel Fusté]

Hello,

On a heavy i/o loaded Postfix (2.11.0) server, i've got this behavior:


=== Connected to x.x.x.x.
-  220 xx.xx.xx ESMTP Postfix
 - EHLO localhost
-  250-xx.xx.xx
-  250-PIPELINING
-  250-SIZE 1024
-  250-VRFY
-  250-ETRN
-  250-STARTTLS
-  250-AUTH CRAM-MD5 DIGEST-MD5
-  250-ENHANCEDSTATUSCODES
-  250-8BITMIME
-  250 DSN
 - AUTH CRAM-MD5
** 535 5.7.8 Error: authentication failed: Connection lost to 
authentication server

*** No authentication type succeeded
 - QUIT
-  221 2.0.0 Bye

In mail.log:

Mar 10 16:36:58 x postfix/smtpd[20613]: connect from xx
Mar 10 16:37:04 x dovecot: auth: Debug: client in: 
AUTH#0111#011CRAM-MD5#011service=smtp#011nologin#011lip=x.x.x.x#011rip=x.x.x.x
Mar 10 16:37:08 x postfix/smtpd[20613]: warning: x.x.x[x.x.x.x]: SASL 
CRAM-MD5 authentication failed: Connection lost to authentication server
Mar 10 16:37:08 x postfix/smtpd[20613]: disconnect from x.x.x[x.x.x.x]
Mar 10 16:37:14 x dovecot: auth: Debug: client passdb out: .
Mar 10 16:39:07 x dovecot: auth: Warning: auth client 0 disconnected 
with 1 pending requests: Connection reset by peer

Ok, I have an i/o load problem with this server, but a 535 error code is too 
much, I was expecting a 454 error code as stated in RFC2554.
As a workaround, I would like to increase the default postfix authentication 
server response timeout of 10 seconds but it seems that this is hard-coded.

Relevant postfix SASL configuration:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_authenticated_header = yes
smtpd_sender_login_maps = cdb:/etc/postfix/controlled_enveloppe_senders

So, I am missing something ? Should the error return code be corrected in 
postfix ? (and yes, my I/O load problem must be fixed...)

Best regards,
Emmanuel.

Re: tlsmgr high io load because of session cache

[Emmanuel Fusté]

Le 14/11/2014 18:47, Viktor Dukhovni a écrit :

On Fri, Nov 14, 2014 at 05:20:14PM +, Viktor Dukhovni wrote:


So gmail.com and postfix.org offer and actually reuses sessions,  On the
other hand, storing hotmail, AOL or Yahoo sessions is just a waste
of I/O, since they are rarely if ever reusable.

 $ posttls-finger -c -r 2 -m 1 -lmay -Lsummary,cache hotmail.com
 posttls-finger: looking for session 
[207.46.8.199]:25B3615E5BC0C51EF280EB79AC8C2D83BB5062B2BE73D21E5CD2AE6E5577D99934
 in memory cache
 posttls-finger: save session 
[207.46.8.199]:25B3615E5BC0C51EF280EB79AC8C2D83BB5062B2BE73D21E5CD2AE6E5577D99934
 to memory cache
 posttls-finger: Reconnecting after 2 seconds
 posttls-finger: looking for session 
[207.46.8.199]:257364A28B331EC120944E55777F8A2AF16784CDC5840C1BA6EF5FE028C66F993E
 in memory cache
 posttls-finger: save session 
[207.46.8.199]:257364A28B331EC120944E55777F8A2AF16784CDC5840C1BA6EF5FE028C66F993E
 to memory cache
 posttls-finger: Untrusted TLS connection established to 
mx4.hotmail.com[207.46.8.199]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 
(256/256 bits)

Note that the cache lookup key is different for the second connection.

To work with split caches for hosts behind load-balancers, Postfix
includes the server name from the remote EHLO response in the lookup
key, that way a small number of hosts behind a single IP address
each get their own cache entry.

This does not work very well when the load-balancer front-ends
hundreds or thousands of hosts, you almost rarely connect to
the same host again, while caching lots of discrete sessions.

The gmail cloud has a fixed EHLO server name:

 posttls-finger:  250-mx.google.com at your service

which works well with Postfix, because they have a unified session
cache with session tickets and shared keys across the cloud.  While
consecutive hotmail connections (to the same IP) may yield:

 posttls-finger:  250-BAY004-MC2F21.hotmail.com (3.20.0.138) Hello 
[192.0.2.1]
 posttls-finger:  250-BAY004-MC2F35.hotmail.com (3.20.0.138) Hello 
[192.0.2.1]

which results in a different cache slot.  I'd have to write new
code to determine whether suppressing the EHLO response session
lookup key salt would lead to better cache utilization for the
various large cloud provider domains.

Determining this dynamically, would require keeping some statistics
on cache re-use by IP, and switching from salted to unsalted to
off, if cache re-use is sufficiently poor.  The code for that would
require some care.  Not promising anything any time soon.


Hello Viktor,

Side questions about session cache.
If I have some postfix smtpd physical servers behind a load-balancer, 
how could I setup them to be TLS client session cache friendly ?

- same EHLO
- same keys (and certificate ?).
- shared memcached session cache
and the same questions but to be session ticket friendly: no need of the 
shared memcached, but for the other things ?


Emmanuel.

Re: Small Enhancement Request

[Emmanuel Fusté]

Le 10/10/2014 06:40, Ronald F. Guilmette a écrit :

In message 20141010030256.gw13...@mournblade.imrryr.org,
Viktor Dukhovni postfix-us...@dukhovni.org wrote:


On Thu, Oct 09, 2014 at 10:28:52AM -0700, Ronald F. Guilmette wrote:


What happens if in fact the matching rules specified in the access(5)
man page resulted in matching _multiple_ things at the same priority/
precedence level?  For example, what if I had the following table:

domain.tld  PREPEND X-Foo: bar
domain.tld  PREPEND X-Bar: for

Now you're showing a misunderstanding of Postfix tables.  They are
key-value mappings.

Actually, I *did* (and do) understand that point.  I was just asking
for it to be confirmed, since another poster suggested yielding
multiple values for a single lookup key, which on the face of it made
no sense to me.

Yes, I use one table per header I need to prepend for a match, with the 
same match in each table.

Sorry for the misguided multivalued key suggestion.

Emmanuel.

Re: Small Enhancement Request

[Emmanuel Fusté]

Le 09/10/2014 07:43, Ronald F. Guilmette a écrit :

This is a request for a very minor change to the semantics of the
PREPEND text result that can be returned from policy servers
and/or from specific entries within an access(5) lookup table.

It would be maximally convenient if the subject text could be
interpolated in the following trivial way:

  Any literal \n (backslash-n) sequence withing text is
  replaced with an actual newline character.

This trivial change would allow prepending of multiple headers
to the current e-mail message.

This capability would be useful in the context of systems that
tag incoming messages for later analysis and/or special processing
by tools external to the mail server.

Alternatively, given that the Postfix policy server protocol
theoretically allows for the possibility of a policy server
yielding multiple action=PREPEND text results in response
to any given single request (from Postfix), it would be Nice if
Postfix would in fact accept a sequence of multiple such responses
from a policy server in response to a single request.

Hello,

Do you tried multiple PREPEND result for the same pattern in an access 
table (or a table for each header to PREPEND)?
As the PREPEND action does not accept or reject the message, it 
should be view as a DUNNO action for the evaluation of the access rule.


Emmanuel.

Re: reject_sender_login_mismatch behavior

[Emmanuel Fusté]

Le 16/09/2013 18:43, Viktor Dukhovni a écrit :

On Mon, Sep 16, 2013 at 11:24:12AM -0400, Wietse Venema wrote:


So I think putting sender first and indicating that *only*
listed senders are in scope makes sense:

reject_restricted_sender_wrong_login

this should likely automatically imply reject_unauth_sender_login_mismatch
(to protect said restricted sender addresses from misuse when the
client does not authenticate).  (Thus a small change in the proposed code).

I think the following introduces the least amount of confusion.

reject_sender_login_mismatch
  [this definition does not change]

reject_authenticated_sender_login_mismatch
  Apply the reject_sender_login_mismatch restriction
  only to clients that are SASL-authenticated.

reject_unauthenticated_sender_login_mismatch
  Apply the reject_sender_login_mismatch restriction
  only to clients that are not SASL-authenticated.

reject_known_sender_login_mismatch
  Apply the reject_sender_login_mismatch restriction only to
  MAIL FROM addresses that are known in $smtpd_sender_login_maps.

This works for me, and also sensibly applies to both authenticated
and unauthenticated clients.


Woaou, I leave 24h and all is there.
Viktor, Wietse, thank you !

Emmanuel.

Re: anlyzing sudden spam flood, how?

[Emmanuel Fusté]

Le 18/09/2013 05:40, Viktor Dukhovni a écrit :

On Wed, Sep 18, 2013 at 01:00:48PM +1000, li...@sbt.net.au wrote:


Return-Path: bayedfresc...@reuters.com
...
Received: from p2p (unknown [124.11.170.87])
  by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
  for vvv...@domain.tld; Wed, 18 Sep 2013 08:13:25 +1000 (EST)

Everything below this Received header is fiction.  The EHLO name
is not an FQDN and the IP address does not have matching forward
and reverse addresses.

You could try:

 main.cf:
# Preferred RE map type:
RE = pcre:${config_directory}/

# HELO restrictions for remote clients
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access ${RE}helo.re

 helo.re
# Clients with non-fqdn HELO names MUST have working FCrDNS
/^[^.]*$/   reject_unknown_client_hostname


[...]

Hello Viktor,

In an access table, could I use any postfix reject_xxx and 
permit_xxx directive ?

I did not find it in the documentation. It could be very powerfull.

Emmanuel.

Re: anlyzing sudden spam flood, how?

[Emmanuel Fusté]

Le 18/09/2013 12:48, Wietse Venema a écrit :

Wietse Venema:

Emmanuel Fust?:

In an access table, could I use any postfix reject_xxx and
permit_xxx directive ?
I did not find it in the documentation. It could be very powerfull.

It *is* documented.

OTHER ACTIONS
restriction...
   Applythe   named   UCE   restriction(s)   (permit,   reject,
   reject_unauth_destination, and so on).

And, this is in fact the supported way to implement per-sender (or
per-client, per-recipient, etc.) access policies. You index the
table with the sender (or client, recipient, etc.) and specify
some policy on the right-hand side. You can use this in the
middle of a longer access list.

Wietse

Ok, got it, thank you.
I think that it deserve more than just this paragraph.
I was looking how to do better per sender access policy and completely 
overlook this paragraph !

I'm sorry, all my apologies.

Emmanuel.

reject_sender_login_mismatch behavior

[Emmanuel Fusté]

Hello,

I did not find a way to emulate the behavior of 
reject_sender_login_mismatch for authenticated connexions as for 
unauthenticated connexions.
I need that as in the unauthenticated case, if the envelope sender is 
not in the smtpd_sender_login_maps maps, the request is accepted.

Is there any way to get this behavior ?
If no, is something like reject_sender_login_mismatch_relaxed and 
reject_authenticated_sender_login_mismatch_relaxed could be added on a 
todo list ?


Thanks,
Emmanuel.

Re: reject_sender_login_mismatch behavior

[Emmanuel Fusté]

Le 16/09/2013 12:41, Wietse Venema a écrit :

Emmanuel Fust?:

Hello,

I did not find a way to emulate the behavior of
reject_sender_login_mismatch for authenticated connexions as for
unauthenticated connexions.

reject_authenticated_sender_login_mismatch
   Enforces  the   reject_sender_login_mismatch   restriction   for
   authenticated clients only. This feature is available in Postfix
   version 2.1 and later.

reject_unauthenticated_sender_login_mismatch
   Enforces  the reject_sender_login_mismatch restriction for unau-
   thenticated clients only. This feature is available  in  Postfix
   version 2.1 and later.


Wietse

Sorry, I think I was not clear.
With reject_sender_login_mismatch :
- In the case of unauthenticated connexions, if the envelope sender 
address is not in the map (no know SASL owner), the mail is accepted.
- In the case of authenticated connexions, if the envelope sender 
address is not in the map (no know SASL owner), the mail is rejected.


I want to reject the mail for authenticated and unauthenticated 
connexions if a SASL owner for the envelope sender address is know and  
in the case of an authenticated connexion does not match.

reject_sender_login_mismatch is good for that.
But in either case, I want to accept the email if the envelope address 
is not in the map. With the described behavior of 
reject_sender_login_mismatch (which is in conformance with the 
documentation), it is not the case.


Are you saying that instead of using reject_sender_login_mismatch, 
using reject_authenticated_sender_login_mismatch, 
reject_unauthenticated_sender_login_mismatch will give me what I want ?


Thank you,
Emmanuel.

Re: reject_sender_login_mismatch behavior

[Emmanuel Fusté]

Le 16/09/2013 14:35, Wietse Venema a écrit :

Emmanuel Fust?:

But in either case, I want to accept the email if the envelope address
is not in the map.

Given that reject_sender_login_mismatch is implemented internally
as an alias for reject_authenticated_sender_login_mismatch,
reject_unauthenticated_sender_login_mismatch, the definitions can
be rewritten as:

 reject_unauthenticated_sender_login_mismatch
Reject the request when $smtpd_sender_login_maps specifies
an owner for the MAIL FROM address, but the client is not
(SASL) logged in as that MAIL FROM address owner

The above becomes a NOOP when the sender addresses is not listed in
$smtpd_sender_login_maps.

 reject_authenticated_sender_login_mismatch
Reject the request when the client is (SASL) logged in, but
the client login name doesn't own the MAIL FROM address
according to $smtpd_sender_login_maps.

The above will reject mail when the sender addresses is not listed
in $smtpd_sender_login_maps. It forces authenticated users to use
their proper sender address.

If you want to reject authenticated sender/login mis-matches only
for sender addresses in $smtpd_sender_login_maps, then that would
have to be a completely different feature, with a clear name, and
with clearly defined semantics.

  reject_something_here_that_doesnt_confuse_the_hell_out_of_real_humans
Reject the request when the client is (SASL) logged in, but
the MAIL FROM address is owned by a different client login
name according to $smtpd_sender_login_maps.

The above would will reject mail only when the sender address is
owned by a different customer.

Wietse

Thank you for the detailed explanation.
This is exactly how I understood how it work.
So I need this new completely different feature.

Is it something that could be added to the postfix todo list ?
I know that your resources to devellop Postfix is limited. I will try to 
implement it myself and propose a patch, but I'm not sure I have the 
skills to do so.


Emmanuel.

Re: serious bug with check_client_access

[Emmanuel Fusté]

Le 04/11/2010 05:24, Noel Jones a écrit :

On 11/3/2010 11:07 PM, Vincent Lefevre wrote:

BTW, so, there is no way to match only subdomains (by that, I mean
all possible subdomains, but not the domain itself) without changing
parent_domain_matches_subdomains?


That's correct with indexed tables.  With regexp or pcre tables there
is no automatic subdomain search; you control the scope of the search
with your expression.

To answer your other question, when parent_domain_matches_subdomains
includes smtpd_access_maps (the default), the form .domain.tld is
never searched for. As a result, the entry is silently ignored.

  -- Noel Jones

Good to know, that is not what I expected too.
Hopefully, I generaly clear parent_domain_matches_subdomains in my 
configurations.


Emmanuel.

Sub-domains ignore transport relayhost

[Emmanuel Fusté]

Hello,

Relevant config parameters:

parent_domain_matches_subdomains =
relay_domains = hash:some_relay_domains_map
relay_relayhost = [a.b.c.d]

some_relay_domains_map contain:

xxx.comx
yyy.comx
aaa.xxx.comx
bbb.yyy.comx

symptom:
messages for xxx.com and yyy.com are correctly relayed to [a.b.c.d]
messages for aaa.xxx.com and bbb.yyy.com are tried to be delivered 
directly to the MX of aaa.xxx.com and bbb.yyy.com.


Workaround:
With a transport map, I force these subdomains to be routed to [a.b.c.d]:
aaa.xxx.comrelay:[a.b.c.d]
bbb.yyy.comrelay:[a.b.c.d]

Note: using simply aaa.xxx.comrelay: or bbb.xxx.comrelay: in 
the transport map is not sufficient witch seems to imply that the 
problem is not the selection of the right transport but that 
relay_relayhost = [a.b.c.d] is ignored in the subdomain case.


Is this an expected behavior ? or a bug ?
It reminds me a previous discussion but I could not find it in my mail 
archives.

I use Postfix 2.5.4.
I checked all release notes and changelog of newer version but did not 
find any relevant changes.


Best regards,
Emmanuel.

Re: Sub-domains ignore transport relayhost

[Emmanuel Fusté]

Le 01/04/2010 15:20, Wietse Venema a écrit :

Emmanuel Fust�:

relay_relayhost = [a.b.c.d]


As always, use postconf -n output when reporting a problem. This
would have revealed immediately that relay_relayhost is a mistake.

Wietse


Ok so transport_postfix-conf-parameter is no longer a supported syntax ?

I double check and you're right: the main domains are working by 
accident (MX=relayhost gateway).


Yes I know that postconf -n did not report relay_relayhost = 
[a.b.c.d] but I was fooled by my half working setup.


Could I achieve my goal with modifying the relay line in the master.cf like:

relay unix  -   -   -   -   -   smtp
-o smtp_fallback_relay=
-o relayhost= [a.b.c.d]

Or should I simply use the transport map and stop doing silly things ;-)

Best regards,
Emmanuel.

Re: SNMP + MTA-MIB + Postfix

[Emmanuel Fusté]

Wietse Venema a écrit :

Ralf Hildebrandt:
  

* no7find - no7f...@gmail.com:


Hi list !

I want to know if there is any implementation of MTA-MIB (defined @ RFC
2789) for the Postfix.
  


The answer is: type SNMP into the search window at http://www.postfix.org.

  
Sounds like something qmgr would keep track of 
http://www.faqs.org/rfcs/rfc2789.html



In the spirit of the Postfix architecture, this would involve:

- A new protocol to send statistics or events.

- A new server process that receives statistics or events from
  Postfix processes, and that provides READ-ONLY access via SNMP.

- A new client library to send statistics or events from a Postfix
  process.

Wietse
  

Yes, it is a BIG piece of work to achieve this correctly. But it would
be a must.
In corporate environment, it is now a big pain for us to provide
accurate realtime metrics, reliable weekly statistics which are
mandatory things requested  by  our  bosses. Big piles of pearl scripts
to post process logs, or parse them as they arrive have limits.
This is a lot of additional work and would be a big piece of code not
involved in improving the capability of postfix to do his job as an SMTP
mailer, but it would greatly improve our life as sysadmins ;-)

Emmanuel.

Re: SNMP + MTA-MIB + Postfix

[Emmanuel Fusté]

Ralf Hildebrandt a écrit :

* Emmanuel Fusté emmanuel.fu...@external.thalesgroup.com:

  

In corporate environment, it is now a big pain for us to provide
accurate realtime metrics, reliable weekly statistics which are
mandatory things requested  by  our  bosses. Big piles of pearl scripts
to post process logs, or parse them as they arrive have limits.
This is a lot of additional work and would be a big piece of code not
involved in improving the capability of postfix to do his job as an SMTP
mailer, but it would greatly improve our life as sysadmins ;-)



mailgraph and queuegraph do this out of the box.

  

Yes thanks, already in use here.