----- Original Message -----
From: "Serge Knystautas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, March 04, 2000 4:12 PM
Subject: Re: Missing src files in framework project
> Federico Barbieri wrote:
> > Ok. What about filling theese infos in the SMTPHandler? Since it's
> > SMTPHandler to receive the message it's up to it to set Received and
> > Message-ID.
> > We must provide sendMail(..) with a VALID mail. Any optional work can be
> > done then in the servler pipe.
> >
> > My question is: one we are guarantee that mail is valid (sendMail) do we
> > still need IP info?
>
> I thought about it a bit more, and I think that MessageID and Received
> should be set in the SMTPHandler... that makes sense to me. The other
> headers (Date, From, To, Return path), should be set in a first servlet
> like you suggested. I'll write up a simple servlet to do this.
Ok
>
> As for IP address... I think you still need to provide it for possibly
> writing servlets that will restrict on IP address. With protocols like
> DRAC, the IP authentication can get quite complicated. The DRAC
> protocol/component watches your POP3/IMAP4 account, and if you
> successfully login, your IP address is added to the list of valid IP
> addresses for 30-60 minutes. Another thing is spam control (I'm
> restating some of this to get it on the listserv as well). Services
> list MAPS and ORBS list IP addresses of spamming mail servers from which
> you can block email.
>
> So... here's a really screwy idea... in the first servlet that sets the
> additional headers if you so desire, it will also go through, find the
> appropriate Received header, and parse out what the remote IP address.
> Then it can stick it in the Mail (former MessageContainer) object so
> that other servlets can use this.
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.
>
> Which makes me think of another approach I was considering for spam
> control. Rather than have every servlet checking for spam control
> determine what the policy for spam is, it will simply add a flag to the
> Mail object, and possibly a header to the email message. Then a later
> servlet (for instance right before local delivery), can check for this
> and bounce the email, or something Yahoo! does which I think is pretty
> smart... put it in the user's Bulk Mail folder (instead of Inbox). This
> will separate the checking parts from the admin's policy of what to do
> with spam.
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...?
>
> Also, as for the new Transport object... I'm thinking I'll call it
> SmartTransport, since from what I've seen, it's "smart" lookups that
> means you're using MX records to resolve the target server. Otherwise
> I'll model it like the javax.mail Transport object.
>
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...
> Time to start writing some code. I'll send you the changes.
GREAT!!!
>
> Serge
>
>
Federico
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
