> > I think that is not correct to close a connection during a DATA > > session, so I think that there should be NO stage when we > received the headers.
> True, though other servers do it to avoid receiving the whole > message. > Not ideal though. Which servers? RFC states that we should retry if a server drop the connection during the DATA transmission. So they will not reach their goal. > > IMHO current Matcher/Mailet api are not enough to have > REAL, RE-USABLE > > mailets between different mailet containers: most James mailets > > currently use and need concepts specific to james, repositories, > > states, attributes that are not defined by the mailet api. > > Repositories are expected to be added, states are already in > there (do you have examples of what aren't), attributes are > rather app-specific and I wouldn't expect to codify. Maybe > some standard ones need to. Got some specifics you think > need to be added? I think we should put inside the specification the notification service: default DSN/Bounce handling and similar things should be defined by the mailet API. IMHO the mailet context should know wether a message spooled has been lost, has got errors, has been succesfully delivered/processed, has been relayed, remotely delivered or anything else. I'm not sure but probably we shoult take care of the fact that mailet and matchers behaviour can depend on one or more of: - SMTPEnvelope headers (MAIL FROM, RCPT TO, DATE) - MimeMessage headers/body I think we should provide this classification because Matchers/Mailets that match/change only the MimeMessage headers/body could also been used in NON-SMTP environment (e.g: rule system for a mail client). Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
