As you have found, the SMTP protocol is a set of guidelines that...some
are adhered to closely, some not so much. Error codes is one of the not
so much areas.
At this point, all I can say for sure is that your provider is choosing
to disallow your sending outbound messages via SMTP when your inbox is
full (your account has reached disk storage quota) as you have proven. I
find that choice, by them, to be arbitrary and pointless. I just don't
see the connection. Do they want more $$$ for a larger quota? Are you
getting so much email in your inbox that it fills up that quickly? I
would consider getting a free Gmail account and using that for some of
your message reply-to addresses or something.
In my opinion, you aren't doing any thing wrong unless not cleaning out
your inbox more often is to be considered a mistake on your part.
Mike
-------- Original Message --------
Subject: Re: [NF] Standard Email Sender Verification Procedures
From: Ken Dibble <[email protected]>
To: [email protected]
Date: 4/29/2013 9:32 PM
Try to work completely through the telnet test and send yourself an
email "Hello World" and see what happens. And yeah, I'm very aware of
what a pain in the butt sending email via telnet is....one little
typo and you have to start over.
Okay. So after following the same Telnet steps I do:
recpt to:[email protected]
550 verification failed for <[email protected]>
550 mailbox quota exceeded
550 sender verify failed
My provider seems to indicate that after accepting the rcpt to:
command he issues his callback to [email protected], and
if this generates something other than 250, he sends 550 back to me.
He further explains that quota exceeded is a "temporary error" in the
400 range, and that if his callback returns a number in the 400 range
he will issue 550 back to me.
So now I'm reading the (painful) SMTP return code reference. There
does seem to be general agreement on the range of available return
codes, but somewhat less than general agreement on what they mean.
There doesn't seem to be a 400-range error specifically for "mailbox
quota exceeded". The closest one is in RFC 2821 is 452 - "Requested
action not taken - insufficient system storage"; that is, according to
one more detailed reference
(http://www.hosteng.com/faqfiles/SMTP%20Server%20Status%20Codes%20and%20Errors.pdf)
there is insufficient disk space at the host for
[email protected], which may mean that the entire host
server is full, or all of the space allocated for my domain is full,
or just that my mailbox is full. Or it may mean that the SMTP server
is out of memory, or that its limit on concurrent connections has been
reached.
This would not seem to be a clear indication that my account is valid;
it only would appear to demonstrate that my domain is valid.
However, there is also 552, for which the RFC 2821 legend is
"Requested mail actions aborted - exceeded storage allocation". The
above-cited reference PDF says this means "The user's mailbox has
reached its maximum allowed size." But neither RFC 2821, nor another
reference at http://www.authsmtp.com/faqs/faq-25.html, is willing to
go so far in specifying the meaning of this code, which on its face
would only seem to mean that the condition defined in 452--or
whichever of the several possibilities listed there--is not
"temporary" but "permanent".
My provider says that anything after the number is "undefined" and not
required.
So I guess the pertinent questions now are:
Is there a real difference, other than "temporary" vs "permanent",
between 452 and 552?
Then, if the answer is, "Yes, 452 is insufficient disk space or RAM or
connections for presumably temporary reasons and 552 is always mailbox
quota exceeded, a permanent condition until the user takes action to
rectify it," then why doesn't the provider's callback return 552
instead of "some number in the 400 range"?
And if the callback does in fact return 552, could not the provider
then conclude that the account is valid?
And, lastly, how does any of this inform my provider, who hosts many
domains, that my domain not only exists, but is a domain that he hosts
and for which he should provide SMTP service?
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: [email protected]
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/[email protected]
** 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.
