Danny Angus wrote: > > > Hi, > > Since this issue has come up (again) this time wrt issue JAMES-344 I > thought I'd post my understanding of the consensus we have reached for > dealing with non-compliant behaviour. > I've also commented the issue. > Please note that this is my personal opinion but I believe > that it reflects > the decisions made in every case we've discussed to date, and > therefore > represents policy.
<snipped> Policy or not I agree. I would also add that wherever possible optional adaptations to accomodate non-compliant messages should be performed by a Mailet. This way we are leveraging our existing architecture and ensuring that the same adaptations are applied in the same way to mail injected from whatever source. Due to the timeline on which fetchmail was developed, it sports a number of filters which are better applied after the mail had been injected into the spool by Mailets. Back then, MailAttributes were not available, so this approach was not possible. Now they are. Using the Mailet chain to optionally match on a MailAttribute indicating that a condition has been detected and run a Mailet to handle it is a much better approach. Fetchmail now adds the required MailAttributes. The same approach applies to any spool injector. This is why in JAMES-344 I argued that fetchmail, which detects the non-compliant behaviour and sets a MailAttribute accordingly, should not be adapted to handle non-compliance. Far better to by default reject it, as it does, and optionally inject it. Then someone can write a Mailet to fixup the condition if they have that burning need. This way we do not polute our core code with workarounds for non-compliance, while enabling non-compliant messages to be processed and optionally fixed up by Mailets, if that is what a user desires. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
