>I might not be understanding your question, but I would test the

>provider's server using Telnet.

I think you may not be (or I'm not understanding your explanations). My

problem is this:

I am user@mydomain.net. That email address is managed by a company that I

pay for the privilege.

My desktop email client uses POP/SMTP. It is set to leave messages on the

server for a certain number of days and then delete them. This so that the

account can be accessed from more than one email client.

Yes, I know IMAP can handle this differently but for now let us just assume

that I continue to use POP/SMTP (as I had been using for well over a decade

without problems until late 2010 or so).

Now, the mailbox for user@mydomain.net on the server is full. I can

determine this by checking the webmail, or by trying to send a message to

that account and receiving a "mailbox over-quota" bounce message.

Now, while that mailbox is full, I try to SEND email FROM user@mydomain.net

to ANYBODY. The recipient is irrelevant. When I attempt to send the

message, I do not receive a bounce-back email. I immediately get "550

Sender verify failed" in my email client's error display.

My mail provider says that he's using a callback procedure that involves

"trying to deliver an email" to user@mydomain.net. He says that if the

server returns anything other than 250 OK, he sends back the 550 error.

My complaint is that his server should be able to differentiate "account

does not exist" from other possible sources of results other than 250, and

if the account actually exists, then his server should allow me to send

messages.

If it will help, I've included a (lightly) edited transcript of my email

conversation with the provider about this, below.

Thanks.

Ken Dibble

www.stic-cil.org

Here are the pertinent parts of the email conversation I had with the

provider. If this makes sense to anyone, please let me know. (Actually, the

provider's behavior first changed, to start sending 550 Sender Verify

Failed if the sender's mailbox was full, in late 2010.)

Me:

People here frequently have full mailboxes; that situation gets rectified

within a matter of days in the normal course of business. They should not

have to be bothered by whether their mailbox is full at the moment they

want to SEND an email to somebody else.

So can you please turn this behavior off for STIC's email accounts?

Provider:

It is not possible to disable it on a per domain basis, and we are not

going to disable it on the per server basis, sorry. It prevents soo much

invalid / spam mail.

The reason it fails is this,. the server does an SMTP callback to the mx

for the domain and try to deliver a mail. Since the mailbox is full it

gets fail.

We are using totally different mail server software now, then before the

move/upgrade hence the reason we cannot disable it.

Your options are to either disable quotas on individual boxes, or make sure

that people don't let their mailbox fill up.

Me:

IMO, a bad design, since it monitors an irrelevant state in order to make a

decision about something completely different. Simply put, in real terms,

full mailbox <> invalid sender. Mailbox exists == valid sender, but that is

an entirely different thing.

Provider:

The problem is that you are looking at from the point of view that the

MTA knows anything about the LDA, and they don't. MTA is the Mail

Transfer Agent. The LDA is the Local Delivery agent. So when the MTA gets

a message and it is looking to receive it. it looks at the MAIL

FROM line. Once it gets that it issues the SMTP Callback to verify the

existence of the account. It really doesn't even know that the account is

local. So it issues the call back and it gets a temp failure code. The MTA

only sees the temp failure code, it doesn't care about the english text

after it, since that format of that is undefined and left up to the mail

server to provide (and is optional at that). So the MTA now only knows

that it tried to deliver a message to the sender and it failed with a 4XX

error code, and didn't get a 2XX (250 normally) , so it will reject the

message with the failure code, and text. Normally the sending mail server

will see this as temp failure and try again at a later time, but in the

case of an MUA (Mail user agent) like Outlook or thunderbird, it just fails

right away and doesn't really retry later.

Does that make more sense?

Me:

I understand what you're describing. But the old system apparently didn't

do things that way, so therefore it cannot be necessary to do things that

way. It would seem that either:

whatever the MTA's callback request talks to is looking at the wrong thing,

since the MTA is trying to find out whether the account is valid, not

whether the mailbox is full,

or

There should be a different call in the SMTP spec to determine specifically

whether an account is valid regardless of the state of the mailbox, and

that is the call the MTA should issue.

I certainly don't know all the ins and outs of the SMTP specification but

there must be something in there that would work better than this, since it

worked better than this a year ago.

Provider:

The old system was very bad at dealing with inbound spam.

No there is nothing.

Basically you have status codes.

2XX - Everything ok

4XX - Temp Failure , try again later

5XX - Perm Failure , just go away and don't try again..

That is pretty much it. Over quota is a Temp Failure (4xx), but as I said

the call back doesn't know why it failed, just that it failed. And if the

sender verification failed

That being said there is nothing we can do, save for you to either remove

quotas or not let the accounts go over. If the person is attempting to

send email, they should be capable of checking/removing it, unless I am

missing something.

-- End transcript

And, they did another "security update" in December of 2012, after which,

the system got even worse at handling spam, while still retaining the 550

Sender Verify Failed problem on full sender mailboxes.

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/5.2.1.1.1.20130429160848.01cabb20@POP-Server.stny.rr.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.