• The Inbox folder stores inbound email messages retreived from the POP3 server.
• The Errors folder stores Inbox email that cannot be delivered to the SMTP server.  This mail is delivered to the postmaster (optional, but delivered by default. See SMTP section)
• The Junk folder stores Errors folder email that can not be delivered to the postmaster.  It also stores email messages when EFS can not find any recipients of your domain (optional, turned off by default. See Headers section)

1.  Every message is failing to send or all mail is being sent to the postmaster: 

EFS specific:

• Incorrect spelling of your domain name in EFS (but correct postmaster email address)
• Incorrect spelling of your virtual domain name in EFS (but correct postmaster email address)
• The 'BCC all messages to' setting is enabled under the Headers tab in EFS


Other:

• Incorrect spelling of your domain name on the Mail Server
• SMTP server is not listening on the same port that EFS is sending too (TCP port 25 by default)
• Mail server has incorrect 'anti-relay' settings enabled and is denying EFS sending mail
• SMTP traffic is being blocked by an access list on a router or firewall

2. Most messages are being delivered successfully, only some messages are in the "Errors" / "Junk" folder or being delivered to the postmaster:

• Mail server or content filtering software is denying email because the email address does not exist
• Mail server or content filtering software is denying email because the message is over the maximum size allowed (hint: set EFS maximum email size = SMTP maximum email size)
• Mail server or content filtering software is denying EFS sending mail based on message content (possibly spam)

3. Mail Server specific:

• If you are running Exchange 2007, check the Quarantine rating for content filtering. Initially, try changing the rating from 5 to 7

Generally it is normal to have some mail delivery failures going to the postmaster, however a large number of delivery failures may indicate a misconfiguration.

• 1. An incorrect local mail server setting
  
  EFS can handle rejections from the mail server and act accordingly, however in general it should not be setup to work with mail servers that generate the following response when EFS sends mail to it:
  
  220 [200.150.100.50] Mail Server SMTP Ready.
  HELO EFS
  250 Ok
  MAIL FROM: sender@host.com
  250 Sender Ok
  RCPT TO: no-such-local-user@mydomain.com
  550 Destination Not Accepted
  
  (the 220, 250 and 550 lines are server responses to EFS mail commands) The error, shown in bold above, is generated by the mail server because "the local users mailbox does not exist". EFS is a forwarder, it specifically sits between an ISP and local mail server and "redirects" mail. It does not generate NDR (non-deliverable) messages to a sender if the user does not exist on the local server. However - unfortunately many spammers today will try and "guess" email addresses at your domain to try and get unsolicited emails through, therefore its very likely you will unintentionally receive email to non-existant addresses. If you would like better control over this, you can setup an EFSUSERS.TXT file (effectively a local whitelist) that contains all known email addresses in your domain (WARNING! ALWAYS ensure this file is kept up-to-date as any email address NOT in this file will be dropped! Also note that NDR's will NOT be sent to valid senders who may have mistyped an email address) 
  
  NOTE: You can allow EFS to work like this if you are happy that no "non-deliverable" report is sent back to the original user and the postmaster receives these messages instead.
  
  Generally, the local mail server should be setup to accept mail to ANY local address, regardless of whether they exist or not (do not confuse this with "anti-relay" or "routing restriction" settings - you should do this by IP address) If the user does not exist locally, it's the local mail servers job to deliver the "mailbox does not exist" message back to the sender. 
  
  NOTE: A mail server generating a "550 Destination Not Accepted" reply will cause EFS to consider the message as malformed. If this is the case, then the "malformed message header" rule applies (see below)
  
  Consult your mail server documentation to adjust your settings.
  
  
  
• 2. Malformed message headers
  
  EFS can handle "553 malformed message" emails. Malformed messages are messages that have an incorrect format somewhere in the header (usually the To: or From: field). For example, if a message had something like:
  
  MAIL FROM: bob@invalid@.domain.com
  
  ...then the second "@" symbol is the invalid character (in most cases, EFS is intelligent enough to work around invalid addresses)
  
  Again, it is not EFS that generates a "malformed message", it is the response from the local mail server to a command that it doesn't like or can't interpret. You can click the "Show Detail Window" from the "Advanced" section in EFS then send a message, watch the response that the mail server gives to each command that EFS issues it. For example, the following is a "detailed" transaction log of a malformed message (comments in italics)
  
  220 [200.150.100.50] Mail Server SMTP Ready.
  HELO EFS
  250 Ok
  MAIL FROM: bob@invalid@.domain.com
  553 malformed address: bob@invalid@.domain.com
  
  (malformed message response from the mail server here occurs due to an invalid FROM field. EFS re-connects and sets it's own FROM field in the format MAILER-DAEMON@your.domain which it knows is valid. It does this regardless of whether the error originated from the To: or From: field)
  
  220 [200.150.100.50] Mail Server SMTP Ready.
  HELO EFS
  250 OK
  MAIL FROM: MAILER-DAEMON@chimera.co.nz
  250 Sender Ok
  
  (EFS addresses the message to the postmaster, regardless of a valid TO field)
  
  RCPT TO: postmaster@chimera.co.nz
  250 OK - Recipient postmaster@chimera.co.nz
  DATA
  354 Send data. End with CRLF.CRLF
  250 OK
  QUIT
  221 closing connection
  
  
  As you can see from above, the extra "@" symbol in the FROM address causes the mail server to generate a "553 malformed address" response. EFS handles each malformed message by moving it to the "Errors" folder. After all other messages have been sent, it then reconnects to the SMTP server and sends each malformed message. It does this by creating a new message addressed to the postmaster and inserts up to the first 500 lines of the malformed message into the body.
  
  NOTE: Most firewalls (with SMTP daemons acting as redirectors) or mail servers with direct mail feeds simply deny the entire message if it is malformed. EFS gets at least part of the message through, notifying the postmaster to do something with it.