Forums & Blog

Hi,

 You say that in the event of a bug / problem SM will return your ticket back. Ok taking that into consideration then please answer this for me.

if a mail is sent by a customer to an invalid recipient outside your servers, and the log file clearly indicates 554 user does not exist 5.1.1, should the server return the mail to the user as undeliverable, or to continue retrying the email until the retry limits are reached. ?

My answer to this is this is a BUG, the email should be returned to the user the user clearly does not exist. but my ticket was not returned  and SM said this was the way the system worked as it could be the user was not yet created, or the likes.

1. If a mail is sent to the wrongly spelt username or domain that clearly does not resolve or the user does not exist, or the message is ovesized for that server or user, it should be bounced back as a failure. (The chances of the admins, creating a user, adjusting the mailbox size, message limit, or adding a new domain within the next 24-48hrs is almost zero. Sure it could be done, but why wait for 24-48hrs before returning the email to the sender in the hope that this gets done.)
2. if the domain exists and the server is unavailable, or the mailbox is full then sure keep retrying the mail.

I would rather have a email bounce back telling me the domain does not exist or the dns servers are down, at least I could address the problem immediately and not look like an ass and only sort out the issues like 24-48hrs later. Reactive service looses customers. Proactive service keeps customers.

 

kdovale:

Hi,

 You say that in the event of a bug / problem SM will return your ticket back. Ok taking that into consideration then please answer this for me.

if a mail is sent by a customer to an invalid recipient outside your servers, and the log file clearly indicates 554 user does not exist 5.1.1, should the server return the mail to the user as undeliverable, or to continue retrying the email until the retry limits are reached. ?

My answer to this is this is a BUG, the email should be returned to the user the user clearly does not exist. but my ticket was not returned  and SM said this was the way the system worked as it could be the user was not yet created, or the likes.

1. If a mail is sent to the wrongly spelt username or domain that clearly does not resolve or the user does not exist, or the message is ovesized for that server or user, it should be bounced back as a failure. (The chances of the admins, creating a user, adjusting the mailbox size, message limit, or adding a new domain within the next 24-48hrs is almost zero. Sure it could be done, but why wait for 24-48hrs before returning the email to the sender in the hope that this gets done.)
2. if the domain exists and the server is unavailable, or the mailbox is full then sure keep retrying the mail.

I would rather have a email bounce back telling me the domain does not exist or the dns servers are down, at least I could address the problem immediately and not look like an ass and only sort out the issues like 24-48hrs later. Reactive service looses customers. Proactive service keeps customers.

Yes, there's no doubt this is a bug.  I know of no other mail server that exhibits this behavior.

Why would SM do this?  The only conclusion I can come to is that they have little confidence in their DNS resolution so they need to retry the message. 

As for this thread... the fact that SmarterTools hasn't chimed in here is evidence to me that they really don't give a damn. 

-Joe

kdovale:

if a mail is sent by a customer to an invalid recipient outside your servers, and the log file clearly indicates 554 user does not exist 5.1.1, should the server return the mail to the user as undeliverable, or to continue retrying the email until the retry limits are reached. ?

 First let me say that my expectation is that a 5.x.x error generates a NDR to the user immediately.  This is a common expected practice among nearly every single MTA.  However, I believe the RFC leaves an open.
 

The RFC answer for this is that 5.x.x errors are permanent errors. 

A permanent failure is one which is not likely to be resolved by
resending the message in the current form.  Some change to the
message or the destination must be made for successful delivery.

If ST focused on the "..... destination must be made for successful delivery."  With the thought that if the user account is created at the destination than it seems they meet the RFC.

This is a terrible implementation and they should at the least create a configuration option to allow a 5.x.x. code to generate a NDR.

Darrell

-------------------------------------------------------------------------------------------

invURIBL - Intelligent URI filtering plug-in for SmarterMail.  Stop spam at the source the spamvertised domain.  More effective than traditional RBL's.  Try it today - http://www.invariantsystems.com

My point exactly this to me is a bug, all other mail servers I have used does this, however SM4 does not, as can be clearly seen from below, this is a critical failure in all senses to me, to reduce the impace my retries were brought down to a total of 10 retrys with a 5 hour total so at least this bounces back in a shorter time. I have already lost 3 companies business due to this problem...

Received:
250-telkomsa.net Welcome to the TelkomSA SMTP Server.
250-PIPELINING
250-SIZE 11048576
250-DATAZ
250-AUTH LOGIN PLAIN
250 8BITMIME
Sent:
mail from:
Received:
250 ok
Sent:
rcpt to:
Received:
554 Sorry, no mailbox here by that name. (#5.1.1) Server rejected the recipient address.

The remote server clearly rejects the email but SM keeps it in it's in the queue as below, this is clearly a non valid user and should be treated as such with a 5.1.1 error SM should return the message and its not as can be clearly seen this message has been in the queues for 4hrs 48 minutes and is on its 9th retry. The above log is from smtpdiag and as can be seen the session is dropped immediately, however the SMTP log clearly reflects the 554 no mailbox here by that name. (#5.1.1) but carries on regardless.

55712821.eml

someone@someplace.co.za

4:48:29

9

9/5/2007 2:11 pm

0 / 1

Waiting to Deliver

1 KB

Spool

I'm not so active in the forum because SmarterMail 4 just works and I have no issues with my installation.

I come here from time to time to check if there is a new beta or any other news and try to answer a question or two while I'm here...
 

The forums are nice and I go through them daily, but since the release of 4.0 I have seen a significant drop in the participation by the staff. A prime example is that I have had a simple question out for a week now with no response, its something that none of us could know, and only requires a one line answer. They must have so much business that they can't afford to take the time.

I encourage each of you that have lost support tickets to the stupid things I've read here to call sales and get an E-Mail address of someone at the top and let them know (in a calm polite way) what you think (squeaky wheel).      

Well, then........where do I begin?

First--yes, this thread was started on a long holiday weekend here in America so we are a bit late to the conversation.  But why all of the comments about "not give a dang" (etc.)?  Anyone who has delt with SmarterTools for any length of time knows that this is not the case.

Let's start with the Forum/Support/Simple Questions topic.
It is always a balancing act.  The forums are for both you and us.  We encourage our active user community to participate and make suggestions to each other--we participate as well.  We are "smarter" as a whole community than we are individually.  Support Tickets are there as a direct pipeline into us for help.  Have a truly simple question?  Call us.  If it is indeed a simple answer we have never said "no."  However, I will tell you from first-hand experience that sometimes what one person considers to be a "simple" question can quickly become worth multiple Support Tickets.  If a question necessitates a complicated response or research--it should be a Ticket.  We will track that issue through to resolution and that stuff may become part of future development efforts.

Pay for Support--it's a good thing.....really!
You have to choose a business model.  We decided that it was better to have a low price for our products--arguably the best value in the Windows mail server marketplace--and then allow customers to only pay for additional support when they need it.  If the price of a product is higher and/or less stable, but includes technical support, then that support is not really free, is it?  And remember, purchased licenses and upgrades come with two support incidents--so we do include a certain amount of support in the price in case anyone needs a little help right out of the gate.  With this model no one is ever paying for Support that they do not need.  This becomes a big deal for those who purchase more than one license--where odds are that their support requirements will be significantly less.  Why should they pay for what they do not need?  It all boils down to value.  It's OK to pay a few bucks for Support when you really need it as long as you receive value at least equivalent to what you have paid. 

Nobody pays for bugs, ever.
First of all, we need to have someone start a Ticket--it's how we track of the whole thing.  It's a very good system.  If the issue is confirmed as a bug, that Ticket is refunded.  I am not aware that this has ever not been the case.  If you ever believe that your issue hase not been given the proper classification (a bug, or not a bug), by all means give us a call or send us an email.  We will take a look at it and reconsider, if appropriate.

Is it Good Form to Boast?
Sometimes you just can't help but toot your own horn--just a little--when facing criticism.  SmarterMail is the most stable, easy to use, secure (0 known vulnerabilities), and feature-rich Windows mail server available in our market space.  It is also a leader in price point.  We have a Technical Support system that includes online Help, knowledgeable staff, white papers, this community forum, and two levels of paid support.  This combination strongly suggests that SmarterMail is the best value on the market--even if we occasionally take a long holiday weekend.  :-)

The Specific Issues
One of our Support Team members will be looking at the specific technical issues mentioned in this thread to see if we can help. 

By the way--Mike (mgraveen) suggested a mailing list or some such to keep in touch.  We have some mailing lists that you can subscribe to through the Manage Account area of the SamrterTools site.  It may not deliver all of the data you are looking for, but we try to keep everyone up-to-date.  I will see if additional mailing lists might be in order.

Our User Community is very important to us--keep the feedback coming.

- Jeff

kdovale,

 SmarterMail should be generating an NDR for these messages. 5xx series errors are permenant failures (which was mentioned above). I have verified with our development team, and these messages should fail immediately, generating an NDR.

We will be looking into this issue to make sure that this is the case.

**UPDATE**

I verified with our latest version of SmarterMail, that if SmarterMail receives a 5xx error, it should generate an NDR. It did in our test. Specifically the 500 No Such User Found.

kdovale:

My point exactly this to me is a bug, all other mail servers I have used does this, however SM4 does not, as can be clearly seen from below, this is a critical failure in all senses to me, to reduce the impace my retries were brought down to a total of 10 retrys with a 5 hour total so at least this bounces back in a shorter time. I have already lost 3 companies business due to this problem...

Received:
250-telkomsa.net Welcome to the TelkomSA SMTP Server.
250-PIPELINING
250-SIZE 11048576
250-DATAZ
250-AUTH LOGIN PLAIN
250 8BITMIME
Sent:
mail from:
Received:
250 ok
Sent:
rcpt to:
Received:
554 Sorry, no mailbox here by that name. (#5.1.1) Server rejected the recipient address.

The remote server clearly rejects the email but SM keeps it in it's in the queue as below, this is clearly a non valid user and should be treated as such with a 5.1.1 error SM should return the message and its not as can be clearly seen this message has been in the queues for 4hrs 48 minutes and is on its 9th retry. The above log is from smtpdiag and as can be seen the session is dropped immediately, however the SMTP log clearly reflects the 554 no mailbox here by that name. (#5.1.1) but carries on regardless.

55712821.eml

someone@someplace.co.za

4:48:29

9

9/5/2007 2:11 pm

0 / 1

Waiting to Deliver

1 KB

Spool

Jeff I hear where you are coming from, And I agree with you.

However I have been in the Support Game for 22 years now, admittedly I do not now everything about every product, however I am quite capable of resolving and sorting out a 90 % of problems myself, and really when I have exhausted most know avenues, forums, google, etc I then need to turn to someone who should know their products.

I have no qualms paying for support and would not expect it any otherway, I to do not just give away support for free all the time, however when a customer says they are having a problem I at least investigate it and isolate the exact cause of the problem and dependant on the issue charge or do not charge for the service.

But I have some issues, of which other people also have the exact same problems (which means I am not the only one, excperiencing this), But I have highlighted the fact that this is happening on our and other peoples servers, and yes the software quite rightedly should work one way and it is not. The reason for it could be due to a config problem, software bug, etc.

But I feel that when someone comes back to you after you have asked them to help sort it out, and they reply with an answer that is really not helpfull in anyway, Ie "we have tested and our servers do not do that" does not resolve the issue.

This issue might only mean that 100 mails a week out of 40 000 have this issue and it is not a major train smash and is more of an irritation but the reality of it is, that the problem is happening, the customers are getting p'd off due to this. But ST should be taking this as an opportunity to find out why it is happening and investigate further.

Ben, I agree it shouldnt happen, and most likely is not happening on your servers, however this IS happening on our servers, If I can help out in anyway please let me know how. Logs, etc.

For me, it's because of the way that SmarterMail is written makes it real easy for a decent email administrator to troubleshoot their own problems. XML config files, decent logging, and mailbox .GRP files are mostly plain text as well. Only major issues I've had with SmarterMail were actually caused by outside sources such as a .NET Framework issue with reading certain IP's in domain forwarding and that .NET update that broke the calendar...

kdovale -

Our Ticket system is built just for things like this.  I do believe you when you say that you solve 90% of the problems on your own--we have some pretty smart users out there.  We want to help you with your issue.  Sorting through log files and such--by definition--requires the use of a Support Ticket.  Otherwise, we could not effectively track the issue through to completion.  That's just common sense.  If the issue is determined to be a bug, that Ticket is refunded in full without delay.  If, on the other hand, it is a setting or component or other item particular to your system (or a handful of similarly configured systems), then it is not a bug--it's Tech Support.

If any one of our team is not giving good customer service or support, I want to hear about it.  I would really like to see the context and form of the message you quote: "we have tested and our servers do not do that"   If that was indeed the extent and intent of the message, I will look into it on my end.  Send me a private message with the whole thing.

I encourage you to confidently start a Support Ticket with your issue.  The Team looks at log files and such all the time and that is what they are here for.  If it's a bug....no charge--we'll fix it and move on.

Keith,

If your installation of SmarterMail is indeed not behaving correctly, then we definitely want to look into it further. This would require a support incident. I wrote the previous message to let you know that SmarterMail is designed to bounce 5xx series errors. And this is how it performed.

This does not mean that it isn't happening. This means that SmarterMail is designed to behave that way, and even though you are not the only server that is having this issue, we do not have the necessary information to fully troubleshoot this issue.

For us to give this issue our undivided attention, it would require the incident. This is so we can document the issue fully, and provide you the utmost value of the incident. It will also put us on track to give you a resolution. If there is a bug, then we will forward it to the development team and it will help provide them the documentation to readily work out a fix action.

fhaglund:

I'm not so active in the forum because SmarterMail 4 just works and I have no issues with my installation.

I come here from time to time to check if there is a new beta or any other news and try to answer a question or two while I'm here...
 

Same here.  It's refreshing to have a mailserver that just works.  Migrated from Imail almost a year ago and haven't looked back.