the purpose of smtpd_sasl_authenticated_header

[Udo Rader]

Hi,

as we are currently testing 2.3 I would like to know the rationale
behind smtpd_sasl_authenticated_header.

On one hand I find the flag useful for tracing purposes, but on the
other hand I already see hordes of script kiddies/spammers harvesting
the login names for brute force attacks.

So what's the idea behind it?

Udo Rader

[Ralf Hildebrandt]

Post by Udo Rader
Hi,
as we are currently testing 2.3 I would like to know the rationale
behind smtpd_sasl_authenticated_header.
On one hand I find the flag useful for tracing purposes, but on the
other hand I already see hordes of script kiddies/spammers harvesting
the login names for brute force attacks.
So what's the idea behind it?

# postconf -d smtpd_sasl_authenticated_header
smtpd_sasl_authenticated_header = no

The idea is to activate it if YOU think it's useful.

[Udo Rader]

Post by Ralf Hildebrandt

Post by Udo Rader
Hi,
as we are currently testing 2.3 I would like to know the rationale
behind smtpd_sasl_authenticated_header.
On one hand I find the flag useful for tracing purposes, but on the
other hand I already see hordes of script kiddies/spammers harvesting
the login names for brute force attacks.
So what's the idea behind it?

# postconf -d smtpd_sasl_authenticated_header
smtpd_sasl_authenticated_header = no
The idea is to activate it if YOU think it's useful.

yes, that is quite obvious, I am in control of any parameter, but I
would like to know what's the idea behind it.

If I was to setup a completely new, state of the art etc. server, (why)
would I enable it?

Udo Rader

[l***@kwsoft.de]

Post by Udo Rader

Post by Ralf Hildebrandt

Post by Udo Rader
Hi,
as we are currently testing 2.3 I would like to know the rationale
behind smtpd_sasl_authenticated_header.
On one hand I find the flag useful for tracing purposes, but on the
other hand I already see hordes of script kiddies/spammers harvesting
the login names for brute force attacks.
So what's the idea behind it?

# postconf -d smtpd_sasl_authenticated_header
smtpd_sasl_authenticated_header = no
The idea is to activate it if YOU think it's useful.

yes, that is quite obvious, I am in control of any parameter, but I
would like to know what's the idea behind it.
If I was to setup a completely new, state of the art etc. server, (why)
would I enable it?

As far as i remember there was some demand for this to distinguish
authenticated mail from other at a later stage (content filter ..).
Some sites may use it to assign every sent e-mail to a user without
scanning zhe logs.
But as said, if you have no idea what to do with leave it at default.

Regards

Andreas

[mouss]

Post by Udo Rader
Hi,
as we are currently testing 2.3 I would like to know the rationale
behind smtpd_sasl_authenticated_header.
On one hand I find the flag useful for tracing purposes, but on the
other hand I already see hordes of script kiddies/spammers harvesting
the login names for brute force attacks.
So what's the idea behind it?

some cases where this is ok:

- if login = email address (many virtual users setups), then there is no
problem including the login.

- if you have different instances/servers handling inbound and outbound
mail, you can enable the header for inbound mail only.

- if you use a content filter, you can enable it, use it in the content
filter (SA can use it), and then remove it either in a custom filter or
using REPLACE after the filter.

This header allows you to use a single filter (with a single port) but
still distinguish between auth'ed users and others. This may be handy if
you need this deeper in a daisy chain or at delivery time (as designing
completely separate paths may not be desirable).

[Udo Rader]

Post by mouss

Post by Udo Rader
Hi,
as we are currently testing 2.3 I would like to know the rationale
behind smtpd_sasl_authenticated_header.
On one hand I find the flag useful for tracing purposes, but on the
other hand I already see hordes of script kiddies/spammers harvesting
the login names for brute force attacks.
So what's the idea behind it?

- if login = email address (many virtual users setups), then there is no
problem including the login.
- if you have different instances/servers handling inbound and outbound
mail, you can enable the header for inbound mail only.
- if you use a content filter, you can enable it, use it in the content
filter (SA can use it), and then remove it either in a custom filter or
using REPLACE after the filter.
This header allows you to use a single filter (with a single port) but
still distinguish between auth'ed users and others. This may be handy if
you need this deeper in a daisy chain or at delivery time (as designing
completely separate paths may not be desirable).

thanks for explaining, Mouss, now this seams perfectly reasonable to
me.

Udo Rader

[Eddy Beliveau]

Post by mouss
- if login = email address (many virtual users setups), then there is no
problem including the login.
- if you have different instances/servers handling inbound and outbound
mail, you can enable the header for inbound mail only.
- if you use a content filter, you can enable it, use it in the content
filter (SA can use it), and then remove it either in a custom filter or
using REPLACE after the filter.
This header allows you to use a single filter (with a single port) but
still distinguish between auth'ed users and others. This may be handy if
you need this deeper in a daisy chain or at delivery time (as designing
completely separate paths may not be desirable).

Hi!

In our case, login = Student-Id which I won't put on any Received headers

Is there any solution to have smtpd_sasl_authenticated_header to display another variable on the
Received header

I would like it to use 'mail' instead of 'login'

Thanks,
Eddy

[mouss]

Post by Eddy Beliveau

Post by mouss
- if login = email address (many virtual users setups), then there is no
problem including the login.
- if you have different instances/servers handling inbound and outbound
mail, you can enable the header for inbound mail only.
- if you use a content filter, you can enable it, use it in the content
filter (SA can use it), and then remove it either in a custom filter or
using REPLACE after the filter.
This header allows you to use a single filter (with a single port) but
still distinguish between auth'ed users and others. This may be handy if
you need this deeper in a daisy chain or at delivery time (as designing
completely separate paths may not be desirable).

Hi!
In our case, login = Student-Id which I won't put on any Received headers
Is there any solution to have smtpd_sasl_authenticated_header to
display another variable on the Received header

You are not giving any information about your setup. please reread my
post and say if your setup matches one of those.

Post by Eddy Beliveau
I would like it to use 'mail' instead of 'login'

'mail' is already in the envelope (Return-Path when mail is delivered).
why would you want it in the Received headers?

[Eddy Beliveau]

Post by mouss

In our case, login = Student-Id which I won't put on any Received headers
Is there any solution to have smtpd_sasl_authenticated_header to
display another variable on the Received header

You are not giving any information about your setup. please reread my
post and say if your setup matches one of those.

Hi! Mouss,

Thanks for your reply.

I'm using postfix 2.2.10 and it work great :-)

I would like to have some header which tell if the SMTP sender has been authenticated or not
and, if so, what was the login username that has been used for authentication.

I didn't find a way of doing it in 2.2.10

I noticed in 2.3 that there is a main.cf parameter smtpd_sasl_authenticated_header
which should add the login username to the Received header

My problem is that my login username is the studentid or employeeid value
and I don't want that value to appear on any headers.

You said:
"- if login = email address (many virtual users setups), then there is no
problem including the login.
- if you use a content filter, you can enable it, use it in the content
filter (SA can use it), and then remove it either in a custom filter or
using REPLACE after the filter."

This is exactly what I was going to do:
-enable smtpd_sasl_authenticated_header
-use it with my content filter
-and remove the header when I need it no more.

But, I won't need to remove it if the displayed value was something
like the email address instead of the original login username

This is why I ask if there is some way to display another content in that field.

Post by mouss

I would like it to use 'mail' instead of 'login'

'mail' is already in the envelope (Return-Path when mail is delivered).
why would you want it in the Received headers?

Because, I also need to know if the message has been "authenticated"

Thanks,
Eddy

[mouss]

Post by Eddy Beliveau
I would like to have some header which tell if the SMTP sender has
been authenticated or not
and, if so, what was the login username that has been used for
authentication.
I didn't find a way of doing it in 2.2.10
I noticed in 2.3 that there is a main.cf parameter
smtpd_sasl_authenticated_header
which should add the login username to the Received header
My problem is that my login username is the studentid or employeeid value
and I don't want that value to appear on any headers.

so once you "consume" it, replace it.

Post by Eddy Beliveau
You said: "- if login = email address (many virtual users setups),
then there is no problem including the login.
- if you use a content filter, you can enable it, use it in the
content filter (SA can use it), and then remove it either in a custom
filter or using REPLACE after the filter."
This is exactly what I was going to do: -enable
smtpd_sasl_authenticated_header
-use it with my content filter
-and remove the header when I need it no more.
But, I won't need to remove it if the displayed value was something
like the email address instead of the original login username

what to do and how you do it depend on your exact setup. if you don't
like providing too much infos publicly, contact me offlist (and I'll
"translate" to the list)

Post by Eddy Beliveau
This is why I ask if there is some way to display another content in that field.

see above. it really depends on your setup. one hint here is to add a
REPLACE in after the filter header_checks that woul remove the login.
but again, this depends on your setup.

[b***@gmail.com]

I'm seriously considering enabling this so that we can catch real accounts that fake dummy email addresses to send spam.