We can't do Delivery Reports - WebAfrica

[Edunhin]

I have recently (24/10/2011 & 07/11/2011) migrated 4 domains to WebAfrica, I have now 31domains registered with them. The Monday after the 1st migration, I got a call from my customer that indicated that they do not receive any Delivery Reports on any of their sent emails.

After checking that everything was in order on the site I contacted WebAfrica, they have now (14/11/2011) advised (after migrating the domain in question from Smartermail 3 to Smartermail 5) that the issue seems to be with Smartermail (smartertools.com) and that there is nothing ells they can do about it. I questioned if they spoke to Smartertools, and they indicated they have exhausted every possible solution.

So that’s it.. Well I have now posted on startertools forum, to see if they can assist.
But it seems that it is going to be an uphill battle as WebAfrica is running on their newest email server legacy versions of Smartermail, so it seems that there is no support for them. Why is an ISP who charges fees for hosting emails, not on the latest build, or at least have paid support from their vendor


http://forums.smartertools.com/show...at-Smartermail-is-the-issue?p=96823#post96823

 

[w1z4rd]

Im sure if you go through the logs you can see the delivery reports fine enough.

Ive actually never heard of delivery reports before this post.

They are probally on a dated system because all their current systems are programmed to integrate with the older system. Being older doesnt mean bad. I have stable versions of older software running on a lot of servers.

 

[maumau]

we changed our steam email address yesterday from webafrica to gmail. automatic login codes emailed by steam arrived 30 minutes late on webafrica and were "outdated" when entered on steam. i phoned WA support but they were unaware of email problems. gmail arrives almost immediately.

 

[Edunhin]

Agree on the older versions comment, but then you can't tell your customer sorry the problem is with the software and there is nothing we can do about it, and if your software vendor is not offering support, you need to do someting about it.

 

[w1z4rd]

Agree on the older versions comment, but then you can't tell your customer sorry the problem is with the software and there is nothing we can do about it, and if your software vendor is not offering support, you need to do someting about it.

What is a delivery report? Why on earth would someone be asking for one? Is that different to a read receipt?

 

[Edunhin]

What is a delivery report? Why on earth would someone be asking for one? Is that different to a read receipt?

A delivery report is a report indicating that an email was delivered to a mailbox. The reasons for that is one can disable the sending of Read Receipts, so if your avoiding someone they will have no proof that the email was delivered. In cases like my customer who deals with liquidating companies, they need to provide proof of delivery, as usually people try to avoid the law

 

[PsyWulf]

What is a delivery report? Why on earth would someone be asking for one? Is that different to a read receipt?

It's called Delivery Receipt in some mail clients. For the serverside it's called a Delivery Status Notification (DSN) - specifically in this case Positive Delivery Status Notification and is described in the RFC 1891

It confirms delivery of email to the remote server ( and if fully supported,the mailbox ),which sometimes is good when diagnosing issues ( "It delivered to your server,it's your problem" )

 

[koffiejunkie]

A delivery report is a report indicating that an email was delivered to a mailbox.

This is a relic from the days when the internet was a safe place used by a handful of academic folks who all had each other's best interests at heard.

While it's fine to use delivery receipts (and read receipts if you want) internally, i.e. for mail sent from one address to another address on the same domain, it is incredibly stupid to enable this for public mail. You'll be confirming delivery to spammers and phisers alike and be completely reliant on your antivirus/antispam doing a 100% accurate job, 100% of the time.

It's about as stupid as using Outlook's "recall" feature if you have no idea that the recipient is also using Outlook.

In cases like my customer who deals with liquidating companies, they need to provide proof of delivery, as usually people try to avoid the law

A delivery receipt would not stand up in court. All it shows is that the mail was delivered to a mailbox. It doesn't prove any (let alone all) of the following:

1. That the mailbox owner collected it from the mailbox
2. If it was collected from the mailbox, that the mailbox owner's e-mail client didn't put it in the junk folder or that their antivirus didn't eat it (and if you've used Outlook's built-in junk filtering, you'll know how dodgy it is)
3. That the mailbox owner actually opened and read it
4. That it was, in fact, the mailbox owner is the one who downloaded it.

We routinely clean up abandoned mailboxes for clients where thousands of mails have piled up to the point that it affects server performance. The delivery receipt, in this case, means squat.

 

[Edunhin]

Thanks for that, and it is all well and good, but it is a feature that my client had, and after migrating to WA it is not there anymore, thus the client is indicating either it works or he moves back to his previous ISP.

 

[koffiejunkie]

Thanks for that, and it is all well and good, but it is a feature that my client had, and after migrating to WA it is not there anymore, thus the client is indicating either it works or he moves back to his previous ISP.

It is not a reliable feature. It requires every hop on the way to the client to support and reliably deliver these reports, and most mail servers simply don't. DSN is not proof of delivery - you need to help your client understand that.

 

[Johand]

This is a relic from the days when the internet was a safe place used by a handful of academic folks who all had each other's best interests at heard.

While it's fine to use delivery receipts (and read receipts if you want) internally, i.e. for mail sent from one address to another address on the same domain, it is incredibly stupid to enable this for public mail. You'll be confirming delivery to spammers and phisers alike and be completely reliant on your antivirus/antispam doing a 100% accurate job, 100% of the time.

It's about as stupid as using Outlook's "recall" feature if you have no idea that the recipient is also using Outlook.



A delivery receipt would not stand up in court. All it shows is that the mail was delivered to a mailbox. It doesn't prove any (let alone all) of the following:

1. That the mailbox owner collected it from the mailbox
2. If it was collected from the mailbox, that the mailbox owner's e-mail client didn't put it in the junk folder or that their antivirus didn't eat it (and if you've used Outlook's built-in junk filtering, you'll know how dodgy it is)
3. That the mailbox owner actually opened and read it
4. That it was, in fact, the mailbox owner is the one who downloaded it.

We routinely clean up abandoned mailboxes for clients where thousands of mails have piled up to the point that it affects server performance. The delivery receipt, in this case, means squat.

+1. e-mail cannot be used like this, and it is in fact your duty to educate people about that fact. Normal e-mail is not secure in any way or form and delivery receipts is meaningless. In fact, not only can it be that a delivery receipt is not sent, it can also be that delivery receipt is sent but the mail discarded in any case (e.g. spam filter/mailbox quotas/AV appliances etc).

And you can fake mail. There is no generally accepted and adopted way for e-mails to be encrypted and for both the sender and receiver to validated. In my job the topic once came up and I settled it by faking mails from the people trying to push the e-mail agenda to each other. Matter settled. You don't even need any software - sometimes it is as easy as punching the fake details into the mail client settings.

If you trust e-mail and/or promote the trust in e-mail and/or keep you mouth shut while people trust e-mail then you have a serious problem.

I am slightly paranoid about this because I also hear stories that some ACB's accept unencrypted files via e-mail for debit orders. :wtf:

 

[koffiejunkie]

If you trust e-mail and/or promote the trust in e-mail and/or keep you mouth shut while people trust e-mail then you have a serious problem.

Exactly. If you let your customers think they can rely on this, it *will* come back to byte you. One day, sooner or later, your client will lose business because of this and they'll want to know from you why it happened.

 

[Ben_D0ver]

tell webafrica to stop being so cheap and upgrade their smartermail 3 licenses to smartermail 8.
their is something that they can do, its just going to cost them and that means that top brass wont have money to pay bonuses.