Hard Bounce

A Hard Bounce indicates that an email cannot be delivered because of a permanent error. For example, a permanent error is when a mailbox does not exist for a particular domain. There is no point in continuing to attempt to deliver current or future messages to the address as it can no longer accept email.

Soft Bounce

Soft Bounces are when an email cannot be delivered to an address because of a temporary error. Unlike a hard bounce, a soft bounce indicates that it is possible to deliver to the address at some point in the future. An example of a soft bounce is a mailbox full response.

Connect using Direct Mail Sending

The following diagram illustrates how Connect uses Direct Mail Sending.

CUSTOMER_QUEUE Status Codes

There are several STATUS_CODES that are used in the CUSTOMER_QUEUE.

Table 1. List of CUSTOMER_QUEUE Status Codes

Scenario 1: Message Not Accepted by Destination SMTP Server

There is an error when Mail Sender attempts to execute the SMTP protocol with the destination SMTP server. Please refer to RFC-821 for more details. The following is a summary of codes and their description:

• 2XX - Positive Completion

• 5XX - Negative Permanent (a permanent error)

Note: Any network errors while establishing a connection or when executing the SMTO protocol are considered Temporary Errors.

For a permanent error: Mail Sender (using ComposerSyncLogs) updates CUSTOMER_QUEUE with status_code=104

For a temporary error: Mail Sender (using ComposerSyncLogs) updates CUSTOMER_QUEUE with status_code=2 (mail attempted). Another attempt to send all email is made at a later date.

Counters defined in COUNTER_MASTER where creator_name=Mail Sender are updated by the mail sender.

Scenario 2: Message accepted by destination SMTP server

When a message is accepted: Mail Sender updates CUSTOMER_QUEUE with the status_code=1.

Counters defined in COUNTER_MASTER where creator_name=Mail Sender are updated by the mail sender.

Scenario 3: Message accepted by destination SMTP server but sends a failure message back to the connect mail receiver (to the address specified in the email from field sent by Connect)

Stage1: Destination SMTP server accepts email.

• Connect considers the message successfully sent when the message is accepted by the destination SMTP server. The CUSTOMER_QUEUE is updated with status_code=1.

• Counters defined in COUNTER_MASTER where creator_name=Mail Sender is updated by mail sender.

Stage 2: Destination SMTP Server sends a failure reply to Connect MR.

• When Mail Receiver receives a reply from the destination SMTP server, it applies the Reply Handler as specified above.

• MSG* Tables are updated for the number of bounces and number of unsubscribe replies.

• Counters defined in COUNTER_MASTER where creator_name=Mail Receiver/Processor are updated.

Connect using Mail Farm

The following diagram illustrates how Connect uses a mail farm.

Mail farms usually accept all email coming from the Connect Mail Sender unless there are network issues between the Connect mail sender and the mail farm. As far as Connect Mail Sender is concerned any email accepted by the mail farm is considered to be successfully sent. If there is an issue when the mail farm tries to relay the email, it is up to the mail farm to retry or send a failure reply back to the mail receiver depending on how the mail is configured.

Scenario 1: Message not accepted by Mail Farm

If the mail farm rejects an email from the mail sender and if it is a permanent error, mail sender updates CUSTOMER_QUEUE with status_code=104.

Note: This is very rare since mail farms accept any incoming email then try to relay the email to the destinations.

If there is a temporary error, Connect tries to resend the same email a certain number of times as specified by the system parameter Max number of retries (Notification | Advanced) or until the email is sent. Since retry attempts occur immediately, Connect does not update CUSTOMER_QUEUE with status_code=2 like it does when using DMS.

Scenario 2: Message accepted by Mail Farm

When mail farm accepts an email, Connect considers that email successfully delivered.

Counters defined in COUNTER_MASTER where creator_name=Mail Sender are updated by mail sender.

Scenario 3: Message accepted by Mail Farm. If the mail fails after repeated attempts to send, Mail Farm sends a failure reply to Connect MR:

Stage1: Mail Farm accepts email.

• Connect considers the message successfully sent when the message is accepted by the Mail Farm. The CUSTOMER_QUEUE is updated with status_code=1.

• Counters defined in COUNTER_MASTER where creator_name=Mail Sender are updated by mail sender.

Stage 2: Mail Farm sends a failure reply to Connect MR.

• When mail receiver gets a reply from the destination mail farm, it applies the reply handler as specified above.

• MSG* Tables are updated with the number of bounces and number of unsubscribe replies.

• Counters defined in COUNTER_MASTER where creator_name=Mail Receiver/Processor are updated.

Scenario 3: Message accepted by Mail Farm. Mail Farm successfully sends the email to the destination email address. Destination SMTP Server sends a failure message back to Connect Mail Receiver (to the address specified in the email from field sent by Connect).

Stage1: Mail Farm accepts email.

• Connect considers the message successfully sent when the message is accepted by the destination SMTP server. The CUSTOMER_QUEUE is updated with status_code=1.

• Counters defined in COUNTER_MASTER where creator_name=Mail Sender are updated by mail sender.

Stage2: Destination SMTP server accepts email from Mail Farm.

Mail Farm successfully sends the email to the destination SMTP server. There is no change in Connect when this happens.

Stage 3: Destination SMTP Server sends a failure reply to Connect MR.

• When Mail Receiver receives a reply from the destination SMTP server, it applies the Reply Handler in the order specified above.

• MSG* Tables are updated for the number of bounces and number of unsubscribe replies.

• Counters defined in COUNTER_MASTER where creator_name=Mail Receiver/Processor are updated here.