Prev: Question re: postscreen and -o options
Next: smtpd_helo_required compliance with the RFC
From: Christoph Anton Mitterer on 23 Dec 2009 09:54
Hi.

As far as I understood the documentation, if those two are at their default:
local_header_rewrite_clients = permit_inet_interfaces
remote_header_rewrite_domain =
local clients are subject to address rewriting, but remote ones are not.

Unfortunately it seems that my postfix (2.6.5 from Debian/sid) also
rewrites remote clients.
This is the smtp session:
mail from:<root>
250 2.1.0 Ok
rcpt to:<root>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
test
..
250 2.0.0 Ok: queued as 2434F18B50A

And the log says:
Dec 23 15:00:51 hilbert postfix/smtpd[24688]: connect from
host149.natpool.mwn.de[138.246.7.149]
Dec 23 15:01:04 hilbert postfix/smtpd[24688]: 2434F18B50A:
client=host149.natpool.mwn.de[138.246.7.149]
Dec 23 15:01:06 hilbert postfix/cleanup[24693]: 2434F18B50A:
message-id=<20091223140104.2434F18B50A(a)a.mail.srv.scientia.net>
Dec 23 15:01:06 hilbert postfix/qmgr[24686]: 2434F18B50A:
from=<root(a)hilbert.scientia.net>, size=379, nrcpt=1 (queue active)
Dec 23 15:01:06 hilbert postfix/local[24694]: 2434F18B50A:
to=<root(a)hilbert.scientia.net>, orig_to=<root>, relay=local,
delay=8.2, delays=8.2/0.02/0/0, dsn=2.0.0, status=sent (delivered to
mailbox)
Dec 23 15:01:06 hilbert postfix/qmgr[24686]: 2434F18B50A: removed

So it seems that both, from and to were rewritten and the mail was
delivered which IMHO is quite security critical.

I would have expected that postfix lets both addresses as "root" and
says at some point something like "error, undeliverable email, not
fully quallified".

When I set:
remote_header_rewrite_domain = domain.invalid
nothing else happens. The addreses are still rewritten.

Am I doing something wrong?! ;)


Another question:
append_dot_myorigin has to be always yes if I understand the docs correctly.
I do not want to perform append_dot_mydestination style rewrites,
rather such messages should generally fail (regardless whether they
were submitted locally or not).
But if I set:
append_dot_mydestination = no
then (as far as I understood the documentation), a domain.invalid
would _NOT_ be appended to remote mails if the addres was just
something like "root(a)foo" because the append_dot_mydestination = no
disabled this generally.
Is this true? If so, how can I get what I want?


Thanks,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: Christoph Anton Mitterer on 23 Dec 2009 18:53
Hi list.

Sorry for asking questions again ;)


Quoting Wietse Venema <wietse(a)porcupine.org>:
>> As far as I understood the documentation, if those two are at their default:
>> local_header_rewrite_clients = permit_inet_interfaces
>> remote_header_rewrite_domain =
>> local clients are subject to address rewriting, but remote ones are not.
>
> Please pay attention. The feature is called HEADER rewriting
> not ADDRESS rewriting.

Ok.. I tried many differend combinations of
append_at_myorigin = yes
append_dot_mydomain = yes/no
with
local_header_rewrite_clients = permit_inet_interfaces
and either
remote_header_rewrite_domain =
or
remote_header_rewrite_domain = domain.invalid
fro both local clients and remote.

I think I found out the following, so can some expert confirm this:
- Header sender and recipient addresses are always rewritten for local
clients (depending on local_header_rewrite_clients) and for remote
clients only if remote_header_rewrite_domain is not empty.
In addition append_at_myorigin and append_dot_mydomain are used for
both to decide what to rewrite.


- Envelope sender and recipient addresses are ALWAYS (regardless of
local or remote clients) rewritten depending on append_at_myorigin and
append_dot_mydomain control.
=> For local clients this makes of course sense.
=> For remote clients I'd see some sense to rewrite the envelope
recipient address.
But why is the envelope sender address rewritten with remote clients??
When I did a "MAIL FROM:<root>" my logs showed that this was expanded
to root@$myorigin ?
What's the sense behind this?
And are there controls for the envelope address rewriting with respect
to at_myorigin and dot_mydomain that I haven't found yet? Or would I
break things by touching this?


Thanks,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: Wietse Venema on 23 Dec 2009 19:46
Christoph Anton Mitterer:
> - Header sender and recipient addresses are always rewritten for local
> clients (depending on local_header_rewrite_clients) and for remote
> clients only if remote_header_rewrite_domain is not empty.

Indeed. The feature is called HEADER rewriting. This is called
truth in advertising.

This only trips up people who can't read what the text says, and
instead read what they want to read.

> - Envelope sender and recipient addresses are ALWAYS (regardless of

Indeed. Does the documentation ever claim otherwise?

In case you wonder why bare name is handled as name@$myorigin,
this is because doing otherwise would open a giant hole in the
Postfix defenses (people would have to specify more access rules).

Wietse

From: Christoph Anton Mitterer on 23 Dec 2009 20:30
Hi.

btw: Thanks for your efforts in answering my questions, and sorry for
posting to -devel before (did not notice in the beginning, that this
is not meant for bug/feature reports).

Quoting Wietse Venema <wietse(a)porcupine.org>:
>> clients (depending on local_header_rewrite_clients) and for remote
>> clients only if remote_header_rewrite_domain is not empty.
> This only trips up people who can't read what the text says, and
> instead read what they want to read.
Well,... I just got confused as I saw the envelope addresses to be
rewritten in my logs,.. sorry.


>> - Envelope sender and recipient addresses are ALWAYS (regardless of
> Indeed. Does the documentation ever claim otherwise?
No not really.
http://www.postfix.org/ADDRESS_REWRITING_README.html#standard ,
http://www.postfix.org/postconf.5.html#append_dot_mydomain ,
http://www.postfix.org/postconf.5.html#append_at_myorigin and
say addresses which refers as I know understand to both (envelope and
header). But they're also refer to the remote_header_rewrite_domain and
> local_header_rewrite_clients and the later rewrite chapters directly
> named envelope and header addresses...
So again,.. this confused me probably a little bit. My fault, sorry!


> In case you wonder why bare name is handled as name@$myorigin,
> this is because doing otherwise would open a giant hole in the
> Postfix defenses (people would have to specify more access rules).
Not sure if understand what you mean.

Anyway,.. it seems that it's possible for a remote client to send mail
that looks as if it would come from the host postfix is running on,
right?!
Either as just "root" or "root(a)host" (without the domain) if
append_dot_mydomain = no and remote_header_rewrite_domain is empty.
But even if not empty a remote client could still simply use
root(a)host.domain.tld as sender.

Of course I understand that mail does not guarantee sender
authenticity but this is still a security problem, isn't it?
I mean it's easily possible to reject reject_non_fqdn_sender and I
think even envelope sender addresses that match any of the canonical
domains,.. but this doesn't help with the headers.
Is there an easy way for this problem? Or do I misunderstand something.


Cheers,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: Noel Jones on 23 Dec 2009 21:56
On 12/23/2009 7:30 PM, Christoph Anton Mitterer wrote:
> Hi.
>
> btw: Thanks for your efforts in answering my questions, and sorry for
> posting to -devel before (did not notice in the beginning, that this is
> not meant for bug/feature reports).
>
> Quoting Wietse Venema <wietse(a)porcupine.org>:
>>> clients (depending on local_header_rewrite_clients) and for remote
>>> clients only if remote_header_rewrite_domain is not empty.
>> This only trips up people who can't read what the text says, and
>> instead read what they want to read.
> Well,... I just got confused as I saw the envelope addresses to be
> rewritten in my logs,.. sorry.
>
>
>>> - Envelope sender and recipient addresses are ALWAYS (regardless of
>> Indeed. Does the documentation ever claim otherwise?
> No not really.
> http://www.postfix.org/ADDRESS_REWRITING_README.html#standard ,
> http://www.postfix.org/postconf.5.html#append_dot_mydomain ,
> http://www.postfix.org/postconf.5.html#append_at_myorigin and
> say addresses which refers as I know understand to both (envelope and
> header). But they're also refer to the remote_header_rewrite_domain and
>> local_header_rewrite_clients and the later rewrite chapters directly
>> named envelope and header addresses...
> So again,.. this confused me probably a little bit. My fault, sorry!
>
>
>> In case you wonder why bare name is handled as name@$myorigin,
>> this is because doing otherwise would open a giant hole in the
>> Postfix defenses (people would have to specify more access rules).
> Not sure if understand what you mean.
>
> Anyway,.. it seems that it's possible for a remote client to send mail
> that looks as if it would come from the host postfix is running on, right?!
> Either as just "root" or "root(a)host" (without the domain) if
> append_dot_mydomain = no and remote_header_rewrite_domain is empty. But
> even if not empty a remote client could still simply use
> root(a)host.domain.tld as sender.
>
> Of course I understand that mail does not guarantee sender authenticity
> but this is still a security problem, isn't it?
> I mean it's easily possible to reject reject_non_fqdn_sender and I think
> even envelope sender addresses that match any of the canonical
> domains,.. but this doesn't help with the headers.
> Is there an easy way for this problem? Or do I misunderstand something.
>

To insure that local users aren't confused by a HEADER that
looks as if it came from the local domain, I use
remote_header_rewrite_domain = domain.invalid

-- Noel Jones

 |  Next  |  Last
Pages: 1 2
Prev: Question re: postscreen and -o options
Next: smtpd_helo_required compliance with the RFC