Federico Barbieri wrote:
> I'd prefer to see the Mail object filled by the SMTPHandler. Since,
> IMHO, anti-spam should be based on routing info more than headers inside
> MimeMessage... here's what I was thinking:
> the sender in Mail could be a InternetAddress extension with a
> InetAddress getHost() method.
>
> public class MailAddress extends InternetAddress {
> public InetAddress getHost() {
> return host;
> }
> ....
> }
>
> public class Mail {
> public MailAddress getSender();
> ....
> }
>
> this way both servlets and matches classes can easily access both name
> and IP of host sender and efficiently check anti-spam rules.
> The sender is detected by the SMTPHandler.
Excellent! I was thinking something just like this (although I wasn't
going to add the MailAddress class... I'm not sure what this gives
you... why not just call smtpsocket.getInetAddress ()? I guess there's
also the HELO command, but this is obviously easily spoofed.
The problem I'm facing is... James (the mail server block) does not
support accepting a Mail object... just a MimeMessage, a sender, and a
vector of recipients (ok, also a string for the MimeMessage). We'll
have to add a method to James to support storing your own Mail object.
Another slight change I made was then to use the MimeMessage's own
Message-ID (from the header) as a Mail object's MessageId (the store's
key). Actually, when you send a message to it, it sees if this
messageId is already in the store, and if it is, it adds (count++) to
the beginning of the Message-ID. This is nice because sometimes you
like to look in the spool (or whatever store) and find a particular
message. Always using the locally generated Message-ID can make it
more difficult to find. This is just a little thing though and I think
I can see how it would cause problems.
> This takes me to another question. Should we provide a flagging
> mechanism inside the Mail object (to makes servlet somehow communicate
> each other) or should we force servlet independence avoiding any
> flagging except ERROR (with its private message)?
> What I'm afraid of is linking mail servlets with more than necessary
> "contracts" that take the risk of gluing together mail servlet in a
> single "mail application" limiting pluggablity.
> Comments...?
Yes, I actually would like the support of attributes, like HttpSession,
except for Mail objects. add setAttribute (String, Object),
getAttribute (String), removeAttribute (String). That would be
extremely cool IMHO.
> I think it would be nice to follow javax path and make SmartTranport extend
> javax.Transport. This could be done overwriting in
> meta-inf\javamail.defailt.providers
> the default smtp provider but I'm not sure it is legal or not...
I went back and forth over making this it's own implementation of a
Transport object. So it became "smtps://host" (smtp Smart), but this
actually created problems in the URLName object. The transport object
expects you to use this, but actually when you connect, you'll be
connecting to one of multiple mail servers. Because of this (and
because the delivery actually gets attempted to multiple servers), I
ended up just making SmartTransport it's own object that uses the
existing SMTPTransport to deliver messages after the DNS lookup is
complete. It was working quite nicely. I've got a ton of code to ship
you, part of that however are the changes to James (to accept a Mail
object instead of just MimeMessage and recipients, etc...). It's a bit
of a mess, but I'll try to send you the changes shortly. Been very busy
at work this week.
Serge
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
