It's the ability to check from within any mailet if, when SMTP AUTH is active, the sender user has been successfully authenticated and also his name.
The name is passed along with the mail as a mail attribute named "org.apache.james.SMTPAuthUser", and can be get with a command like:
String authUser = (String) mail.getAttribute("org.apache.james.SMTPAuthUser");
Great stuff. This was one of best reasons for mailet attributes, IMHO.
I understand that we might need to do some CVS juggling, to better tag the old code (perhaps the Mailet API). But as I'm going away for a long weekend (until Monday) I just wanted to turn it in before leaving.
Yes, seems like we should get the mailet API vs. james (server) release schedules better defined in the short-term now. This may also help usher in some of the other changes pending in 3.0.
A second more general topic regarding mail attributes: as I just said I've used an attribute named "org.apache.james.SMTPAuthUser", defined in SMTPHandler and in two new matchers using a "private final static String" constant in each of them (and using the constant name instead of the string - mail.getAttribute(SMTP_AUTH_USER_ATTRIBUTE_NAME)):
I think there might be a large number of constants for attributes we'll want to do. I think these should be part of the Mailet API though (instead of SMTP Handler), and would put them on Mail.
It would be better to start using a "org.apache.mailet.Attributes" class in v3 and a "org.apache.james.util.Attributes" class in v2, similar to the RFC2822Headers class, just to hold any such new attribute name constant and reference it from everywhere. Or perhaps something else.
I think Attributes is design overkill. I think constant Strings is great.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
