The administrator of the mail server has the authority to set email
quotas on a per user basis. In my system, which runs Fedora, Postfix,
Dbmail, and PostgreSQL, setting the quota to 0 allows a user to have an
unlimited amount of space on the mail server for emails. Otherwise,
quotas on each user account is set to some reasonable amount of server
disk space.
Once a user hits his quota limit, the user is required to clean up his
emails in order to continue using his email account on the mail server.
You might talk to your administrator to see if he/she would remove
quotas on your email account(s) by setting them to zero, or raise the
quota limit on the account(s) over quota.
I'm using Thunderbird as my email client. I can check my email account
quotas on my mail server by right clicking on an email folder, selecting
properties, and then clicking on the quota tab. This allow me to easily
identify quota problems and delete emails on over quota situations;
until, they the space used by the user falls back below quota limits.
Regards,
LelandJ
On 04/29/2013 03:19 PM, Ken Dibble wrote:
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 [email protected]. 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 [email protected] 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
[email protected] 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 [email protected]. 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.
[excessive quoting removed by server]
_______________________________________________
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.
