tags:

views:

184

answers:

3

I want to write some email scanning software and don't understand how to setup my server. I have a hosted web server running Windows 2003 Server. It is running the Default SMTP Virtual Server with a fully-qualified domain name of abcdef.com (example). DNS is pointing abcdef.com to my server. If I spoof an email from my desktop pc so that it appears to come from [email protected], and I send the email to a 'non-existant' email address then the bounceback does arrive on my web server and is stored in C:\inetpub\mailroot\Queue on the server - great! (I can scan it and handle the bounceback). However, if I simply send an email straight to [email protected] then it does not seem to get placed anywhere on the server. I don't understand why bouncebacks get stored but other incoming email doesn't. I'm keen to avoid having to install any 'email server software' on the server, as I want to keep things as clean as possible. All I really want is some way of telling the server to accept all incoming messages to abcdef.com so that I can process them myself, and to place the .eml files in a known directory that I can scan. I'll then write an eml file parser to process the files. Thanks very much.

A: 

SMTP is a message transfer agent (MTA), responsible only for handling the transfer of mail from one point (the client, perhaps) to another (the mailbox server, such as a POP or IMAP server). SMTP servers aren't the right tool for ultimately handling mail coming INTO a domain -- they only handle transferring the mail coming into a domain to another app, such as the aforementioned POP or IMAP server, which then know how to sort and store that mail.

In short, the Default SMTP Virtual Server isn't the tool you're looking for for your project.

From this other StackOverflow question, it looks like there are a few SMTP servers which are intended for development use but which might serve the purpose you seek -- they accept incoming messages and then write them to files (in some manner, and with some tweaking).

delfuego
Ok, so perhaps I shouldn't have mentioned SMTP. However, the bounceback email IS being placed in C:\inetpub\mailroot\Queue, so why aren't other messages destined for {anything}@abcdef.com being placed there, and how can I tell the server to place them there?
DEH
The error message is stored because you're talking about two different things, outgoing email and incoming email.The "bounced" message is one you're trying to send **out** of the SMTP server. When your server connects to the destination domain's server and tries to deliver the message, the destination server says "no such user"; your server then leaves the message in your outgoing queue so that an administrator can deal with it.**Incoming** mail is entirely different, and as I said, the server you've chosen -- a pure SMTP server -- does not handle incoming email.
delfuego
I'm still confused here! I don't want to grab emails that I have generated - I want to gain access to all emails sent to abcdef.com. I understand that SMTP is for 'outbound' email - I need to handle inbound email. I am looking for the most lightweight way of configuring my server so that inbound emails (from anywhere on the internet) are stored somewhere in the file system on the server. Do I have to use a MailServer of some description, or can I configure the server in some way so that any inbound email is simply written to the server's file system?
DEH
Once again, the Default SMTP Virtual Server isn't the tool you're looking for -- it **does not do what you want it to**. You need another piece of software, one that handles inbound mail and saves it to the files that you intend to process. If you'll look at the last paragraph of my post, you'll see a link to another Stack Overflow post that offered up a few options.
delfuego
A: 

A possible reason for the lack of delivery is that your domain has a DNS A record, but no DNS MX record. MX records are used for delivery of mail. Historically, if no MX record was present for a domain, mail servers were supposed to fall back to looking for a domain's A record.

In your case, I'd guess that your local mail-sending software is looking for an MX record and then stopping if it doesn't find one, whereas the remote system sending you the bounce is looking for the MX record and then looking for an A record when it can't find one.

The Wikipedia article on MX records has more details.

Jon Bright
It stands to reason that there already is the appropriate MX record, since the SMTP server receives the delivery failure message from the OP's first trial (using an address at the abcdef.com domain as the From: address of an email and then sending it to a non-existent recipient) -- the only way the mailserver for the destination domain knows where to bounce the message back to is via the MX record.Either this, or the OP is using this SMTP server to try to *deliver* the message in the first trial, and the destination server rejects it in-band.
delfuego
delfuego, no. Test 1 is with a spoofed From: [email protected] to a remote domain. Test 2 is a direct mail to [email protected]. The two tests result in two mails being directed at abcdef.com, (presumably) from different mail servers. One of the mail servers might be falling back to using the A record when it fails to find an MX record while the other doesn't. See the linked Wikipedia article for details about fallback to A. It's possible to get mail delivered to a domain without an MX record (indeed, it's *supposed* to work, so any MTA that's not doing this is wrong according to RFC5321).
Jon Bright
From the OP's comment reply below, I think that the first test **was** done using this SMTP server to pass along the message, so that explains why it ended up remaining in the queue. But in the end, it still doesn't matter; the core problem is that the MS SMTP server is an MTA that doesn't have the ability to deliver mail to mailboxes or users, only to pass it from SMTP clients to SMTP servers (which might be more robust and able to deliver it to mailboxes or users via a POP, IMAP, Exchange, or other server with these capabilities).
delfuego
Jon, thanks for the info about A fallback -- I had *totally* forgotten about that behavior!
delfuego
A: 

Ok, working now. Issues were as follows:

  1. There was no MX record, so external email wasn't being directed to the server. The .EML file that existed on the server was indeed placed there by an outbound email process.
  2. The firewall was blocking port 25 - now opened.
  3. It is necessary to have some sort of inbound email service running on the server. Windows Server has a lightweight POP3 service which you can configure to place all incoming email into a single 'catch-all' mailbox. This fills with .EML files, which can then be scanned by our custom service.

Many thanks to delfuego & Jon.

DEH
DEH