james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <danny.an...@gmail.com>
Subject Re: Change in policy to for JAMES to violate RFCs
Date Wed, 04 Oct 2006 16:17:02 GMT
As far as I understand it (and I wrote the compiance statement on
http://james.apache.org/server/design_objectives.html) the position
need not change.

It is acceptable for us to build non-compliant behaviour into James to
support interoperability with "broken" implementations. However it
should always be disabled by default so that operators make a
conscious decision to enable non-compliant behaviour.

The argument against non-compliance is that as increasingly more
non-compliant behaviours become accepted they enforce an undocumented
"dark" standard which implementors will struggle to understand and
implement. directly countering the purpose of published
interoperability standards.


d.


On 03/10/06, Bernd Fondermann <bernd.fondermann@googlemail.com> wrote:
> +1, I fully agree to Stefanos view.
>
> all non-strict, relaxed behavior should be commented out per default
> and the related comment should include a strong warning.
>
>   Bernd
>
> On 9/30/06, Stefano Bagnara <apache@bago.org> wrote:
> > Noel J. Bergman wrote:
> > > JAMES has always enforced RFC compliance.  In the case of JAMES-642 (a request
to drop the RFC 2821 requirement that MAIL and RCPT addresses have brackets), when this has
come up on rare occasions, we have repeatedly and deliberately rejected such requests.  Now
Norman, Stefano and Joachim are in favor of permitting the behavior.
> >
> > I don't agree that JAMES-642 is a request to drop RFC2821 requirement
> > that MAIL and RCPT address have brackets: IMO is clear that this is a
> > requirement for clients, not for servers!
> >
> > Clients issue that commands, not servers.
> >
> > > I am against supporting specification violations, even as an option, except
*maybe* in the case that there is such a widespread issue that everyone's transport capabilities
are compromised.  Postal's Law doesn't mean to ignore mandated behavior.  RFC 2821 is quite
clear that the brackets must always be present for MAIL and RCPT.  Are we as a community changing
to say that specification compliance is no longer important?
> >
> > My interpretation of Postal's Law applied to this issue is quite different:
> > An SMTP client MUST use the brackets.
> > An SMTP server COULD accept also addresses without brackets.
> >
> > It is not so clear that accepting a MAIL FROM or an RCPT TO without
> > brackets is a violation to the RFC. It is for sure a violation to send
> > that commands.
> >
> > I would agree with your position if we were talking about sending the
> > branckets in the MAIL FROM our remote delivery issue when sending an
> > email: this would be a "specification violations".
> >
> > The same thing would be if the specification said "the server MUST NOT
> > accept MAIL FROM: " with not compliant attributes: this thing has not
> > been written in the specification, so we are compliant anyway.
> >
> > As another example, the RFC say:
> > | Several commands (RSET, DATA, QUIT) are specified as not permitting
> > | parameters.  In the absence of specific extensions offered by the
> > | server and accepted by the client, clients MUST NOT send such
> > | parameters and servers SHOULD reject commands containing them as
> > | having invalid syntax.
> >
> > As you can see they enforce the client to operate in a specific way, but
> > say the the server "SHOULD" reject badly composed commands instead of
> > using a "MUST reject".
> >
> > So I think that I never changed my mind on specification compliance: we
> > seem to have a different Idea on what does it mean to be specification
> > compliant.
> >
> > Imho the key is interoperability: adding the feature does not make James
> > non-compliant and give it more interoperability, so I put a +1.
> >
> > > As for a possible solution, the "fast fail" chain is really about in-protocol
plug-ins, not just fast fail.  If someone wants to write a command handler to repair defective
addresses for MAIL and RCPT, that's their option.  JAMES is open source.  If someone wants
to violate the specification, they can manage their own changes.
> > >
> > >       --- Noel
> >
> >
> > Well saying that the user can write code to alter the behaviour is not a
> > solution: we are an opensource project, using this reasoning we could
> > close every JIRA issue saying that the user can fix it. The can also
> > write their own smtp server...
> >
> > Stefano
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

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


Mime
View raw message