ArrivalEvents

nickspoon

Hi there,

I am trying to work out how we should report ArrivalEvents to our customers.

It was my understanding that after a certain number of failed sends, an address would receive a block, and this would subsequently be reported to us (in a JobDeliveryStatus response) as a DeliveryDetailType.StateType.gammacode value of 6500 (Recipient is blocked), 6504 (Recipient is blocked for persistent failure: Mailbox Not Found) or 6505 (Recipient is blocked due to membership in a do not email list).

We are receiving a large number of ArrivalEvents, and I can now see that we are sometimes receiving ArrivalEvents for recipients whose addresses are clearly no longer valid. For example, I've found instances where an email address has received ArrivalEvents with Class.Subject.Detail values 5.1.1  for the last 10 attempts. According to the information we have been given, this combination of class, subject and detail is an error of some kind. So despite this recipient receiving consistent error arrivalevents, they are never blocked, and given a gammacode.

Could someone please explain how these ArrivalEvents should be interpreted? We log opens for some emails that have received an ArrivalEvent, so we can’t log them all as being non-deliveries. We need to know which ones are actual non-deliveries.

Do we actually need to use a combination of gammaCodes and ArrivalEvents to determine non-deliveries?

Any help and advice would be appreciated,

Nick

skamens

This is a good question with a somewhat complicated set of answers...

The gamma codes that you noted above would be logged if the system did not attempt to deliver a particular email message (in that case, the State of the item would be "Cancelled" - code 5).  So you would never see an ArrivalEvent for an item like this, since the system did not even attempt delivery.

The 6500 (Recipient is blocked) and 6505 (Recipient is blocked due to
membership in a do not email list) codes are currently in use (although the vast majority of these will just be 6500).  However, while there may be a few addresses in the system that still have the 6504 code, the system is no longer tracking persistent failures.  That's why even with multiple failures, you're not seeing any of your items getting this new code.

As for how to interpret Arrival Events - there is no simple answer to this.

The Arrival Events that we report are simply the contents of Delivery Status Notifications
(DSN's, or "bounce backs") that are received.  Our system intercepts these bounce backs, extracts the data from them, and stores them as Arrival Events in the system.

We may get "weird" DSN's for many reasons.  For instance, a user might have a filter set up to forward their message to a different account.  If the initial delivery succeeds but then the delivery to that other account fails, we might receive a failure notice even though the recipient actually got the message.  Another example is when the destination address is a mailing list, and one of the addresses on that list is bad; in that case some people would have received it, and you would still see an Arrival Event.

Because this is all so "fuzzy", there's no hard and fast way to interpret these events.  We recommend using logic that goes something like:

• If you do see open events, then you can be confident that the message was opened (but of course, you don't know for sure who opened it).
• If you don't see any opens, and you have an Arrival Event that indicates a permanent failure (class = 5), then it's likely (but not certain) that the message was not received.
• If you see no opens and no arrival events, then you can assume that the message was likely delivered, but there's no way to be 100% sure.

I hope this helps clarify things a bit without being too confusing.