To me, it would seem ideal for fetchPOP to be no different to the SMTPHandler, from the point of view of the rest of JAMES. I can see the difficulty in having to deal with the extraneous recipients of fetched messages, but I wonder if this could be dealt with through the use of a (v3) mail attribute?2) Is there a reason why fetchpop does a send instead of a store?For the resaons stated by Serge & Noel I wanted fetched mail to be treated the same as SMTP delived mail, to gain the advantages of the mailet pipeline. Although recent comments suggest that short-circuiting fetched mail straight to a single user might be a worthwhile option.
Obviously fetchPOP cannot delete the unwanted recipients, as the real recipient may wish to see them, but if both the SMTPHandler and fetchPOP set a mail attribute for the "active recipient", then this could be used to allow mailets to ignore extraneous recipients and process the mail with respect to the "active" recipient only. No differentiation between mail receipt mechanisms would then be necessary.
The down side of this idea is that the SMTPHandler would have to submit each message to the processor once /for each recipient/. This poses obvious efficiency problems. This could perhaps be worked around by allowing multiple "active" recipients for a single message.
An actual field on the Mail interface is probably better suited to this purpose than a mail attribute, as it would need to be a universally used mechanism to be of real use. I see mail attributes as being an extensibility mechanism for use in situations where the attribute is not universally used.
Any thoughts?
ADK
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
