virtual domain alias & check_recipient_access
Hello, I need to redirect all the email coming to one domain to another
like this:
@alias-domain.com -> @real-domain.com
which means when a mail is coming to my.n...@alias-domain.com, it's first
translated to my.n...@real-domain.com and later delivered to the mailbox.
I have found this in the virtual(5) doc:
-
@domain address, address, ...
...
Note: @domain is a wild-card. With this form, the Postfix SMTP
server accepts mail for any recipient in domain, regardless of
whether that recipient exists. This may turn your mail system
into a backscatter source: Postfix first accepts mail for
non-existent recipients and then tries to return that mail as
"undeliverable" to the often forged sender address.
To avoid backscatter with mail for a wild-card domain, replace
the wild-card mapping with explicit 1:1 mappings, or add a
reject_unverified_recipient restriction for that domain:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access
inline:{example.com=reject_unverified_recipient}
unverified_recipient_reject_code = 550
In the above example, Postfix may contact a remote server if the
recipient is aliased to a remote address.
-
I'd like to go the way with the "check_recipient_access" option, but don't
know how to do it with databased map:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access pgsql:map_file ?
unverified_recipient_reject_code = 550
What is the correct settings instead of those "?" please? Any hint?
Thanks, Tomas
Re: virtual domain alias & check_recipient_access
Tomas Macek:
>smtpd_recipient_restrictions =
>...
>reject_unauth_destination
>check_recipient_access
>inline:{example.com=reject_unverified_recipient}
>unverified_recipient_reject_code = 550
>
>In the above example, Postfix may contact a remote server if
> the
>recipient is aliased to a remote address.
> -
>
> I'd like to go the way with the "check_recipient_access" option, but don't
> know how to do it with databased map:
>
> smtpd_recipient_restrictions =
> ...
> reject_unauth_destination
> check_recipient_access pgsql:map_file ?
> unverified_recipient_reject_code = 550
>
> What is the correct settings instead of those "?" please? Any hint?
Use inline for reject_unverified_recipient, and use pgsql:map_file
for other things.
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access inline:{example.com=reject_unverified_recipient}
check_recipient_access pgsql:map_file
unverified_recipient_reject_code = 550
Wietse
Re: virtual domain alias & check_recipient_access
On Fri, 21 Dec 2018, Wietse Venema wrote:
Tomas Macek:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access
inline:{example.com=reject_unverified_recipient}
unverified_recipient_reject_code = 550
In the above example, Postfix may contact a remote server if the
recipient is aliased to a remote address.
-
I'd like to go the way with the "check_recipient_access" option, but don't
know how to do it with databased map:
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access pgsql:map_file ?
unverified_recipient_reject_code = 550
What is the correct settings instead of those "?" please? Any hint?
Use inline for reject_unverified_recipient, and use pgsql:map_file
for other things.
smtpd_recipient_restrictions =
...
reject_unauth_destination
check_recipient_access inline:{example.com=reject_unverified_recipient}
check_recipient_access pgsql:map_file
unverified_recipient_reject_code = 550
I filled in my alias domain name instead of the "example.com", but the
system still accepts mail to "nonexist...@alias-domain.com". The
example.com in the example above should be the destination or the alias
domain? Or is that a misunderstanding of the system from me?
Tomas
Re: Outbound opportunistic TLS by default?
On 19 Dec 2018, at 14:36, Viktor Dukhovni wrote: If there are no objections, I can change the default to "may" when TLS is compiled in. But how else will Postfix troubleshooters make themselves look like geniuses with 10 seconds of "work?" (Not An Actual Objection... I wholeheartedly applaud this change) -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole
Re: virtual domain alias & check_recipient_access
Tomas Macek:
> On Fri, 21 Dec 2018, Wietse Venema wrote:
>
> > Tomas Macek:
> >>smtpd_recipient_restrictions =
> >>...
> >>reject_unauth_destination
> >>check_recipient_access
> >>inline:{example.com=reject_unverified_recipient}
> >>unverified_recipient_reject_code = 550
> >>
> >>In the above example, Postfix may contact a remote server
> >> if the
> >>recipient is aliased to a remote address.
> >> -
> >>
> >> I'd like to go the way with the "check_recipient_access" option, but don't
> >> know how to do it with databased map:
> >>
> >> smtpd_recipient_restrictions =
> >>...
> >>reject_unauth_destination
> >>check_recipient_access pgsql:map_file ?
> >>unverified_recipient_reject_code = 550
> >>
> >> What is the correct settings instead of those "?" please? Any hint?
> >
> > Use inline for reject_unverified_recipient, and use pgsql:map_file
> > for other things.
> >
> > smtpd_recipient_restrictions =
> >...
> >reject_unauth_destination
> >check_recipient_access inline:{example.com=reject_unverified_recipient}
> >check_recipient_access pgsql:map_file
> > unverified_recipient_reject_code = 550
>
> I filled in my alias domain name instead of the "example.com", but the
> system still accepts mail to "nonexist...@alias-domain.com". The
> example.com in the example above should be the destination or the alias
> domain? Or is that a misunderstanding of the system from me?
In the table, specify the DOMAIN NAME FROM THE SMTP COMMAND.
It's called SMTPD_RECIPIENT_restrictions for a reason.
Wietse
Re: detect fake mx, tls security encrypt
nights later, a better approach seems to have a policy service that does the tls pre-checking. Something like this already around? ( i'm no coder but want to sponsor that if someone can do it) pm please Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni < postfix-us...@dukhovni.org>: >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer wrote: >> >> I'm aware of such exceptions but I don't like to set them. Our policy is safe or not at all via mail. > > That policy has a cost. You don't like the cost, but there it is... > >> I would like to have a setting like do not try next mx, >> if first mx lacks tls support. it assumes that if tls is >> not avail on primary it will for sure also not be avail >> on second and third. > > Sorry, Postfix does not and will not do that. Data-mine your logs > for deliveries that fall back to a dead MX host (connection failure > and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d" > part of the log entry, e.g. > > delays=263861/0.01/60/0, dsn=4.4.1, status=deferred > (connect to : Operation timed out) > > Then, if you refuse to ever deliver in the clear, reject mail to > the domain. > > transport: > example.com error:5.1.2:Destination domain does not support STARTTLS > > -- > -- > Viktor. >
