Robert Burrell Donkin ha scritto:
i agree in principle but trunk has a lot of JAMES-specific mailets
(but i suspect that many of these could be decoupled)
I would say "some" instead of "many" ;-)
the problem is that many common problems solved by mailets require
access to basic services which are environment specific (for example,
delivery to a logical mailbox or access to user information). ATM
mailets are coupled to basic service APIs defined by JAMES. IMHO it
would be better if mailets were decoupled by exposing their own API
interfaces rather than using JAMES service APIs.
During 2004-2005 (before I joined this project) some of the repository
api landed the mailet api for what was called mailet api v3. Both
usersrepository and mailrepository were exposed in that version.
I don't know exactly what happened because when I joined the project it
was no more there. I think the main cause was that adding repositories
to the mailet apis would have made more complicate to create mailet
containers. And probably repositories api was not mature enough, also.
> i think that it would be a good plan to pull out those mailets which
> are conceptually independent into separate a subproject (standard
> mailets, say)
I did some homework...
here is a list of matcher/mailets that (I think) do not depends on james
or avalon:
matchers/FetchedFrom
matchers/RecipientIsRegex
matchers/RecipientIs
matchers/CommandListservMatcher
matchers/SMTPAuthSuccessful
matchers/SenderIsRegex
matchers/AbstractQuotaMatcher
matchers/SMTPIsAuthNetwork
matchers/HasAttachment
matchers/SenderIs
matchers/CommandForListserv
matchers/HasMailAttributeWithValueRegex
matchers/RecipientIsLocal
matchers/CompareNumericHeaderValue
matchers/SubjectStartsWith
matchers/AttachmentFileNameIs
matchers/All
matchers/FileRegexMatcher
matchers/SizeGreaterThan
matchers/GenericRegexMatcher
matchers/SenderIsNull
matchers/UserIs
matchers/HostIs
matchers/HasMailAttribute
matchers/HostIsLocal
matchers/SMTPAuthUserIs
matchers/SubjectIs
matchers/RelayLimit
matchers/HasHeader
matchers/IsSingleRecipient
matchers/HasHabeasWarrantMark
matchers/SenderHostIsLocal
matchers/HasMailAttributeWithValue
matchers/SenderHostIs
matchers/NESSpamCheck
matchers/smime/IsX509CertificateSubject
matchers/smime/IsSMIMESigned
matchers/smime/IsSMIMEEncrypted
mailets/MailAttributesToMimeHeaders
mailets/RemoveMimeHeader
mailets/debug/Counter
mailets/debug/ExceptionThrowingMailet
mailets/debug/DumpSystemErr
mailets/debug/Identity
mailets/OnlyText
mailets/GenericListservManager
mailets/AddFooter
mailets/RemoveAllMailAttributes
mailets/UseHeaderRecipients
mailets/SetMimeHeader
mailets/ServerTime
mailets/Null
mailets/ToProcessor
mailets/RemoveMailAttribute
mailets/PostmasterAlias
mailets/SetMailAttribute
mailets/AbstractAddFooter
mailets/AddSubjectPrefix
mailets/AddHabeasWarrantMark
-----
Then we have some mailets with dependencies on utility classes that
could be separated from James:
mailets/ReplaceContent
- import org.apache.james.util.mailet.StringUtils;
mailets/ReplaceContent
- depends on org.apache.james.util.mailet.MailetUtil
mailets/UnwrapText
mailets/WrapText
- depend on org.apache.james.util.mailet.FlowedMessageUtils
mailets/smime/SMIMECheckSignature
mailets/smime/Sign
mailets/smime/AbstractSign
mailets/smime/SMIMESign
mailets/smime/SMIMEDecrypt
- smime stuff. depends on org.apache.james.security
mailets/ClamAVScan
- import org.apache.james.util.io.IOUtil;
mailets/SpamAssassin
- import org.apache.james.util.SpamAssassinInvoker;
mailets/LogMessage
- import org.apache.james.core.MailImpl but I think this might be a
mistake and we could replace MailImpl with Mail.
------------
Then we have the jspf mailet that simply depends on the jspf library:
mailets/SPF
---------
And we have an important set of mailets that currently depends on some
James core classes (Constants, core.MailImpl, core.MimeMessageUtil) and
it would be important to make them agnostic from JAMES:
mailets/AbstractRedirect
mailets/NotifyPostmaster
mailets/Forward
mailets/Bounce
mailets/Resend
mailets/NotifySender
mailets/AbstractNotify
mailets/Redirect
mailets/DSNBounce (also depends on util.mail.dsn.DSNStatus and
util.mail.MimeMultipartReport)
The dependency on MimeMessageUtil is in AbastractRedirect (every other
mailet extends this one) and is only because of
MimeMessageUtil.writeMessageBodyTo that is James agnostic and could be
moved to an util class with no heavy dependency (MimeMessageUtil depends
on core James classes like MimeMessageWrapper).
---------
Then we have a bunch of mailets depending on AvalonServiceManager and
the james DNSService because they need some dns lookup service:
matchers/RemoteAddrInNetwork
matchers/RemoteAddrNotInNetwork
matchers/AbstractNetworkMatcher
matchers/SenderInFakeDomain
matchers/InSpammerBlacklist
They use: DNSServer.getByName(String host);
They also depends on the o.a.james.util.NetMatcher that simply depends
on the DNSServer for the getByName(String host) service).
It seems to me that adding a getByName to the MailetAPI we could make
all of this matchers generic.
----------
Then we have mailets depending on avalon configuration, on james
UsersRepositories and MailRepositories and more. But I think the above
list should be easier to take care as a first step.
-------------
Most of the listed stuff (excluding the last 2 groups) could be moved to
its own module along with some utility dependencies.
Should it be a function or a library? How do we package the utilities
that are used both by this mailets and by the core-library module?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
