Re: New default settings for submission service?

[Robert Schetterer]

Am 16.03.2012 00:02, schrieb Ed W:
 On 15/03/2012 13:01, Victoriano Giralt wrote:

 DTNX/NGMX Postmasterpostmas...@dtnx.net  wrote:

 I don't know about Android, but we have not seen any issues with the
 iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested
 above.
 In my experience, both the manufacturer provided and added mail
 clients I have tryed in Android have had no issues with TLS.


 
 I forget the exact issue now, but note that I'm not saying that it
 *can't* work.  What I'm saying is that I have a bunch of normal non
 technical users.  Johnny runs through the wizard on his favourite
 device and then costs me money in tech support time if it doesn't work
 first time.  The issue was something like this device either defaulting
 to non TLS (and not coping with the server requiring it), or he couldn't
 find the button to enable it?
 
 I *encourage* TLS on all new installations, and in fact all the Apple
 stuff and new Microsoft /Mozilla clients seem to default to TLS
 (great).  But at the same time I don't see the issue if someone
 *chooses* (or the defaults exclude) to avoid TLS and talk plaintext
 
 Oh, and after the latest firmware update for my Nokia N9 (lovely
 phone...) I don't seem to be able to do TLS anymore... Vodafone requires
 that you use submission in the UK by blocking port 25, so it's helpful
 to be able to use submission without TLS at least until I figure out why
 it's not working anymore...
 
 My point was only not *enforcing* it, rather than it shouldn't be
 supported?  May, not Required.
 
 
 (A slightly off the wall reason for plaintext is that there are still
 users on dialup.  In particular my business supports users on a
 (2.4Kbit) 300 byte/sec dialup satellite modem which costs $1.50/min. 
 Enabling TLS costs you $1-3 in additional connect time, plus lack of PPP
 compression increases the cost by about a factor of 3.  Although we are
 clearly not talking about the average user now, I think it would focus
 your mind if I asked if you would be happy to increase your monthly
 internet bill by a few hundred dollars vs risking going plain text?)
 
 Cheers
 
 Ed W
 
 

Hi Ed , an example in a config should run right out of the box with
commented basics if its getting to  use.

It cant cover all specials in the world unless you dont want to have
mass of examples, at last in case of postfix, its the job of the postmaster
to cover his local needs, by edit examples, or asking on this list,
reading books etc

all your described special cases can be matched
from general you can use smtp over nearly every port with tls
if this makes sense to you and your place,
at the end its not the job of postfix trying match all existing
firewall setups or client defaults right out of the box
cause this must fail ever

the examples should only demonstrate basics in what can get configured in a
relativ safe


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: New default settings for submission service?

[Ed W]

On 16/03/2012 07:06, Robert Schetterer wrote:

I forget the exact issue now, but note that I'm not saying that it
*can't* work.  What I'm saying is that I have a bunch of normal non
technical users.  Johnny runs through the wizard on his favourite
device and then costs me money in tech support time if it doesn't work
first time.  The issue was something like this device either defaulting
to non TLS (and not coping with the server requiring it), or he couldn't
find the button to enable it?

I *encourage* TLS on all new installations, and in fact all the Apple
stuff and new Microsoft /Mozilla clients seem to default to TLS
(great).  But at the same time I don't see the issue if someone
*chooses* (or the defaults exclude) to avoid TLS and talk plaintext

Oh, and after the latest firmware update for my Nokia N9 (lovely
phone...) I don't seem to be able to do TLS anymore... Vodafone requires
that you use submission in the UK by blocking port 25, so it's helpful
to be able to use submission without TLS at least until I figure out why
it's not working anymore...

My point was only not *enforcing* it, rather than it shouldn't be
supported?  May, not Required.





Hi Ed , an example in a config should run right out of the box with
commented basics if its getting to  use.

It cant cover all specials in the world unless you dont want to have
mass of examples, at last in case of postfix, its the job of the postmaster
to cover his local needs, by edit examples, or asking on this list,
reading books etc

all your described special cases can be matched
from general you can use smtp over nearly every port with tls
if this makes sense to you and your place,
at the end its not the job of postfix trying match all existing
firewall setups or client defaults right out of the box
cause this must fail ever

the examples should only demonstrate basics in what can get configured in a
relativ safe


You are arguing in circles.  The original point of this thread was to 
suggest the defaults better match sensible out of the box defaults.  The 
specs say may offer TLS (not required).  I'm highlighting that 
recently I had to change my (non default, TLS required) settings for 
submissions to make TLS optional because there existed some client which 
puked when connecting to a *mandatory* TLS setup.


Therefore I'm suggesting that the out of the box config matches the 
*RFC*.  Then if the mail owner wants to lock it down to some non RFC 
suggested spec they can read the instructions.


You seem to be advocating the out of the box defaults should not match 
the RFC, fail to allow at least a small number of clients to connect and 
that the mail server owner should read the instructions to get their box 
working in line with RFC?


If we are going to adjust the defaults can we please match the RFC?

Thanks

Ed W

Re: New default settings for submission service?

[Wietse Venema]

Ed W:
 Therefore I'm suggesting that the out of the box config matches the 
 *RFC*.  Then if the mail owner wants to lock it down to some non RFC 
 suggested spec they can read the instructions.

SHOULD does not forbid mandatory TLS; only a twisted mind will read
this as support for plaintext is required. Besides, RFCs are not
the only relevant guidelines. There are plenty other guidelines
that frowm upon plaintext passwords over plaintext connections.

Wietse

Re: New default settings for submission service?

[Ed W]

On 16/03/2012 11:57, Wietse Venema wrote:

Ed W:

Therefore I'm suggesting that the out of the box config matches the
*RFC*.  Then if the mail owner wants to lock it down to some non RFC
suggested spec they can read the instructions.

SHOULD does not forbid mandatory TLS; only a twisted mind will read
this as support for plaintext is required. Besides, RFCs are not
the only relevant guidelines. There are plenty other guidelines
that frowm upon plaintext passwords over plaintext connections.

Wietse


My understanding is that the proposed settings would require TLS even in 
the event of encrypted password exchange?


There are plenty of reasons to *dislike* non TLS connections, but 
*banning* plain text seems harsh?


Unless I missed something there should also be no RFC complaints with 
accepting TLS over port 25?  I believe I have my postfix currently 
configured this way.


Personally I would vote for smtpd_tls_security_level = may to become 
part of the default postfix config (or is it... durr..) so that every 
service can accept TLS by default.  In fact, what objection would you 
raise for this even to become the default for all services where it 
makes sense?  Then the config can switch to either forcing it off/on as 
the owner feels fit?

Re: New default settings for submission service?

[Charles Marcus]

On 2012-03-16 6:41 AM, Ed W li...@wildgooses.com wrote:

You are arguing in circles.  The original point of this thread was to
 suggest the defaults better match sensible out of the box defaults.
The specs say may offer TLS (not required).


No, they say *should*, which, in my book, is the best argument for the 
default to be TLS enabled *and* enforced.


But it doesn't really matter to me, since I know how to require it.

--

Best regards,

Charles

Re: New default settings for submission service?

[Wietse Venema]

Ed W:
 Therefore I'm suggesting that the out of the box config matches the
 *RFC*.  Then if the mail owner wants to lock it down to some non RFC
 suggested spec they can read the instructions.

Wietse:
 SHOULD does not forbid mandatory TLS; only a twisted mind will read
 this as support for plaintext is required. Besides, RFCs are not
 the only relevant guidelines. There are plenty other guidelines
 that frowm upon plaintext passwords over plaintext connections.

Ed W:
 My understanding is that the proposed settings would require TLS even in 
 the event of encrypted password exchange?

The proposed example configuration can be modified when a site has
submission users who traverse links with high latency, low bandwidth,
intermittent connectivity, etc.

It is not practical to provide an example for every scenario; only
one example will suffice, and it will cover the most common case.

Wietse

Re: New default settings for submission service?

[Ulrich Zehl]

On Wed, Mar 14, 2012 at 08:52:54PM -0500, Noel Jones wrote:
 Yes, I would always choose telnet first.  Unfortunately, if you want
 to test an encrypted session telnet fails miserably.
 
 The [press R to renegotiate] behavior of s_client is documented and,
 last time I looked, can't be disabled.
 
 At any rate, s_client is intended for testing.  If your hashed test
 password string has an R in it, use a different test password.

For basic testing, I tend to use gnutls-cli --starttls, where it starts a
plain text session, and only begins TLS negotiation when you send it EOF
(or SIGALRM, but ^D has always been easy enough for me).
As far as I know, it has no other special characters that trigger
potentially unwanted behavior.

Ulrich

Re: New default settings for submission service?

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Ulrich Zehl ulrich-post...@topfen.net wrote:

For basic testing, I tend to use gnutls-cli --starttls, where it
starts a
plain text session, and only begins TLS negotiation when you send it
EOF
(or SIGALRM, but ^D has always been easy enough for me).
As far as I know, it has no other special characters that trigger
potentially unwanted behavior.
And I have found that gnutls-climate is better for testing IPv6 servers.

- --
Victoriano Giralt
Enviado desde el movil / Sent from mobile
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iHQEAREIADQFAk9huPktHFZpY3Rvcmlhbm8gR2lyYWx0IDx2aWN0b3JpYW5vLmdp
cmFsdEB1bWEuZXM+AAoJEFevpg449T04uNUAn1vlWgE3OLVF0d755Rum5DHg6a0w
AJ9C55okVQk5vI2opBiLGAy9O21uUA==
=7oI7
-END PGP SIGNATURE-

Re: New default settings for submission service?

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Victoriano Giralt victori...@uma.es wrote:

And I have found that gnutls-climate is better for testing IPv6
servers.
Stupid autocorrection, I meant gnutls-cli

- --
Victoriano Giralt
Enviado desde el movil / Sent from mobile
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iHQEAREIADQFAk9hugAtHFZpY3Rvcmlhbm8gR2lyYWx0IDx2aWN0b3JpYW5vLmdp
cmFsdEB1bWEuZXM+AAoJEFevpg449T04aH0An32MOaIsyfClhOpL+HOKtkm8cWVI
AJ9zVuUrhd2ZFaJwi4+enKca4rZzaA==
=HGcy
-END PGP SIGNATURE-

Re: New default settings for submission service?

[SamLT]

On Thu, Mar 15, 2012 at 10:44:33AM +0100, Victoriano Giralt wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 
 
 Victoriano Giralt victori...@uma.es wrote:
 
 And I have found that gnutls-climate is better for testing IPv6
 servers.
 Stupid autocorrection, I meant gnutls-cli

Sorry for the OT, but does s_client even works with IPv6? I've never
found how?


 
 - --
 Victoriano Giralt
 Enviado desde el movil / Sent from mobile
 -BEGIN PGP SIGNATURE-
 Version: APG v1.0.8
 
 iHQEAREIADQFAk9hugAtHFZpY3Rvcmlhbm8gR2lyYWx0IDx2aWN0b3JpYW5vLmdp
 cmFsdEB1bWEuZXM+AAoJEFevpg449T04aH0An32MOaIsyfClhOpL+HOKtkm8cWVI
 AJ9zVuUrhd2ZFaJwi4+enKca4rZzaA==
 =HGcy
 -END PGP SIGNATURE-
 

Re: New default settings for submission service?

[DTNX/NGMX Postmaster]

On Mar 14, 2012, at 19:39, Ed W wrote:

 On 13/03/2012 23:50, Wietse Venema wrote:
 #submission inet n   -   n   -   -   smtpd
 #  -o syslog_name=postfix/submission
 #  -o smtpd_tls_security_level=encrypt
 
 I forget the exact details now, but one mail client, I think it might be an 
 Android or iPhone mail client(?) defaults to using the submission service but 
 without encryption.  The error messages were confusing and unhelpful to the 
 customer and I just recall it took some time to realise that it was the 
 enforced tls requirement that was the problem
 
 I see no reason to *require* encryption on the submission port (RFC aside).  
 I think may is a more appropriate default?

I don't know about Android, but we have not seen any issues with the 
iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested above.

Cya,
Jona

Re: New default settings for submission service?

[DTNX/NGMX Postmaster]

On Mar 14, 2012, at 21:03, Patrick Ben Koetter wrote:

 * Charles Marcus cmar...@media-brokers.com:
 On 2012-03-14 2:39 PM, Ed W li...@wildgooses.com wrote:
 I see no reason to *require* encryption on the submission port (RFC
 aside).
 
 Unless you prefer that sniffers not be able to see your passwords
 crossing the wire in plaintext?
 
 I think may is a more appropriate default?
 
 Disagree vehemently.
 
 The RFC on submission is clear about that. It says SHOULD and not MUST. It is
 safe to AUTH if you use cram-md5, digest-md5, ntlm or any other non-plaintext
 mechanism. Forcing TLS by default is safer, but it pushes a policy on people
 the SHOULD decide themselves, I think.

From what I remember when we spent some time deciding our new defaults, all
the methods that hash the password before sending it over the wire require
that the server stores the plaintext, or at least the hashed versions of it.
This was considered insecure, so we went with enforced TLS, and 'plain' auth
only.

Also, in our experience, pushing a policy that leaves no wiggle room tends
to be a Good Thing for most users. To each their own, of course :-)

Cya,
Jona

OT Re: New default settings for submission service?

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



SamLT s...@sltosis.org wrote:

Sorry for the OT, but does s_client even works with IPv6? I've never
found how?
In my experience, limited to bare IPv6 addresses, it does not.

- --
Victoriano Giralt
Enviado desde el movil / Sent from mobile
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iHQEAREIADQFAk9h50ItHFZpY3Rvcmlhbm8gR2lyYWx0IDx2aWN0b3JpYW5vLmdp
cmFsdEB1bWEuZXM+AAoJEFevpg449T04+uYAoIlzptZ6j3D6WUTvOtJ02oByrrxq
AJ4vxEAt34q5txTSMikvyv9zBbroWQ==
=yFTS
-END PGP SIGNATURE-

Re: New default settings for submission service?

[Victoriano Giralt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



DTNX/NGMX Postmaster postmas...@dtnx.net wrote:

I don't know about Android, but we have not seen any issues with the
iPhone/iPad. Works fine with TLS 'encrypt' in our setups, as suggested
above.
In my experience, both the manufacturer provided and added mail clients I have 
tryed in Android have had no issues with TLS.

- --
Victoriano Giralt
Enviado desde el movil / Sent from mobile
-BEGIN PGP SIGNATURE-
Version: APG v1.0.8

iHQEAREIADQFAk9h6DAtHFZpY3Rvcmlhbm8gR2lyYWx0IDx2aWN0b3JpYW5vLmdp
cmFsdEB1bWEuZXM+AAoJEFevpg449T04YjsAn1GSr8WPGOJlUZKrYBb0ybf5UAe5
AJsHYhU2z7vBycfR2uq/mOZ+/lo+dQ==
=L+yZ
-END PGP SIGNATURE-

Re: New default settings for submission service?

[Ed W]

On 13/03/2012 23:50, Wietse Venema wrote:

#submission inet n   -   n   -   -   smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt


I forget the exact details now, but one mail client, I think it might be 
an Android or iPhone mail client(?) defaults to using the submission 
service but without encryption.  The error messages were confusing and 
unhelpful to the customer and I just recall it took some time to realise 
that it was the enforced tls requirement that was the problem


I see no reason to *require* encryption on the submission port (RFC 
aside).  I think may is a more appropriate default?


Ed W

Re: New default settings for submission service?

[Charles Marcus]

On 2012-03-14 2:39 PM, Ed W li...@wildgooses.com wrote:

I see no reason to *require* encryption on the submission port (RFC
aside).


Unless you prefer that sniffers not be able to see your passwords 
crossing the wire in plaintext?



I think may is a more appropriate default?


Disagree vehemently.

--

Best regards,

Charles

Re: New default settings for submission service?

[Wietse Venema]

Ed W:
 On 13/03/2012 23:50, Wietse Venema wrote:
  #submission inet n   -   n   -   -   smtpd
  #  -o syslog_name=postfix/submission
  #  -o smtpd_tls_security_level=encrypt
 
 I forget the exact details now, but one mail client, I think it might be 
 an Android or iPhone mail client(?) defaults to using the submission 
 service but without encryption.  The error messages were confusing and 
 unhelpful to the customer and I just recall it took some time to realise 
 that it was the enforced tls requirement that was the problem
 
 I see no reason to *require* encryption on the submission port (RFC 
 aside).  I think may is a more appropriate default?

That's not a problem for me. I don't use the submission service
and rely on input from the real world for this.

Wietse

Re: New default settings for submission service?

[Wietse Venema]

Wietse Venema:
 Ed W:
  On 13/03/2012 23:50, Wietse Venema wrote:
   #submission inet n   -   n   -   -   smtpd
   #  -o syslog_name=postfix/submission
   #  -o smtpd_tls_security_level=encrypt
  
  I forget the exact details now, but one mail client, I think it might be 
  an Android or iPhone mail client(?) defaults to using the submission 
  service but without encryption.  The error messages were confusing and 
  unhelpful to the customer and I just recall it took some time to realise 
  that it was the enforced tls requirement that was the problem
  
  I see no reason to *require* encryption on the submission port (RFC 
  aside).  I think may is a more appropriate default?
 
 That's not a problem for me. I don't use the submission service
 and rely on input from the real world for this.

Meaning, may, combined with a setting that allows plaintext
passwords only over encrypted connections.  Not sure if that makes
trouble shooting easier than when TLS is always required, though.

Wietse

Re: New default settings for submission service?

[Patrick Ben Koetter]

* Charles Marcus cmar...@media-brokers.com:
 On 2012-03-14 2:39 PM, Ed W li...@wildgooses.com wrote:
 I see no reason to *require* encryption on the submission port (RFC
 aside).
 
 Unless you prefer that sniffers not be able to see your passwords
 crossing the wire in plaintext?
 
 I think may is a more appropriate default?
 
 Disagree vehemently.

The RFC on submission is clear about that. It says SHOULD and not MUST. It is
safe to AUTH if you use cram-md5, digest-md5, ntlm or any other non-plaintext
mechanism. Forcing TLS by default is safer, but it pushes a policy on people
the SHOULD decide themselves, I think.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Patrick Ben Koetter]

* Wietse Venema postfix-users@postfix.org:
 Wietse Venema:
  Ed W:
   On 13/03/2012 23:50, Wietse Venema wrote:
#submission inet n   -   n   -   -   smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
   
   I forget the exact details now, but one mail client, I think it might be 
   an Android or iPhone mail client(?) defaults to using the submission 
   service but without encryption.  The error messages were confusing and 
   unhelpful to the customer and I just recall it took some time to realise 
   that it was the enforced tls requirement that was the problem
   
   I see no reason to *require* encryption on the submission port (RFC 
   aside).  I think may is a more appropriate default?
  
  That's not a problem for me. I don't use the submission service
  and rely on input from the real world for this.
 
 Meaning, may, combined with a setting that allows plaintext
 passwords only over encrypted connections.  Not sure if that makes
 trouble shooting easier than when TLS is always required, though.

It does. One can test CRAM-MD5 also in a telnet session. The SASL_README
refers to a script, gen-auth, that assists creating the necessary response.

p@rick


-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Wietse Venema]

Patrick Ben Koetter:
   That's not a problem for me. I don't use the submission service
   and rely on input from the real world for this.
  
  Meaning, may, combined with a setting that allows plaintext
  passwords only over encrypted connections.  Not sure if that makes
  trouble shooting easier than when TLS is always required, though.
 
 It does. One can test CRAM-MD5 also in a telnet session. The SASL_README
 refers to a script, gen-auth, that assists creating the necessary response.

What about openssl s_client instead of telnet?

Just avoid typing R.

Wietse

Re: New default settings for submission service?

[Patrick Ben Koetter]

* Wietse Venema postfix-users@postfix.org:
 Patrick Ben Koetter:
That's not a problem for me. I don't use the submission service
and rely on input from the real world for this.
   
   Meaning, may, combined with a setting that allows plaintext
   passwords only over encrypted connections.  Not sure if that makes
   trouble shooting easier than when TLS is always required, though.
  
  It does. One can test CRAM-MD5 also in a telnet session. The SASL_README
  refers to a script, gen-auth, that assists creating the necessary response.
 
 What about openssl s_client instead of telnet?

To my knowledge s_client is not a fully featured SMTP client or telnet
replacement. It is fine to see output about the TLS session, but once I
proceed I usally get errors.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Noel Jones]

On 3/14/2012 4:50 PM, Patrick Ben Koetter wrote:
 * Wietse Venema postfix-users@postfix.org:
 Patrick Ben Koetter:
 That's not a problem for me. I don't use the submission service
 and rely on input from the real world for this.

 Meaning, may, combined with a setting that allows plaintext
 passwords only over encrypted connections.  Not sure if that makes
 trouble shooting easier than when TLS is always required, though.

 It does. One can test CRAM-MD5 also in a telnet session. The SASL_README
 refers to a script, gen-auth, that assists creating the necessary response.

 What about openssl s_client instead of telnet?
 
 To my knowledge s_client is not a fully featured SMTP client or telnet
 replacement. It is fine to see output about the TLS session, but once I
 proceed I usally get errors.
 
 p@rick
 


AFAIK OpenSSL works OK for testing SMTP as long as you avoid
sending/pressing the upper-case R character, which triggers TLS
renegotiation (and an SMTP error).  Issuing the SMTP commands in
lower-case is the usual workaround.
But if your hashed password contains an R you're out of luck.




  -- Noel Jones

Re: New default settings for submission service?

[Patrick Ben Koetter]

* Noel Jones postfix-users@postfix.org:
 On 3/14/2012 4:50 PM, Patrick Ben Koetter wrote:
  * Wietse Venema postfix-users@postfix.org:
  Patrick Ben Koetter:
  That's not a problem for me. I don't use the submission service
  and rely on input from the real world for this.
 
  Meaning, may, combined with a setting that allows plaintext
  passwords only over encrypted connections.  Not sure if that makes
  trouble shooting easier than when TLS is always required, though.
 
  It does. One can test CRAM-MD5 also in a telnet session. The SASL_README
  refers to a script, gen-auth, that assists creating the necessary 
  response.
 
  What about openssl s_client instead of telnet?
  
  To my knowledge s_client is not a fully featured SMTP client or telnet
  replacement. It is fine to see output about the TLS session, but once I
  proceed I usally get errors.
  
  p@rick
  
 
 
 AFAIK OpenSSL works OK for testing SMTP as long as you avoid
 sending/pressing the upper-case R character, which triggers TLS
 renegotiation (and an SMTP error).  Issuing the SMTP commands in
 lower-case is the usual workaround.
 But if your hashed password contains an R you're out of luck.

Thanks, now I understand Wietse's comment about avoiding 'R'. There's no way I
can control whether a hashed password contains an R or not. Personally, I'd
rather stick with telnet then.

p@rick



-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Michael Orlitzky]

On 03/14/2012 04:03 PM, Patrick Ben Koetter wrote:

* Charles Marcuscmar...@media-brokers.com:

On 2012-03-14 2:39 PM, Ed Wli...@wildgooses.com  wrote:

I see no reason to *require* encryption on the submission port (RFC
aside).


Unless you prefer that sniffers not be able to see your passwords
crossing the wire in plaintext?


I think may is a more appropriate default?


Disagree vehemently.


The RFC on submission is clear about that. It says SHOULD and not MUST. It is
safe to AUTH if you use cram-md5, digest-md5, ntlm or any other non-plaintext
mechanism. Forcing TLS by default is safer, but it pushes a policy on people
the SHOULD decide themselves, I think.


I agree with Charles: the defaults should be as safe as possible, but 
adjustable in the rare case that the administrator has some idea what 
he's doing.

Re: New default settings for submission service?

[Noel Jones]

On 3/14/2012 5:09 PM, Patrick Ben Koetter wrote:
 * Noel Jones postfix-users@postfix.org:
 AFAIK OpenSSL works OK for testing SMTP as long as you avoid
 sending/pressing the upper-case R character, which triggers TLS
 renegotiation (and an SMTP error).  Issuing the SMTP commands in
 lower-case is the usual workaround.
 But if your hashed password contains an R you're out of luck.
 
 Thanks, now I understand Wietse's comment about avoiding 'R'. There's no way I
 can control whether a hashed password contains an R or not. Personally, I'd
 rather stick with telnet then.

Yes, I would always choose telnet first.  Unfortunately, if you want
to test an encrypted session telnet fails miserably.

The [press R to renegotiate] behavior of s_client is documented and,
last time I looked, can't be disabled.

At any rate, s_client is intended for testing.  If your hashed test
password string has an R in it, use a different test password.



  -- Noel Jones

Re: New default settings for submission service?

[Patrick Ben Koetter]

* Wietse Venema postfix-users@postfix.org:
 Patrick Ben Koetter:
  Wietse et al.
  
  With the arrival of postscreen, but also before I find myself repeatedly
  changing the defaults for the 'submission' service in master.cf. I believe 
  the
  changes I apply are not rooted in my local mail policies, but of general
  nature.
  
  Now that submission has become more popular I'd like to discuss if the 
  current
  settings should be modified to work better with an MTA that runs different
  policies for port 25 and 587, which I believe has become the standard use 
  case
  for 'a mailserver'.
 
 Indeed. Of course, not every MTA needs to provide port 587
 submission service. Enabling an unused service by default would be
 undesirable as it may produce unexpected results.

Agreed.


 Different sites have different needs, and perhaps it is an idea to
 provide *multiple* submission service examples in master.cf, all
 commented out of course. The first could be the recommended one:
 not allowing plaintext sessions is good as a general rule. The
 second example could allow plaintext sessions (level = may) but
 allow plaintext passwords only over encrypted sessions.

I'll be on a train for quite some time today. That will give me time to work
out some examples.


 I would not recommend smtpd_delay_reject=no.  With that, the sysadmin
 has no clue about what mail is blocked.  Even postscreen tries to
 capture sender and recipient information.

You would not recommend it in general or not on 587? The latter would be my
recommendation:

- Do not delay on port 25 for MTA to MTA communication
- Delay on port 587 for MUA to MTA communication

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Ralf Hildebrandt]

* Patrick Ben Koetter p...@state-of-mind.de:

 You would not recommend it in general or not on 587? The latter would be my
 recommendation:
 
 - Do not delay on port 25 for MTA to MTA communication
 - Delay on port 587 for MUA to MTA communication

I'd keep smtpd_delay_reject at its default for both 25  587

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: New default settings for submission service?

[Wietse Venema]

Patrick Ben Koetter:
 - Do not delay on port 25 for MTA to MTA communication

With this. the sysadmin has no clue about what mail is blocked.
Even postscreen goes through great efforts to report the
sender and recipient of blocked mail.

Recommending this change would be a major mistake.

Wietse

Re: New default settings for submission service?

[Nerijus Kislauskas]

On 03/13/2012 01:51 AM, Wietse Venema wrote:
 The first could be the recommended one:
 not allowing plaintext sessions is good as a general rule. The
 second example could allow plaintext sessions (level = may) but
 allow plaintext passwords only over encrypted sessions.

While ninjas are being busy with lives, our submission configuration is
as follows:

smtpd_sasl_auth_enable=yes
smtpd_tls_security_level=may
smtpd_tls_auth_only=yes

and mynetworks is of course my client networks. Works good so far (about
a month).
-- 
Sincerely,
Nerijus Kislauskas

Re: New default settings for submission service?

[Patrick Domack]

Quoting Wietse Venema wie...@porcupine.org:


Patrick Ben Koetter:

- Do not delay on port 25 for MTA to MTA communication


With this. the sysadmin has no clue about what mail is blocked.
Even postscreen goes through great efforts to report the
sender and recipient of blocked mail.


Along these lines, would patching the enforce blacklist, so that it  
logs the from/to without doing dnsbl's be useful? I can't think of a  
purpose why, if you have them in the blacklist, you would also want to  
do all those dns rbl lookups also, but I do want to get the from/to so  
I can locate something if a user requests it.


This patch causes postscreen_blacklist_action = enforce to not  
generate dnsbl lookups.


--- src/postscreen/postscreen_dnsbl.c   2012-01-09 19:31:52.0 -0500
+++ src/postscreen/postscreen_dnsbl.c   2012-03-10 08:10:46.261969063 -0500
@@ -491,6 +491,7 @@
  * We therefore do not optimize the maximum out of this temporary
  * implementation.
  */
+if ( (((PSC_STATE *)context)-flags  PSC_STATE_FLAG_BLIST_FAIL) == 0) {
 for (ht = dnsbl_site_list; *ht; ht++) {
if ((fd = LOCAL_CONNECT(psc_dnsbl_service, NON_BLOCKING, 1))  0) {
msg_warn(%s: connect to %s service: %m,
@@ -513,6 +514,7 @@
   (char *) stream, DNSBLOG_TIMEOUT);
score-pending_lookups += 1;
 }
+}
 return (PSC_CALL_BACK_INDEX_OF_LAST(score));
 }

Re: New default settings for submission service?

[Wietse Venema]

Patrick Domack:
 Quoting Wietse Venema wie...@porcupine.org:
 
  Patrick Ben Koetter:
  - Do not delay on port 25 for MTA to MTA communication
 
  With this. the sysadmin has no clue about what mail is blocked.
  Even postscreen goes through great efforts to report the
  sender and recipient of blocked mail.
 
 Along these lines, would patching the enforce blacklist, so that it  
 logs the from/to without doing dnsbl's be useful? I can't think of a  

This replaces one hard-coded behavior (apply all configured tests)
with different hard-coded behavior (skip some arbitrary subset of
configured tests), making postfix more difficult to understand, in
the hope of achieving a minor performance optimization.

The reason to apply all configured tests is to find out how effective
all tests are, even if a bot is blocked by the first one.

Wietse

Re: New default settings for submission service?

[Patrick Ben Koetter]

* Patrick Ben Koetter postfix-users@postfix.org:
 * Wietse Venema postfix-users@postfix.org:
  Different sites have different needs, and perhaps it is an idea to
  provide *multiple* submission service examples in master.cf, all
  commented out of course. The first could be the recommended one:
  not allowing plaintext sessions is good as a general rule. The
  second example could allow plaintext sessions (level = may) but
  allow plaintext passwords only over encrypted sessions.

Here are two examples we all seem to agree on. They differ in TLS
(optional/mandatory) and the SASL mechanisms they allow depending on the TLS
context.

Additionally, both examples have SMTP session filters that check for syntactic
deliverability (MSA job) and add required headers if they are missing.

Filters and fixing headers is a change I'd propose, but nobody seems to have
commented on yet. Agreed by everyone?

As a safety net I would change smtpd_client_restrictions into
smtpd_recipient_restrictions. This will give a client sufficient time to
authenticate and permit_sasl_authenticated will work even if an admin changed
the defaults for smtpd_delay_reject. It also makes it possible to filter for
reject_non_fqdn_recipient, which the RFC I quoted says to be a MSA job.


# submission example 1: Optional TLS with SASL methods safe to use over an
# unencrypted network
#submission inet n   -   -   -   -   smtpd
#  -o smtpd_tls_security_level=may
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_sasl_security_options=noplaintext,noanonymous
#  -o smtpd_tls_sasl_security_options=noanonymous
#  -o always_add_missing_headers=yes
#  -o 
smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING


# submission example 2: Mandatory TLS and SASL only over an encrypted network
#submission inet n   -   -   -   -   smtpd
#  -o smtpd_tls_security_level=enforce
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o always_add_missing_headers=yes
#  -o 
smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Robert Schetterer]

Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:
 * Patrick Ben Koetter postfix-users@postfix.org:
 * Wietse Venema postfix-users@postfix.org:
 Different sites have different needs, and perhaps it is an idea to
 provide *multiple* submission service examples in master.cf, all
 commented out of course. The first could be the recommended one:
 not allowing plaintext sessions is good as a general rule. The
 second example could allow plaintext sessions (level = may) but
 allow plaintext passwords only over encrypted sessions.
 
 Here are two examples we all seem to agree on. They differ in TLS
 (optional/mandatory) and the SASL mechanisms they allow depending on the TLS
 context.
 
 Additionally, both examples have SMTP session filters that check for syntactic
 deliverability (MSA job) and add required headers if they are missing.
 
 Filters and fixing headers is a change I'd propose, but nobody seems to have
 commented on yet. Agreed by everyone?
 
 As a safety net I would change smtpd_client_restrictions into
 smtpd_recipient_restrictions. This will give a client sufficient time to
 authenticate and permit_sasl_authenticated will work even if an admin changed
 the defaults for smtpd_delay_reject. It also makes it possible to filter for
 reject_non_fqdn_recipient, which the RFC I quoted says to be a MSA job.
 
 
 # submission example 1: Optional TLS with SASL methods safe to use over an
 # unencrypted network
 #submission inet n   -   -   -   -   smtpd
 #  -o smtpd_tls_security_level=may
 #  -o smtpd_sasl_auth_enable=yes
 #  -o smtpd_sasl_security_options=noplaintext,noanonymous
 #  -o smtpd_tls_sasl_security_options=noanonymous
 #  -o always_add_missing_headers=yes
 #  -o 
 smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
 #  -o milter_macro_daemon_name=ORIGINATING
 
 
 # submission example 2: Mandatory TLS and SASL only over an encrypted network
 #submission inet n   -   -   -   -   smtpd
 #  -o smtpd_tls_security_level=enforce
 #  -o smtpd_sasl_auth_enable=yes
 #  -o smtpd_tls_auth_only=yes
 #  -o always_add_missing_headers=yes
 #  -o 
 smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
 #  -o milter_macro_daemon_name=ORIGINATING
 

Hi Patrick,

always_add_missing_headers (default: no)

Always add (Resent-) From:, To:, Date: or Message-ID: headers when
not present. Postfix 2.6 and later add these headers only when clients
match the local_header_rewrite_clients parameter setting. Earlier
Postfix versions always add these headers; this may break DKIM
signatures that cover non-existent headers.

are you sure that your example is safe with i.e dkim ?

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: New default settings for submission service?

[Scott Kitterman]

On Tuesday, March 13, 2012 07:46:09 PM Robert Schetterer wrote:
 Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:
  * Patrick Ben Koetter postfix-users@postfix.org:
  * Wietse Venema postfix-users@postfix.org:
  Different sites have different needs, and perhaps it is an idea to
  provide *multiple* submission service examples in master.cf, all
  commented out of course. The first could be the recommended one:
  not allowing plaintext sessions is good as a general rule. The
  second example could allow plaintext sessions (level = may) but
  allow plaintext passwords only over encrypted sessions.
  
  Here are two examples we all seem to agree on. They differ in TLS
  (optional/mandatory) and the SASL mechanisms they allow depending on the
  TLS context.
  
  Additionally, both examples have SMTP session filters that check for
  syntactic deliverability (MSA job) and add required headers if they are
  missing.
  
  Filters and fixing headers is a change I'd propose, but nobody seems to
  have commented on yet. Agreed by everyone?
  
  As a safety net I would change smtpd_client_restrictions into
  smtpd_recipient_restrictions. This will give a client sufficient time to
  authenticate and permit_sasl_authenticated will work even if an admin
  changed the defaults for smtpd_delay_reject. It also makes it possible
  to filter for reject_non_fqdn_recipient, which the RFC I quoted says to
  be a MSA job.
  
  
  # submission example 1: Optional TLS with SASL methods safe to use over
  an # unencrypted network
  #submission inet n   -   -   -   -   smtpd
  #  -o smtpd_tls_security_level=may
  #  -o smtpd_sasl_auth_enable=yes
  #  -o smtpd_sasl_security_options=noplaintext,noanonymous
  #  -o smtpd_tls_sasl_security_options=noanonymous
  #  -o always_add_missing_headers=yes
  #  -o
  smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_rec
  ipient,permit_sasl_authenticated,reject #  -o
  milter_macro_daemon_name=ORIGINATING
  
  
  # submission example 2: Mandatory TLS and SASL only over an encrypted
  network #submission inet n   -   -   -   -   smtpd
  #  -o smtpd_tls_security_level=enforce
  #  -o smtpd_sasl_auth_enable=yes
  #  -o smtpd_tls_auth_only=yes
  #  -o always_add_missing_headers=yes
  #  -o
  smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_rec
  ipient,permit_sasl_authenticated,reject #  -o
  milter_macro_daemon_name=ORIGINATING
 
 Hi Patrick,
 
 always_add_missing_headers (default: no)
 
 Always add (Resent-) From:, To:, Date: or Message-ID: headers when
 not present. Postfix 2.6 and later add these headers only when clients
 match the local_header_rewrite_clients parameter setting. Earlier
 Postfix versions always add these headers; this may break DKIM
 signatures that cover non-existent headers.
 
 are you sure that your example is safe with i.e dkim ?

The MSA should be doing the signing, not the MUA, so it should be.

Scott K

Re: New default settings for submission service?

[mouss]

Le 13/03/2012 00:25, Patrick Ben Koetter a écrit :
 Wietse et al.
 
 With the arrival of postscreen, but also before I find myself repeatedly
 changing the defaults for the 'submission' service in master.cf. I believe the
 changes I apply are not rooted in my local mail policies, but of general
 nature.
 
 Now that submission has become more popular I'd like to discuss if the current
 settings should be modified to work better with an MTA that runs different
 policies for port 25 and 587, which I believe has become the standard use case
 for 'a mailserver'.
 
[sip]
 
 I would add the following filters to reject messages that are not in
 conformance in order to gain basic transportability and better deliverabilty:
 
 reject_non_fqdn_sender
 reject_non_fqdn_recipient
 reject_unknown_sender_domain
 reject_unkown_recipient_domain
 

while I like such checks in order to detect virus/trojan attacks, we're
not there yet. more efforts are needed to educate hosters as well as
application developers



 I'd also add header fields if the authenticated client failed to:
 
 always_add_missing_headers=yes
 
 And finally I'd change the current settings for smtpd_tls_security_level and
 smtpd_delay_reject regarding the submission service:
 
 smtpd_tls_security_level
 I would not enforce TLS as the submission RFC only says SHOULD on TLS and
 therefore would only set 'may' as preconfigured setting. I'd leave it to the
 postmaster to set a stricter policy. I personally keep changing this all the
 time since I configure and test SASL first and once that works as expected
 turn to TLS. Opportunistic TLS as default would make this easier without
 breaking RFCs.
 
 smtpd_delay_reject
 For convenience reasons I'd add this setting and set it to 'yes'. Eversince
 postscreen has been around I've been switching to smtpd_delay_reject=no and
 more aggressive filtering on port 25. I believe many have done so.
 Unfortunately setting it to 'no' breaks the assigned smtpd_client_restrictions
 for the submission service - the client will be rejected before it was able to
 authenticate.
 
 
 All in all I think these changes would make a submission service more useful
 out of the box.
 
 What do you think?
 
 p@rick
 

Re: New default settings for submission service?

[Patrick Ben Koetter]

Hey mouss,

* mouss mouss+nob...@netoyen.net:
 Le 13/03/2012 00:25, Patrick Ben Koetter a écrit :
  Wietse et al.
  
  With the arrival of postscreen, but also before I find myself repeatedly
  changing the defaults for the 'submission' service in master.cf. I believe 
  the
  changes I apply are not rooted in my local mail policies, but of general
  nature.
  
  Now that submission has become more popular I'd like to discuss if the 
  current
  settings should be modified to work better with an MTA that runs different
  policies for port 25 and 587, which I believe has become the standard use 
  case
  for 'a mailserver'.
  
 [sip]
  
  I would add the following filters to reject messages that are not in
  conformance in order to gain basic transportability and better 
  deliverabilty:
  
  reject_non_fqdn_sender
  reject_non_fqdn_recipient
  reject_unknown_sender_domain
  reject_unkown_recipient_domain
  
 
 while I like such checks in order to detect virus/trojan attacks, we're
 not there yet. more efforts are needed to educate hosters as well as
 application developers

my intentions in this effort are not to educate anyone. That's out of my
control. I want to do what I can control and prepare submitted messages for a
safe journey i.e. make sure they meet the technical standards for best
deliverability.

Of course, I'd require application developers to write software that meets the
standard requirements, but that's a different story to me.

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/

Re: New default settings for submission service?

[Wietse Venema]

I'm going to keep it simple: one template for the submission (port 587)
service, and one for smtps (which still seems to be needed in some
places). Three mail submission-like templates becomes unwieldy.

- Both templates override the main.cf settings for smtpd_*_restrictions
to avoid surprises when changes are made to the port 25 configuration.

- There are no extra syntax or domain existence checks. On the
contrary, I would suggest -o smtpd_reject_unlisted_recipient=no
because MUAs do not handle user unknown reject messages well. It
may be better to drop such notifications into the user's mailbox.

- These overrides are parametrized to encourage setting them in
main.cf instead of master.cf. Managing such parameters in main.cf
is a realistic possibility now that postconf actually has a clue
about master.cf settings.

#submission inet n   -   n   -   -   smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

#smtps inet  n   -   n   -   -   smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

The mua_*_restrictions pseudo-parameters may be set in main.cf.
If, for example, mua_client_restrictions were to be set in main.cf,
then it would control both mail submission services. Otherwise,
the mua_*_restrictions pseudo-parameters all have empty values.

Wietse

New default settings for submission service?

[Patrick Ben Koetter]

Wietse et al.

With the arrival of postscreen, but also before I find myself repeatedly
changing the defaults for the 'submission' service in master.cf. I believe the
changes I apply are not rooted in my local mail policies, but of general
nature.

Now that submission has become more popular I'd like to discuss if the current
settings should be modified to work better with an MTA that runs different
policies for port 25 and 587, which I believe has become the standard use case
for 'a mailserver'.

In RFC 5598 Internet Mail Architecture Dave Crocker writes about the
submission service:

4.3.1.  Mail Submission Agent (MSA)

   A Mail Submission Agent (MSA) accepts the message submitted by the
   aMUA and enforces the policies of the hosting ADMD and the
   requirements of Internet standards.  An MSA represents an unusual
   functional dichotomy.  It represents the interests of the Author
   (aMUA) during message posting, to facilitate posting success; it also
   represents the interests of the MHS.
   
   ...

   The hMSA takes transit responsibility for a message that conforms to
   the relevant Internet standards and to local site policies.  It
   rejects messages that are not in conformance.  The MSA performs final
   message preparation for submission and effects the transfer of
   responsibility to the MHS, via the hMSA.  The amount of preparation
   depends upon the local implementations.  Examples of aMSA tasks
   include adding header fields, such as Date: and Message-ID:, and
   modifying portions of the message from local notations to Internet
   standards, such as expanding an address to its formal IMF
   representation.
   -- http://tools.ietf.org/rfc/rfc5598.txt

This said, I think the submission service should be expanded and modified.

I would add the following filters to reject messages that are not in
conformance in order to gain basic transportability and better deliverabilty:

reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unkown_recipient_domain

I'd also add header fields if the authenticated client failed to:

always_add_missing_headers=yes

And finally I'd change the current settings for smtpd_tls_security_level and
smtpd_delay_reject regarding the submission service:

smtpd_tls_security_level
I would not enforce TLS as the submission RFC only says SHOULD on TLS and
therefore would only set 'may' as preconfigured setting. I'd leave it to the
postmaster to set a stricter policy. I personally keep changing this all the
time since I configure and test SASL first and once that works as expected
turn to TLS. Opportunistic TLS as default would make this easier without
breaking RFCs.

smtpd_delay_reject
For convenience reasons I'd add this setting and set it to 'yes'. Eversince
postscreen has been around I've been switching to smtpd_delay_reject=no and
more aggressive filtering on port 25. I believe many have done so.
Unfortunately setting it to 'no' breaks the assigned smtpd_client_restrictions
for the submission service - the client will be rejected before it was able to
authenticate.


All in all I think these changes would make a submission service more useful
out of the box.

What do you think?

p@rick

-- 
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/