I think that your explanation (below) is clear.
Why, in the name of all that is normal, would the email service provider
that you use test YOUR account for being full when YOU send an email? Or
to ask it another way, what is the logic for doing that? Are they
assuming that if your email inbox is full that you are not going to send
anything? That's just nuts.
Or, again, am I misunderstanding?
In your info, below, you identified yourself as u...@mydomain.net.
If you try to send me an email using your account u...@mydomain.net,
then I would only expect MY email address to be an issue in a perfect
world. Now, almost any self-respecting email service provider (your
service provider that you pay for the privilege) will test the
sender/sending address ("u...@mydomain.net") to be both a valid address
and an address that they are responsible for. Hmmmm.....maybe that is
why he is attempting to use a call back procedure...
Okay, so you say that this only happens when your inbox has reached the
arbitrary limit the service provider has set.
The service provider says that if they don't get a 250 (all okay) then
they refuse to let you send. Curious.
I would say that the service provider is using a very odd, and obviously
unworkable, method to determine if you are one of their customers. Why
would they not, instead, maintain a database of customers email
addresses and validate against that?
Sorry, but I'm going to have to cast my vote for another provider...or
you're going to have to poke them until they revise their methods. I
think you also said that something "changed" recently, so obviously they
are not anti-change.
This all makes me wonder if they actually have control of the email
server they are selling you service from...there are a lot of resellers
out there that just handle the human-customer-seller interaction and buy
the service at a discount from the actual computer owner-operator.
Mike
-------- Original Message --------
Subject: Re: [NF] Standard Email Sender Verification Procedures
From: Ken Dibble <krdib...@stny.rr.com>
To: profoxt...@leafe.com
Date: 4/29/2013 3:19 PM
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.
[excessive quoting removed by server]
_______________________________________________
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/517edaef.8020...@ggisoft.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.
