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 u...@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 u...@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 u...@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 u...@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.01cab...@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.