adrian ilarion ciobanu:
> >
> > 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 thi
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 unspecifi
>
> 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
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
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
> dom
> 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 o
On Wed, Jan 27, 2010 at 12:54:25PM -0600, adrian ilarion ciobanu wrote:
> > Using login names as next-hop destination? I am not sure I like
> > this user interface.
>
> well the next hop in the case of atrn IS the connection authenticated
> for the user more than anythin else. i believe there's n
> Victor Duchovni:
> > On Tue, Jan 26, 2010 at 08:26:15PM -0500, Wietse Venema wrote:
> >
> > > Then the transport map would look like:
> > >
> > > example.com atrn:[example.com]
> > > example.org atrn:[example.org]
> >
> > ATRN supports multi-domain requests either explicitly or imp
Victor Duchovni:
> On Tue, Jan 26, 2010 at 08:26:15PM -0500, Wietse Venema wrote:
>
> > Then the transport map would look like:
> >
> > example.com atrn:[example.com]
> > example.org atrn:[example.org]
>
> ATRN supports multi-domain requests either explicitly or implicitly,
> in
On Tue, Jan 26, 2010 at 08:26:15PM -0500, Wietse Venema wrote:
> Then the transport map would look like:
>
> example.com atrn:[example.com]
> example.org atrn:[example.org]
ATRN supports multi-domain requests either explicitly or implicitly,
in which case the domain -> nextho
adrian ilarion ciobanu:
> >
> > You associate a fixed nexthop with each authenticated client, and their
> > entire set of domains. You flush either all their domains, or the subset
> > they requested. The scache entry is for the client-specific nexthop, not
> > the recipient domain.
> >
> > e
>
> You associate a fixed nexthop with each authenticated client, and their
> entire set of domains. You flush either all their domains, or the subset
> they requested. The scache entry is for the client-specific nexthop, not
> the recipient domain.
>
> example.com atrn:[client1.atrn.in
On Tue, Jan 26, 2010 at 05:40:40PM -0600, adrian ilarion ciobanu wrote:
> > >
> > > So I would push the socket to scache after I'm done setting it up
> > > from SMTPD (auth, policy checks) and forget about it. If it times
> > > out before local smtp will start deliver then the client is welcome t
> >
> > So I would push the socket to scache after I'm done setting it up
> > from SMTPD (auth, policy checks) and forget about it. If it times
> > out before local smtp will start deliver then the client is welcome to
> > reconnect.
> > This will happen if it has to happen in SMTPD or in SCACHE
adrian ilarion ciobanu:
>
> > In both clases the client connects to the standard SMTP port. The
> > biggest difference is that ETRN creates new SMTP connections for
> > delivery, whereas ATRN delivers over the existing connection.
>
> So I should understand that RFC specifying port 366 as the ODMR
On Tue, Jan 26, 2010 at 04:45:25PM -0600, adrian ilarion ciobanu wrote:
> > Instead of using a DOMAIN_PORT kludge which requires "reserving"
> > a TCP port or UNIX-domain pathname per customer, it would make
> > sense to use the existing Postfix connection caching mechanism.
> >
> > The idea is
> Instead of using a DOMAIN_PORT kludge which requires "reserving"
> a TCP port or UNIX-domain pathname per customer, it would make
> sense to use the existing Postfix connection caching mechanism.
>
> The idea is to push an open socket into the scache daemon (with a
> suitable time to live) und
> In both clases the client connects to the standard SMTP port. The
> biggest difference is that ETRN creates new SMTP connections for
> delivery, whereas ATRN delivers over the existing connection.
So I should understand that RFC specifying port 366 as the ODMR port is just
a "should" and not a
Added a comment about how to avioid the transport:DOMAIN_PORT kludge.
Wietse Venema:
> adrian ilarion ciobanu:
> > No matter how hard I try not to, I keep seeing similarities between
> > ETRN and ATRN.
>
> In both clases the client connects to the standard SMTP port. The
> biggest difference is
adrian ilarion ciobanu:
> No matter how hard I try not to, I keep seeing similarities between
> ETRN and ATRN.
In both clases the client connects to the standard SMTP port. The
biggest difference is that ETRN creates new SMTP connections for
delivery, whereas ATRN delivers over the existing conne
I got this task of implementing ODMR in postfix. Although I tried playing the
"why-not-instead" game,
1. no one wants to hear about uucp probably because they thought we will also
switch the fiber links to 9600baud modems.
2. ETRN was a good choice until ISP decided that ETRN is not a good choic
21 matches
Mail list logo
