james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: James, standards and non-standard behaviour
Date Fri, 07 Jan 2005 20:56:43 GMT
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.


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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message