The In-bound Message Filter (IBMF) receives any replies from recipients, while filtering out unsubscribe requests, out of office messages, viruses, spam complaints, and other unwanted responses to your emails. Any messages identified as unsubscribe requests or spam complaints will be processed and any actionable messages are sent to the forwarding email address provided by you (e.g. [email protected]).

The IBMF email address is based on your delegated subdomain or CNAME (e.g. [email protected]). When applied to any outgoing email messages from iPost, the IBMF becomes the "From" and "Reply-to" email address.

Please contact iPost Client Services for more information on how to add or update the IBMF.

The In-bound Message Filtering (IBMF) address provided with every client delegated domain (including Sender Domains) provides several levels of automated processing, based on a number of heuristic criteria.  "Heuristic" here means that an algorithm is applied to make an "educated guess" about the probable intention of the sender's message.

Automated processing steps are applied in the following order:

1. Check whether the message originated from the SpamCop reporting service.  Processing stops here and the reporting address is recorded as an opt-out.
2. Scan the message for common tricks used to embed malware in messages.  This is not a full commercial anti-virus scan and should not be relied upon to intercept all malware.  Processing stops here and the message is filed in a quarantine folder.
3. Examine the message headers for indications that it is a bounce-back from SMTP server software.  (Bounce-backs normally do not use the IBMF address.)
4. Examine the message headers for indications that this is another type of automated response, usually an "out of office" message.  Key phrases from several common languages are recognized (for example, German and French).
5. Scan the message header for other email addresses.Identify any addresses of common spam reporting services, for example [email protected], [email protected], [email protected].  
   1. If such an address is found, the message is considered a spam complaint.
   2. b. Collect other email addresses mentioned in the header.
6. Scan the message for iPost cryptographic tokens (aka "blobs") that identify a source message (for which the scanned message is a reply or forward).  The contact identity and email address of the recipient of that source message is extracted from the blobs.  This may be foiled by attachment or encoding methods via which the source message is included in a reply.  If no blobs are found, the email addresses collected at the previous step are used to search for a contact.
7. Attempt to distinguish (and ignore for further processing) the full content of any included or excerpted source message.  This may be fooled by user cut-and-paste, or by other means via which the source message is included in a reply or forward, so in some cases words or phrases used in the source message sent by the iPost client may trigger the additional steps below.
8. Scan the message body for any additional email addresses mentioned, except those that appear in "mailto:" URLs.  This catches automated responses from some ISPs that contain a list of several recipients all of whom are to be unsubscribed.
9. Scan the message body for "out of office" and similar auto-response messages, again using an assortment of language phrases.
10. Remove any message subject that contains phrases common to hospitality bookings or retail order processing when either preceded or followed by an unsubscribe phrase.
11. Examine the subject and sender for information about ISP feedback reporting loops.
12. Examine the subject for indications of spam complaints and unsubscribe key phrases.
13. Attempt to strip extraneous content from the message body, such as HTML formatting, HTML comments, style sheets, extra attachments, etc.  As with removing the source message content, this can also be foiled by unusual constructions.
14. Scan the remaining message body for:
    1. Keywords related to hospitality bookings or organization membership, plus other key phrases indicating that the message is not an unsubscribe request.  If found, the next part of this step does not apply.
    2. Unsubscribe key phrases.  These must appear within 10 lines of the beginning of the text that remains after extraneous content has been stripped.  Note that HTML formatted without line breaks or with mostly image content can result in phrases matching even if they appear very far from the "visible" top of the content.  The scanner does not render HTML or images, it looks at the raw text.
15. If the message does not contain any blobs, scan the message body for phrases common in spam messages, especially any that might be mistaken for unsubscribe phrases.  Messages that are found to contain such phrases are filed as spam.
16. Match the addresses found in the blobs and in the message header or body against the contact list of the receiving client.
17. If the foregoing steps have found that the message is a bounce-back or an out-of-office response, the message is redirected into bounce processing and IBMF processing stops.
18. Final disposition of the message:
    1. If at least one blob was found along with unsubscribe phrases, or the message is a feedback loop response, an opt-out is recorded.b. Otherwise, if the message does have a blob or an address that identifies a contact of the client, the message is forwarded.c. In all other cases the message is filed as spam.