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 2004/06/05 05:21:28 UTC
Putting version 2.2.0 release to bed
Guys,
Can we please clear up:
Steve Short: http://nagoya.apache.org/jira/browse/JAMES-247
Chris Means: http://nagoya.apache.org/jira/browse/JAMES-294
Steve Brewin: http://nagoya.apache.org/jira/browse/JAMES-276
Danny Angus: http://nagoya.apache.org/jira/browse/JAMES-275
I believe they are all ready to be closed, as are JAMES-159 and probably
some others, but I'd like confirmation so that we can call for a vote to
release.
Also, if folks would take a few minutes daily for the next week or so, and
please close up issues that are resolved but not closed, that'd be great.
It is just a tedious job, so if we could spread the pain, that'd be good.
:-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Source Routing
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The backend system (apparently it must have a few years on it's back)
> uses addresses like: @YYY.XXX.DK:zzz@XXX.dk
> Now James hickups at this issuing:
> ERROR smtpserver: Error parsing sender address:
> @YYY.XXX.DK:zzz@XXX.dk: No local-part (user account) found at position 1
> So to be compliant James actually MUST accept this syntax ;-(
Please see RFC 2821 #3.3, #3.7, and most importantly, #4.1.1.3, which makes
it quite clear that we are entitled to reject with a 550 the RCPT TO command
that provided a source route. If you want to support it by stripping the
source route information, that's fine, but I'm just as comfortable issuing
the 550.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Source Routing
Posted by Soren Hilmer <so...@tietoenator.com>.
Hi,
Okay we just ran into the following at a site, where James is setup as a
mailprocessing gateway.
The backend system (apparently it must have a few years on it's back) uses
addresses like:
@YYY.XXX.DK:zzz@XXX.dk
ie. the old RFC-821 source route style.
Now James hickups at this issuing:
ERROR smtpserver: Error parsing sender address: @YYY.XXX.DK:zzz@XXX.dk: No
local-part (user account) found at position 1
Which is logical as MailAddress is not designed to handle source routes.
But according to RFC-2821 appendix F.2:
"SMTP servers MUST continue to accept source route syntax as specified
in the main body of this document and in RFC 1123. They MAY, if
necessary, ignore the routes and utilize only the target domain in
the address. If they do utilize the source route, the message MUST
be sent to the first domain shown in the address. In particular, a
server MUST NOT guess at shortcuts within the source route."
So to be compliant James actually MUST accept this syntax ;-(
I propose a fix, where we use the MAY above, that is ignore the routes and
utilize only the target domain in the address.
If you all agree with me that this is something we should (no must) handle,
and in the proposed manner.
I will start working on this fix.
--Søren
--
Søren Hilmer, M.Sc.
R&D manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax: +45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 64 57
DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Putting version 2.2.0 release to bed
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We also have a bunch of documentation that would be nice to update.
> FAQs, instructions, etc... Are we still using the xdocs stuff, and
> how exactly do these get generated for the release as I thought they
> got deleted on the 2.x branch.
The docs are still in the v2 branch, since the build process was never
changed to get them from elsewhere. They are packaged with the bundles, but
not used on the web site. The web site is all generated from the MAIN
branch.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Putting version 2.2.0 release to bed
Posted by Serge Knystautas <se...@prestosports.com>.
Noel J. Bergman wrote:
> I believe they are all ready to be closed, as are JAMES-159 and probably
> some others, but I'd like confirmation so that we can call for a vote to
> release.
>
> Also, if folks would take a few minutes daily for the next week or so, and
> please close up issues that are resolved but not closed, that'd be great.
> It is just a tedious job, so if we could spread the pain, that'd be good.
> :-)
We also have a bunch of documentation that would be nice to update.
FAQs, instructions, etc... Are we still using the xdocs stuff, and how
exactly do these get generated for the release as I thought they got
deleted on the 2.x branch.
--
Serge Knystautas
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: Putting version 2.2.0 release to bed
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Regarding JAMES-159, I wasn't able to reproduce it using openssl as reported by the issuer. After the successful handshake, I never got any answer for the "helo" sequence.
As I'm successfully using SMTPS in my production server since more than one year with 2.2.0ann, and never had any problem with it, I would resolve the problem as "cannot reproduce", and reopen it only if the issuer gives us some more info.
Vincenzo
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: sabato 5 giugno 2004 5.21
> To: James-Dev Mailing List
> Cc: sshort@postx.com; cmeans@intfar.com; sbrewin@apache.org;
> danny@apache.org
> Subject: Putting version 2.2.0 release to bed
>
>
> Guys,
>
> Can we please clear up:
>
> Steve Short: http://nagoya.apache.org/jira/browse/JAMES-247
> Chris Means: http://nagoya.apache.org/jira/browse/JAMES-294
> Steve Brewin: http://nagoya.apache.org/jira/browse/JAMES-276
> Danny Angus: http://nagoya.apache.org/jira/browse/JAMES-275
>
> I believe they are all ready to be closed, as are JAMES-159 and probably
> some others, but I'd like confirmation so that we can call for a vote to
> release.
>
> Also, if folks would take a few minutes daily for the next week or so, and
> please close up issues that are resolved but not closed, that'd be great.
> It is just a tedious job, so if we could spread the pain, that'd be good.
> :-)
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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