用Java自动处理电子邮件

Question

Just got a request from my boss for an application I'm working on. Basically we're getting an email address setup for an external client to submit excel files to.

What I need is a way to automatically pick up any email sent to this address, so I can take the attachment, process it and save it to a folder.

Any information of even where to start would be helpful.\\

Note: We're using a lotus notes server to do this, but a generic way would be more helpful (If possible).

Answer 1

Email -> mailserver ->[something] -> file-on-disk.

File on disk is pretty easy to parse, use JavaMail .

The [something] could be:

• listener for smtp connections (overkill)!
• Pop3 / imap client
• Maildir /Mailbox

Answer 2

Edit: since I first wrote this answer, Wiser has moved and now claims to only be a unit testing tool, so take the answer below with a pinch of salt...

---

Svrist's answer is good, but if you want to avoid his middle step (the mailserver that writes the mail to disk for later pickup by the Java system) you can use Wiser .

Wiser lets you start an in-Java mailserver:

Wiser wiser = new Wiser();
wiser.setPort(2500);
wiser.start();

Then you can just poll it periodically for mail:

for (WiserMessage message : wiser.getMessages())
{
    String envelopeSender = message.getEnvelopeSender();
    String envelopeReceiver = message.getEnvelopeReceiver();

    MimeMessage mess = message.getMimeMessage();

    // mail processing goes here
}

Answer 3

I've done quite a bit lately with Java agents on Domino servers. The Domino 8.5 server supports Java 6 and its embedded so it won't take someone with a bit of Domino development experience long to put together an agent that runs when new mail arrives. In LotusScript its even easier but that needs more specialised skills which you'd probably need to get a contractor in to provide.

The limitation your likely to encounter concerns the extracted file, you can easily place it on the Domino server's file structure but you may be limited by the OS security from placing it on a different server.

Answer 4

Use a mail in database (your Domino administrator can set that up for you but it's in the help file as well).

In that database, you can create an agent that runs periodically to process all new documents. That agent will use the EmbeddedObjects property of the NotesRichTextItem class and the ExtractFile method of the NotesEmbeddedObject class to get a handle on the file attachment and extract it to the location you specify.

For example, this script goes through all the file attachments, object links, and embedded objects in the Body item of a document. Each time it finds a file attachment, it detaches the file to the SAMPLES directory on the C drive and removes the attachment from the document

Dim doc As NotesDocument
Dim rtitem As Variant
'...set value of doc...
Set rtitem = doc.GetFirstItem( "Body" )
If ( rtitem.Type = RICHTEXT ) Then
  Forall o In rtitem.EmbeddedObjects
    If ( o.Type = EMBED_ATTACHMENT ) Then
      Call o.ExtractFile( "c:\samples\" & o.Source )
      Call o.Remove
      Call doc.Save( False, True )
    End If
  End Forall
End If

Answer 5

No matter what you do, you'll need an understanding of the Lotus Notes data structures. The good news is that a fully automated solution can be built in Notes very easily.

Your best bet is to have it built within Notes, and it can be set up to run automatically whenever new mail is received. Gary's answer is dead on, but without any experience, it would probably be hard to figure out how to implement it yourself. On the other hand, it really shouldn't take any competent Notes programmer more than an hour or two to set it up.

Answer 6

Lotus Notes/Domino stores mail in a Notes database. There are APIs available for getting documents (emails), reading field values (From, Subject), and detaching files.

APIs include

-LotusScript (VB variant, available within the Notes database)

-Java (from within or external to the database)

-C API (external)

-Same API available through COM server

You can create a "scheduled agent" within the database (using LotusScript or Java) that can locate documents created since it last ran, locate the attachments, and extract them. The agent will need to be signed with an ID that has the appropriate permissions on the server, including those required to write to the file system and initiate any other processes.

External to the database, you can use any API except LotusScript to log-in to the server/mail database, and follow a similar process, eg extracting the files locally on a client or separate server. C API and COM require a notes client install, but Java applications can be set up to run via CORBA/DIIOP without a full install.

Consult the Domino Designer help (or IBM's website for C API) for more information.

As to a "generic way" to do this, if you are accessing data in Notes and needing to extract attachments, I believe these APIs are your best option. If you envision porting the application to another mail system, consider decoupling the API routines via an "interface" so you only need to add a new implementation of that interface to support a new mail system.

Answer 7

您可以使用DIIOP相对轻松地访问Notes文档，比沿着C Api道路更容易...

Answer 8

Try POP3Client in the Net Commons package ; it'll let your Java program check for new mail for a particular account at whatever interval you want (every few minutes? hourly?), and get/delete messages as desired.

Answer 9

SMTP/POP3 can be enabled on the Domino server. Worked with this before and gotten Squirrel Mail running with it. SMTP is a bit resource intensive, but well worth the effort because then you don't have to descend into LotusLand to get things working. Just write a small Java CLI program that will check a specific email box (POP3 or SMTP), and parse through the messages, pulling the attachments and placing them where needed.

Plenty of documentation and examples here: http://java.sun.com/products/javamail/

The techniques that you develop taking this approach will be more widely applicable in your future career than anything Lotus/Domino specific.