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.

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.

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.

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.

Time to start writing some code.  I'll send you the changes.

Serge


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/>
Problems?:           [EMAIL PROTECTED]

Reply via email to