+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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
