You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Jason Webb <jw...@inovem.com> on 2003/11/21 18:16:53 UTC

SMTP routes

I need to develop a system to force mail delivery of certain domains to
go to certain hosts.
This is due to a client having issues with their infrastructure rather
than a problem with James...
And yes, I know fixing their name servers would solve the problem, but
sometimes life is not that easy.

RemoteDelivery would be enhanced to support the following extra config
directives (for example):
<smtproute>
<domain>narf.com</domain>
<host>10.0.0.1</host>
</smtproute>

SMTP routes would take priority over all other forms of mail host
resolution including gateways.

If this is generally useful I will roll it into James proper.

Any opinons?

-- Jason



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: SMTP routes

Posted by Serge Knystautas <se...@lokitech.com>.
Jason Webb wrote:
> I need to develop a system to force mail delivery of certain domains to
> go to certain hosts.
> This is due to a client having issues with their infrastructure rather
> than a problem with James...
> And yes, I know fixing their name servers would solve the problem, but
> sometimes life is not that easy.

All we do is add an extra configuration or two with a matcher on the 
special domains and a RemoteDelivery mailet setup to gateway to that 
host.  Works fine as is.  Do you need a large set of mappings?

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: SMTP routes

Posted by Serge Knystautas <se...@lokitech.com>.
Jason Webb wrote:
> Hmm.
> I suppose this was what I was getting at.
> But....
> Qmail and Sendmail both have facilities to setup SMTP routes to deliver
> to alternate ports and this can't be done using DNS trickery.
> However, I think a few matcher/mailet tricks will do what I want, so
> I'll leave it for now.

Ah, yeah I liked Noel's idea because it seemed to make sense and I 
wasn't aware of why no other servers do this.  Now I remember. :)

Well, since we need to map domains to 1-n IP addresses AND ports, seems 
like your mod would be useful.

Does anyone know of a DNS extension/record type that would specify what 
port to connect to for SMTP?  Maybe record types MXP, e.g., mail 
transfer PORT.  Kinda surprised there isn't something like this already. 
  I guess it would increase complexity a bunch.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


RE: SMTP routes

Posted by Jason Webb <jw...@inovem.com>.
Hmm.
I suppose this was what I was getting at.
But....
Qmail and Sendmail both have facilities to setup SMTP routes to deliver
to alternate ports and this can't be done using DNS trickery.
However, I think a few matcher/mailet tricks will do what I want, so
I'll leave it for now.

-- Jason

> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com] 
> Sent: 21 November 2003 20:43
> To: James Developers List
> Subject: Re: SMTP routes
> 
> 
> Noel J. Bergman wrote:
> >>I rather dislike this overloading approach to mailet 
> configuration.  I 
> >>think you'll soon end up with another Redirect mailet that few 
> >>understand and is trying to be another Swiss army knife.
> > 
> > Well, I hope not, but on the other hand, we did clean up 
> the Redirect 
> > area, and it does provide neccessary capabilities.
> > 
> > Another alternative would be enhancing the DNSServer code 
> so that it 
> > could be given locally authoritative mappings.  That is 
> closer to the 
> > semantic we want, since we ask the DNS server to map a domain to an 
> > SMTP server.
> 
> Oooh, I do like that better since it does seem like the right 
> semantic. 
>   Good idea.
> 
> -- 
> Serge Knystautas
> President
> Lokitech >> software . strategy . design >> 
> http://www.lokitech.com p. 301.656.5501 e. 
> sergek@lokitech.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: SMTP routes

Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
>>I rather dislike this overloading approach to mailet configuration.  I
>>think you'll soon end up with another Redirect mailet that few
>>understand and is trying to be another Swiss army knife.
> 
> Well, I hope not, but on the other hand, we did clean up the Redirect area,
> and it does provide neccessary capabilities.
> 
> Another alternative would be enhancing the DNSServer code so that it could
> be given locally authoritative mappings.  That is closer to the semantic we
> want, since we ask the DNS server to map a domain to an SMTP server.

Oooh, I do like that better since it does seem like the right semantic. 
  Good idea.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


RE: SMTP routes

Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge Knystautas wrote:
> Noel J. Bergman wrote:
> > Instead, I propose that we add an attribute that RemoteDelivery will
check,
> > for the purpose of adding dynamic gateway support.  If the attribute is
> > present, RemoteDelivery treats it as the gateway for that Mail,
otherwise
> > RemoteDelivery operates as normal.  A single mailet could check for
> > mappings, and add the attribute as necessary.  This would be a very
simple
> > change to RemoteDelivery, allows a data driven solution, and is far
cleaner,
> > at least in my mind.

> I rather dislike this overloading approach to mailet configuration.  I
> think you'll soon end up with another Redirect mailet that few
> understand and is trying to be another Swiss army knife.

Well, I hope not, but on the other hand, we did clean up the Redirect area,
and it does provide neccessary capabilities.

Another alternative would be enhancing the DNSServer code so that it could
be given locally authoritative mappings.  That is closer to the semantic we
want, since we ask the DNS server to map a domain to an SMTP server.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Re: SMTP routes

Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> Instead, I propose that we add an attribute that RemoteDelivery will check,
> for the purpose of adding dynamic gateway support.  If the attribute is
> present, RemoteDelivery treats it as the gateway for that Mail, otherwise
> RemoteDelivery operates as normal.  A single mailet could check for
> mappings, and add the attribute as necessary.  This would be a very simple
> change to RemoteDelivery, allows a data driven solution, and is far cleaner,
> at least in my mind.

I rather dislike this overloading approach to mailet configuration.  I 
think you'll soon end up with another Redirect mailet that few 
understand and is trying to be another Swiss army knife.

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


RE: SMTP routes

Posted by "Noel J. Bergman" <no...@devtech.com>.
Jason Webb wrote:

> I need to develop a system to force mail delivery of certain domains
> to go to certain hosts.

> RemoteDelivery would be enhanced to support the following extra config
> directives (for example):

> SMTP routes would take priority over all other forms of mail host
> resolution including gateways.

> If this is generally useful I will roll it into James proper.

-1 on the ground that it seems to a be hardcoded hack with limited benefit.
I do offer an alternative solution, below.  As Serge noted:

> All we do is add an extra configuration or two with a matcher on the
> special domains and a RemoteDelivery mailet setup to gateway to that
> host.  Works fine as is.  Do you need a large set of mappings?

So, yes, you could do it with matcher and mailet pairs.  It is not
data-driven (the configuration is hardcoded), but neither was your solution.
And it also has the overhead of another matcher and mailet for each mapping.

Instead, I propose that we add an attribute that RemoteDelivery will check,
for the purpose of adding dynamic gateway support.  If the attribute is
present, RemoteDelivery treats it as the gateway for that Mail, otherwise
RemoteDelivery operates as normal.  A single mailet could check for
mappings, and add the attribute as necessary.  This would be a very simple
change to RemoteDelivery, allows a data driven solution, and is far cleaner,
at least in my mind.

Thoughts?

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org