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 "Noel J. Bergman" <no...@devtech.com> on 2002/08/18 00:46:55 UTC
Re: address-literal addressing not working
Danny,
> I can't see why this needs to be "fixed" it may be that you don't actually
> want to handle mail delivered using IP addresses ...
Section 4.1.3 of RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt): "Sometimes
a host is not known to the domain name system and communication (and, in
particular, communication to report and repair the error) is blocked. To
bypass this barrier a special literal form of the address is allowed as an
alternative to a domain name." I read that as saying that the special
literal form IS allowed, not that it MAY BE allowed. For example, if I
normally count on domain names and your DNS server goes out, I can use the
address-literal form to reach you. I do understand your differing
understanding, and see a bit of US-centric political humor in that we are
saying that it "depends upon what the definition of 'is' is."
As for maintaining it by hand, not only don't I read it as optional, but for
those of us dealing with virtual hosting, there can be quite a few IP
addresses as well as domain names. I'd like the DNS to deal with that, not
have to do it by hand. For example, within the next week or so, we're
moving to a new ARIN block. When there is a DNS change, I'd like to make
change in the DNS, not have to keep disjoint applications in synch.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Saturday, August 17, 2002 18:12
To: James Developers List
Subject: RE: DO NOT REPLY [Bug 11795] New: - address-literal addressing
not working
Oh, now I see what this is about,
Yes you have to specify that James will handle mail for the address literals
as well as domain names, then it works.
I can't see why this needs to be "fixed" it may be that you don't actually
want to handle mail delivered using IP addresses, only FQDN's, for any
number of reasons.
Specifying ip address literals to be handled in the servernames section
seems reasonable to me.
My fix would be to simply document this requirement, and point out the
reasoning.
What do you think?
d.
> -----Original Message-----
> From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> Sent: 17 August 2002 21:41
> To: james-dev@jakarta.apache.org
> Subject: DO NOT REPLY [Bug 11795] New: - address-literal addressing not
> working
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11795>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11795
>
> address-literal addressing not working
>
> Summary: address-literal addressing not working
> Product: James
> Version: unspecified
> Platform: Other
> OS/Version: Other
> Status: NEW
> Severity: Normal
> Priority: Other
> Component: James Core
> AssignedTo: james-dev@jakarta.apache.org
> ReportedBy: noel@devtech.com
>
>
> 2.1a1 doesn't appear to support <us...@address-literal> addressing
> as required
> by the SMTP RFC. James.isServerLocal() does a simple String lookup in a
> serverName collection, so unless the IP addresses are in the
> collection, they
> won't be matched.
>
> There are some reports that this is a regression, since it worked
> with 2.0a3.
> That should be tested. There was also an Open Relay defect in 2.0a3 that
> might have masked this problem, depending upon the test. A patch
> for this
> defect has been submitted.
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by "Noel J. Bergman" <no...@devtech.com>.
I'm submitting a patch for it, with embedded comments about future
directions for change. Support for address literals is controlled by a new
"addIPAddresses" attribute on the <servernames> element, so that anyone who
doesn't want to use it can just turn it off.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Sunday, August 18, 2002 14:31
To: James Developers List
Subject: RE: address-literal addressing not working
Medium :)
Because to do it right you'd need to make sure you could match all the IP
addresses a machine is accepting, and in both forms (with and without [])
I don't think it is such simple matter to correctly identify all the
addresses, whereas it is common practice to configure server daemons with
lists of addresses to accept (see httpd for example).
d.
> I'm leaning towards Noel's reading of this. How strong are your
> objections? I don't want to commit anything before we have a consensus.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by "Noel J. Bergman" <no...@devtech.com>.
> trying to produce predictable and easily controllable behaviour
> keep configuration simple and flexible.
Yes, yes, and yes. :-)
> If you don't care about IPaddresses James will work fine when you ignore
> that section
If you really DON'T care, James will work fine if you ignore that attribute.
If you DO care, then you can turn off auto-discovery, and add (or not) the
IP addresses manually. I do believe that satisfying the RFC should be the
default polarity, but I had added the configurability that you requested.
I think we agree. I just don't think that it requires a separate element to
do this.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by Danny Angus <da...@apache.org>.
> I consider a separate serveraddresses section to be unnecessary. It is
> perfectly permissible today to add elements of the form:
>
> <servername>xxx.xxx.xxx.xxx</servername>
>
> to the <servernames> element today. If truely desired, we could accept:
>
> <servername>[xxx.xxx.xxx.xxx]</servername>
>
> and strip the brackets. The brackets must be stripped because the
> comparison is made against MailAddress.getHost(), and getHost()
> must return
> a valid host (which is why getHost() strips the brackets when it provides
> the host).
The point is that we should be trying to produce predictable and easily
controllable behaviour, keep configuration simple and flexible.
If you don't care about IPaddresses James will work fine when you ignore
that section, if you do care you can reuse your knowledge of how to
configure other aspects of James and plainly see exactly what you should
modify.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > How about we make it an optional behavior with a config param?
> Ok, a fine compromise, if we add (and document) a section
<serveraddresses>
> equivalent to <servernames> with an autodetect element/parameter, as for
> servernames that should allow simple situations to be detected, complex
> situations to override it, and the chosen behaviour to be clearly seen in
> the configuration.
> I think it should be composed of <address>xxx.xxx.xxx.xxx</address>
elements
> which are added in [] to the servernames collection. Yes?
I did attempt to implement this compromise position. The patch I submitted
does add such an autodetect parameter. It tells James to autodetect IP
addresses for the mail hosts it supports. The parameter is addIPAddresses,
although it can be renamed to whatever anyone wants.
I consider a separate serveraddresses section to be unnecessary. It is
perfectly permissible today to add elements of the form:
<servername>xxx.xxx.xxx.xxx</servername>
to the <servernames> element today. If truely desired, we could accept:
<servername>[xxx.xxx.xxx.xxx]</servername>
and strip the brackets. The brackets must be stripped because the
comparison is made against MailAddress.getHost(), and getHost() must return
a valid host (which is why getHost() strips the brackets when it provides
the host).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by Danny Angus <da...@apache.org>.
> I concur with you about the difficulty of matching all the IP addresses.
> That should be much easier once we migrate to Java 1.4 (using the
> NetworkAddress class), but for now it's definitely a problem for complex
> IP setups. However for simple IP setups I think this change would make
> life substantially easier.
I can see that, but following the principle of least surprises leads me to
propose documenting this as a "feature" , rather than doing half a job.
> I'm not sure why we'd have to support both forms. From my reading of
> the RFC, only the bracketed form is strictly correct for IP addresses.
Correct.
> How about we make it an optional behavior with a config param?
Ok, a fine compromise, if we add (and document) a section <serveraddresses>
equivalent to <servernames> with an autodetect element/parameter, as for
servernames that should allow simple situations to be detected, complex
situations to override it, and the chosen behaviour to be clearly seen in
the configuration.
I think it should be composed of <address>xxx.xxx.xxx.xxx</address> elements
which are added in [] to the servernames collection. Yes?
d.
>
> --Peter
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> Medium :)
>
> Because to do it right you'd need to make sure you could match all the
IP
> addresses a machine is accepting, and in both forms (with and without
[])
> I don't think it is such simple matter to correctly identify all the
> addresses, whereas it is common practice to configure server daemons
with
> lists of addresses to accept (see httpd for example).
I concur with you about the difficulty of matching all the IP addresses.
That should be much easier once we migrate to Java 1.4 (using the
NetworkAddress class), but for now it's definitely a problem for complex
IP setups. However for simple IP setups I think this change would make
life substantially easier.
I'm not sure why we'd have to support both forms. From my reading of
the RFC, only the bracketed form is strictly correct for IP addresses.
How about we make it an optional behavior with a config param?
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by Danny Angus <da...@apache.org>.
Medium :)
Because to do it right you'd need to make sure you could match all the IP
addresses a machine is accepting, and in both forms (with and without [])
I don't think it is such simple matter to correctly identify all the
addresses, whereas it is common practice to configure server daemons with
lists of addresses to accept (see httpd for example).
d.
> I'm leaning towards Noel's reading of this. How strong are your
> objections? I don't want to commit anything before we have a consensus.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: address-literal addressing not working
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny et al,
I'm leaning towards Noel's reading of this. How strong are your
objections? I don't want to commit anything before we have a consensus.
--Peter
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Saturday, August 17, 2002 3:47 PM
> To: James Developers List
> Subject: Re: address-literal addressing not working
>
> Danny,
>
> > I can't see why this needs to be "fixed" it may be that you don't
> actually
> > want to handle mail delivered using IP addresses ...
>
> Section 4.1.3 of RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt):
> "Sometimes
> a host is not known to the domain name system and communication (and,
in
> particular, communication to report and repair the error) is blocked.
To
> bypass this barrier a special literal form of the address is allowed
as an
> alternative to a domain name." I read that as saying that the special
> literal form IS allowed, not that it MAY BE allowed. For example, if
I
> normally count on domain names and your DNS server goes out, I can use
the
> address-literal form to reach you. I do understand your differing
> understanding, and see a bit of US-centric political humor in that we
are
> saying that it "depends upon what the definition of 'is' is."
>
> As for maintaining it by hand, not only don't I read it as optional,
but
> for
> those of us dealing with virtual hosting, there can be quite a few IP
> addresses as well as domain names. I'd like the DNS to deal with
that,
> not
> have to do it by hand. For example, within the next week or so, we're
> moving to a new ARIN block. When there is a DNS change, I'd like to
make
> change in the DNS, not have to keep disjoint applications in synch.
>
> --- Noel
>
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: Saturday, August 17, 2002 18:12
> To: James Developers List
> Subject: RE: DO NOT REPLY [Bug 11795] New: - address-literal
addressing
> not working
>
>
> Oh, now I see what this is about,
> Yes you have to specify that James will handle mail for the address
> literals
> as well as domain names, then it works.
> I can't see why this needs to be "fixed" it may be that you don't
actually
> want to handle mail delivered using IP addresses, only FQDN's, for any
> number of reasons.
> Specifying ip address literals to be handled in the servernames
section
> seems reasonable to me.
> My fix would be to simply document this requirement, and point out the
> reasoning.
> What do you think?
> d.
>
> > -----Original Message-----
> > From: bugzilla@apache.org [mailto:bugzilla@apache.org]
> > Sent: 17 August 2002 21:41
> > To: james-dev@jakarta.apache.org
> > Subject: DO NOT REPLY [Bug 11795] New: - address-literal addressing
not
> > working
> >
> >
> > DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> > RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11795>.
> > ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> > INSERTED IN THE BUG DATABASE.
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11795
> >
> > address-literal addressing not working
> >
> > Summary: address-literal addressing not working
> > Product: James
> > Version: unspecified
> > Platform: Other
> > OS/Version: Other
> > Status: NEW
> > Severity: Normal
> > Priority: Other
> > Component: James Core
> > AssignedTo: james-dev@jakarta.apache.org
> > ReportedBy: noel@devtech.com
> >
> >
> > 2.1a1 doesn't appear to support <us...@address-literal> addressing
> > as required
> > by the SMTP RFC. James.isServerLocal() does a simple String lookup
in a
> > serverName collection, so unless the IP addresses are in the
> > collection, they
> > won't be matched.
> >
> > There are some reports that this is a regression, since it worked
> > with 2.0a3.
> > That should be tested. There was also an Open Relay defect in 2.0a3
> that
> > might have masked this problem, depending upon the test. A patch
> > for this
> > defect has been submitted.
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>