adrian ilarion ciobanu:
> I'd say the sasl authorization map IS the transport map. The sasl
> authorization (not the authentication that is ofcourse outside
> atrnd) can be resolved when atrnd
> does the lookup domain<->user
> transport looks like:
>
> domainA atrn:user1
> domainB atrn:user1
> domainX atrn:userN
>
> my 2 cents is the administrator only needs to properly define
> the atrn transports and no other maps. the one to one map adds
> headache on the customer side which i find it to be undesirable.
> one would need to do extra handshakes with the customers to cheat
> the specification. i smell problems with windows exchange and some
> sysadmin bloodshed.
>
> smtpd does normal sasl auth and forwad atrn chats to atrnd which
> will handle atrnd parameters , doing lookups in transport file to
> map the sasl user (or not). where's the extra sasl authorization
> map?
Basically there are two more-or-less sane variants. Both use a full
smtpd(8) with SASL and STARTTLS, and a dedicated atrnd(8) server
that enforces policy and that primes the scache(8) cache with a
channel that can be used repeatedly by smtp(8) delivery agents,
one at a time.
- ATRN domains are in the relay address class. This involves:
- A table with ATRN domains that is queried by the relay_domains
parameter.
- A table that is queried by relay_recipient_maps for recipient
address validation.
- A transport map that overrides the delivery of an ATRN domain
to atrn:username (where atrn is just a standard Postfix smtp
client with some extra options in master.cf). The username
plays a dual role:
- It prevents other users from stealing this domain's mail.
This is enforced by atrnd(8), based on the information
received from smtpd(8).
- It is a search key to store and retrieve a session in the
scache(8) cache.
Gotchas:
- Requires manual configuration to include the ATRN domain table
into relay_domains AND transport_maps (we can't simply use
"relay_domains = $transport_maps" or vice-versa as a built-in
default).
- The transport map username is used as if it were a destination.
This introduces non-obvious restrictions on the username
syntax. For example, the SMTP client will attempt to parse
the destination as [domain]:service, [domain], domain:service,
domain, etc., and will fail if the :service part is invalid
(for example, it will fail when the client authenticates with
a TLS certificate whose name or fingerprint contains a ":"
character).
There is likely to be more code now, or in the future, that
trips up when an SMTP destination is not a valid domain or IP
address. Adding switches that disable the sanity checks it bad.
- ATRN domains are a separate address class that delivers via
$atrn_transport (default: atrn). This involves:
- A table that is queried by atrn_domains for the domains that
are member of the atrn address class.
- The right-hand side of that same table contains a username
that owns the domain, so that other users can't steal this
domain's mail. This is enforced by atrnd(8). There are no
additional restrictions on the user's name syntax. It could
be a TLS certificate name without problems.
- Here, we can use "atrn_domains = $atrn_domain_owners" or vice
versa as a built-in default to reduce manual configuration.
- A table that is queried by atrn_recipient_maps for recipient
address validation.
- This uses the real destination domain name as search key for
scache(8) cache storage and lookups, so there will never be
surprises with unexpected syntax violations.
- No transport mapping.
Gotchas:
- One ATRN session can deliver only one domain (delivering
multiple domains would require a transport map which would
complicate email theft prevention).
Before writing code (and drafting an updated design document) I
would like to discuss these questions first:
1) What is the need for ATRN in the first place? What are the
options (VPN, ETRN + dynamic DNS, ...). I find almost no information
about supported ATRN solutions with other major MTAs (not counting
qmail patches here), so it is not obvious that there is a problem
worth solving.
2) Assuming that ATRN is worth implementing, what is the need for
multiple ATRN domains per account? Somehow, people can't afford a
static IP address, yet they have an infrastructure that is so
complex that it has to be spread across multiple domain names that
must be visible from the Internet.
I have been in this business long enough that I am reluctant to
maintain code that solves a problem without some idea that it
will actually be used.
Wietse
