Prev: Preventing outgoing local mail being delivered to certain domains
Next: multiple IPs in and out
From: adrian ilarion ciobanu on 27 Jan 2010 15:33
> Does any Edge MTA other than Microsoft Exchange support the client-side
> of ATRN?
No idea. I'd say ATRN is a dead subject besides being used by some exchange
users and being offered by some ISPs (europe mostly, not sure why).

>
> Are there enough ATRN-dependent Exchange shops with part-time or dynamic
> Internet connections to justify this architecture?
Can't say. If forced, i will say no, there aren't enough.
>
> Does Postfix also need an ATRN client?

Postfix is the main choice for some important linux distros. Can't say i've heard
users asking for atrn on their forums (thinking ubuntu at least).

>
> Is supporting ATRN worth the effort? It is an interesting problem to
> solve, a cute intellectual puzzle, but perhaps our energies are best
> directed elsewhere?
Perhaps. In fact the main idea was to implement it as a totally decoupled
postfix service while reusing postfix code as much as possible. That would
also allow one to test user response by packaging it as a postfix extension
in some linux distros. If positive, then one can safely decide its ok to merge
to main tree.
The only way one can doit is to dup the postfix source, code atrn service, do
some proper maintenance against postfix source updates, test user response, if ok -
only then think about patching smtpd.

Now that you put the problem this way, if I would be a postfix developer i would
vote against atrn support :)

But i learned ways of doing things in postfix. Much appreciated.

>
> > ofcourse, there are many ways to implement fixes external to postfix
> > but other things gets complicated (maintaining tunnels, cursing dynamic
> > dns providers, etc). I dont know if i would vote for atrn inclusion in
> > the main tree.
>
> Well, this would not be a simple outside the main tree add-on:
>
> - New address class required.
>
> - Some tweaks to the connection cache service.
>
> - Some tweaks to the SMTP delivery agent (when running in the
> "atrn" personality, defer when no cached connection is available,
> never try to connect to the nexthop directly).
>
> - Tweaks to the SMTP server to support a proxy mode after the ATRN
> command is accepted.
>
> One could clone and customize smtpd, but then the body of code that is
> common with smtpd would be maintained twice, this worked poorly with
> smpt(8) and lmtp(8), and things are better now that the two are one.
>
> So I think that either this is mainstream Postfix, or you are completely
> on your own with private patches that are unlikely to be suitable for
> use anywhere else.
>
> --
> Viktor.
>
> P.S. Morgan Stanley is looking for a New York City based, Senior Unix
> system/email administrator to architect and sustain our perimeter email
> environment. If you are interested, please drop me a note.

--
adrian ilarion ciobanu
adrian.i(a)ciobanu.name
http://pub.mud.ro/~cia
+40 788 319 497

From: Wietse Venema on 27 Jan 2010 15:40
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

From: Victor Duchovni on 28 Jan 2010 00:08
On Wed, Jan 27, 2010 at 03:40:43PM -0500, Wietse Venema wrote:

> 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.

Should ODMR support be in the primary MTA queue? Or should mail
for ODMR destinations be batched up onto disk out of the MTA's
queue, and served by dedicated servers as in:

http://www.plonk.de/sw/odmr/

It is far from clear that one wants to gum-up the active and deferred
queues of a real MTA with ODMR mail. If we can deliver envelope + message
to suitable stable storage, and use a standalone ODMR server to make
said storage available to ODMR clients, that is likely a better solution
and is much less intrusive.

You just a need a delivery agent that records the envelope in detail and
delivers to a maildir or similar associated with the owner of the domain.
Then a non-Postfix server that supports retrieval. No pointless retries
or gumming up the deferred/active queue unless the user connects, though
your probably need a daily scan to bounce over-age messages.

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

From: adrian ilarion ciobanu on 28 Jan 2010 04:48
>
> Should ODMR support be in the primary MTA queue? Or should mail
> for ODMR destinations be batched up onto disk out of the MTA's
> queue, and served by dedicated servers as in:
>
> http://www.plonk.de/sw/odmr/
odmr is mail relaying. if one chooses this solution then one probably
wants to do the same thing for any type of relaying.
>
> It is far from clear that one wants to gum-up the active and deferred
> queues of a real MTA with ODMR mail. If we can deliver envelope + message
> to suitable stable storage, and use a standalone ODMR server to make
> said storage available to ODMR clients, that is likely a better solution
> and is much less intrusive.
>
> You just a need a delivery agent that records the envelope in detail and
> delivers to a maildir or similar associated with the owner of the domain.
> Then a non-Postfix server that supports retrieval. No pointless retries
> or gumming up the deferred/active queue unless the user connects, though
> your probably need a daily scan to bounce over-age messages.


What you describe sounds like day-by-day mail relaying, practically for me
there's no "ODMR mail", just mail waiting to be relayed. Maybe I'm wrong and ODMR must be
seen as delivery or something else since it must be hooked up everywhere in the process, it seems. The only difference
is how the relaying process is finalized. Normal smtp, etrn or atrn. So i think
that no matter what the transport is, the queueing rules should be
the same for every email that needs to be relayed.
The "pointless retries or gumming up the deferred/active queue" may also refer
to mail waiting to be relayed in a normal fashion (e.g. smtp/lmtp transport) but with destination being down.
I mean, we will succeed to gumup the queue no matter what transport.

Thats one point I can't agree with for having the atrn totally decoupled from postfix queue and related configurations.
And there are at least 2 kilotons of logic
in postfix that can and should be reused . So i wont duplicate authentication, queueing and other pieces of code.

When i was thinking "exporting more functionality via a library" - `that can be made in a very spartan way, e.g.

smtpd.c:
EXT_SMTPD_LIB int etrn_cmd(...)

user_compiletime_config.h:
#define EXPORT_SMTPD_LIB 1

build_exports.h
#ifndef EXPORT_SMTPD_LIB
#define EXT_SMTPD_LIB static
#endif

and have in fact no library/extraheaders built, the developer can use directly the .o via externs, its not very hard to build your own
stuff in a postfix source tree instead of using a well defined exported api.


no bells and whistles. by default no exports, if enduser knows what he wants he defines his exports (SMTPD_LIB,SMTPD_SASL_LIB) at compiletime.
i can't tell what security considerations must be applied when doing this but I understand it's complicated, it may break things and in the
end its work with possible no payback in time.

i'm not thinking only atrnd, but other services that can successfully reuse pieces of code. as a normal postfix user i vote for this
and against patching smtpd, assuming more extensions needing to be added in the future.


>
> --
> Viktor.
>
> P.S. Morgan Stanley is looking for a New York City based, Senior Unix
> system/email administrator to architect and sustain our perimeter email
> environment. If you are interested, please drop me a note.

--
adrian ilarion ciobanu
adrian.i(a)ciobanu.name
http://pub.mud.ro/~cia
+40 788 319 497

From: Victor Duchovni on 28 Jan 2010 11:28
On Thu, Jan 28, 2010 at 03:48:26AM -0600, adrian ilarion ciobanu wrote:

> > queue, and served by dedicated servers as in:
> >
> > http://www.plonk.de/sw/odmr/
>
> odmr is mail relaying. if one chooses this solution then one probably

No, because with ODMR one cannot relay until some unspecified future
time when the destination system chooses to poll you. With normal
relaying, one expects and largely gets real-time forwarding, and thus
low congestion.

> What you describe sounds like day-by-day mail relaying, practically for me
> there's no "ODMR mail", just mail waiting to be relayed. Maybe I'm wrong and ODMR must be
> seen as delivery or something else since it must be hooked up everywhere in the process, it seems. The only difference
> is how the relaying process is finalized. Normal smtp, etrn or atrn. So i think

The Postfix deferred and active queues have practical size limits. High
volumes of ODMR mail can push you into poor performance regimes, because
the active and deferred queues are gummed up with mail to unreachable
destinations.

Delivering ODMR mail to an envelope preserving store, separtes the ODMR
and non-ODMR recipients of a message, with the ODMR mail not needlessly
cycling in and out of the deferred and active queues.

> Thats one point I can't agree with for having the atrn totally decoupled
> from postfix queue and related configurations.

I think you are mistaken. The benefit of getting such mail out of
the queue, and the advantages of being able to process the backlog
synchronously outside normal queue-manager scheduling, outweigh the
disadvantage of a dedicated ODMR service IMHO.

--
Viktor.

P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Preventing outgoing local mail being delivered to certain domains
Next: multiple IPs in and out