For those of you who administer email servers that communicate with the

internet:

Is it standard SMTP procedure to send a test email to a sender's address to

verify that the address is valid?

My email provider does this, and it causes continuous problems when a POP

client is being used and it is set to hold messages on the server for a

specified number of days. This is not a free email service; we have to pay

for every MB of storage, so huge GMail-style mailboxes are not an option.

Therefore, often the user's mailbox is full, and she/he is therefore not

allowed to send email until s/he forces the server to partially or fully

empty his/her mailbox.

This, in my opinion, is an unfair and poor way to verify the sender's address.

Surely it must be possible for an SMTP server to do sender-verify in a

different way, such as by querying its own table of valid accounts.

Would this still occur with IMAP? As I understand it, IMAP is a retrieval

protocol, not a send protocol. But if an ISP offers IMAP, which, as I

understand it, by default leaves messages on the server, then surely the

ISP must anticipate that many mailboxes will be full and would have to use

some other sender verification strategy.

I am not asking for a referral to some other email service provider.

I am trying to understand what the options are for sender verify and why

people use them.

Thanks for any information.

Ken Dibble

www.stic-cil.org

_______________________________________________

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.20130429131822.01c7de18@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.

On Mon, Apr 29, 2013 at 1:29 PM, Ken Dibble <krdibble@stny.rr.com> wrote:

> For those of you who administer email servers that communicate with the

> internet:

>

> Is it standard SMTP procedure to send a test email to a sender's address

> to verify that the address is valid?

>

No, this is the first time I've heard of that. Wikipedia describes callback

validation [1] but this shouldn't actually result in an email saved.

> This, in my opinion, is an unfair and poor way to verify the sender's

> address.

>

Agreed.

> Would this still occur with IMAP? As I understand it, IMAP is a retrieval

> protocol, not a send protocol. But if an ISP offers IMAP, which, as I

> understand it, by default leaves messages on the server, then surely the

> ISP must anticipate that many mailboxes will be full and would have to use

> some other sender verification strategy.

>

IMAP and POP are a completely different technology, that for retrieving and

storing email. not sending it. They don't have to even be on the same

box(es) as the SMTP service. So, no IMAP would not make a difference.

I am not asking for a referral to some other email service provider.

>

Perhaps you should be. The problem is your service provider is using an

arcane methodology and, as most service providers are supplying gigabytes

for free as part of their service, perhaps it's time you reconsidered your

mail system design. At the very least, a stern discussion with them to see

if they can prevent their self-caused outages.

> I am trying to understand what the options are for sender verify and why

> people use them.

>

As explained in the Wikipedia article, they're trying to verify that mail

actually came from a real mailbox and not a made up fake spam one. However,

I have a hard time understanding how this is filling up a mailbox until the

storage capacity is pitifully low.

POP is not designed to retain mail on the server. The "retain for x days"

functionality was an after-thought and the implications not fully

understood. It would probably make more sense to retain email in-house or

with another server. You could put your own mail server in between the

users and the internet, and retain mail there, but that may just be

shifting the problem.

[1] http://en.wikipedia.org/wiki/Callback_verification

--

Ted Roche

Ted Roche & Associates, LLC

http://www.tedroche.com

--- StripMime Report -- processed MIME parts ---

multipart/alternative

text/plain (text body -- kept)

text/html

---

_______________________________________________

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/CACW6n4tQ2hivbLgnc2m745Xp1fLpT_E79P=t+SvvEkBpi08OJw@mail.gmail.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.

At 10:29 2013-04-29, Ken Dibble <krdibble@stny.rr.com> wrote:

>For those of you who administer email servers that communicate with

>the internet:

I do not, but.

[snip]

>Surely it must be possible for an SMTP server to do sender-verify in

>a different way, such as by querying its own table of valid accounts.

It would be a boon for spammers. They would be able to send

lot of tests to determine which E-mail addresses are valid.

[snip]

Sincerely,

Gene Wirchenko

_______________________________________________

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/

** 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.

>I am not asking for a referral to some other email service provider.

> >

>

>Perhaps you should be. The problem is your service provider is using an

>arcane methodology and, as most service providers are supplying gigabytes

>for free as part of their service, perhaps it's time you reconsidered your

>mail system design. At the very least, a stern discussion with them to see

>if they can prevent their self-caused outages.

>

>

> > I am trying to understand what the options are for sender verify and why

> > people use them.

> >

>

>As explained in the Wikipedia article, they're trying to verify that mail

>actually came from a real mailbox and not a made up fake spam one. However,

>I have a hard time understanding how this is filling up a mailbox until the

>storage capacity is pitifully low.

>

>POP is not designed to retain mail on the server. The "retain for x days"

>functionality was an after-thought and the implications not fully

>understood. It would probably make more sense to retain email in-house or

>with another server. You could put your own mail server in between the

>users and the internet, and retain mail there, but that may just be

>shifting the problem.

Thanks Ted.

Possibly the tech who explained this to me did not fully explain what he

was doing. The "test" emails are not ever actually delivered, so there must

be something further going on; perhaps they contain a code that causes them

to be immediately tossed into the bit bucket. However, if the mailbox is

full when they arrive, they are, naturally, bounced, and any rejection is

then interpreted as "sender verify failed". I would think that at the very

least the thing should be able to read the actual text of the bounce

message and verify the sender if the message contains "over quota", since

such a message indicates that the account exists, but the guy insisted that

this is not possible.

Maintaining the security and functionality of an email server that

communicates with the internet is a headache I don't want or have time for.

(We have an internal email server but that is not a significant security

risk.) I'm a one-man IT department in an agency of nearly 100 computer

users. I barely have time to do what I already have to do. :)

Thanks,

Ken Dibble

www.stic-cil.org

_______________________________________________

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.20130429145507.01c93dd8@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.

>>Surely it must be possible for an SMTP server to do sender-verify in a

>>different way, such as by querying its own table of valid accounts.

>

> It would be a boon for spammers. They would be able to send lot of

> tests to determine which E-mail addresses are valid.

I don't see how they would not get the same results from such a set of

tests no matter what method is used to verify senders.

This is a test on the "From" address of a sender using SMTP, not a test on

the "To" address of a recipient. If a spammer is going to send out a bunch

of emails with randomly generated "From" addresses and keep the ones that

don't get bounced, I don't see why it matters how the SMTP server decides

which ones to bounce.

Anyway, I think it would probably be better and faster for the SMTP server

to read the bounce message and verify addresses for which the message

contains "over quota", since that's a valid existing address.

Ken Dibble

www.stic-cil.org

_______________________________________________

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.20130429150543.01c9d2c8@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.

One of the first steps in the connection and sending of email from

server to server is to identify who the message is for (sender) and a

response from the receiving server as to whether that person (address)

is known to them. At that point, based on the receiver's response, the

sender can abort the transaction.

Look up the SMTP command RCPT TO.

Example:

RCPT TO: User@Domain.Com

If the user is known, the receiving server will respond with something like

250 OK - Recipient User@Domain.Com

Here's an article from MSoft Support

http://support.microsoft.com/kb/153119

Note the last two paragraphs

In addition to the basic testing steps that are listed in this

article, you can use a delivery receipt to test mail in both

directions. You can use this method to verify that the SMTP server

can accept an incoming connection and generate a delivery receipt

back to the sender to test outgoing connectivity of the SMTP server.

To request a delivery receipt for the test message, see step 5 in

the "Basic Testing" section to make sure that the information

provided is a valid email address that can receive the delivery

receipt. Then in step 6 in the "Basic Testing" section, type the

following command in the Telnet session:

RCPT TO:User@Site.Domain.Com notify=success,failure

At least that's my understanding.

Mike

-------- Original Message --------

Subject: Re: [NF] Standard Email Sender Verification Procedures

From: Ken Dibble <krdibble@stny.rr.com>

To: profoxtech@leafe.com

Date: 4/29/2013 2:05 PM

>

>> I am not asking for a referral to some other email service provider.

>> >

>>

>> Perhaps you should be. The problem is your service provider is using an

>> arcane methodology and, as most service providers are supplying

>> gigabytes

>> for free as part of their service, perhaps it's time you reconsidered

>> your

>> mail system design. At the very least, a stern discussion with them

>> to see

>> if they can prevent their self-caused outages.

>>

>>

>> > I am trying to understand what the options are for sender verify

>> and why

>> > people use them.

>> >

>>

>> As explained in the Wikipedia article, they're trying to verify that

>> mail

>> actually came from a real mailbox and not a made up fake spam one.

>> However,

>> I have a hard time understanding how this is filling up a mailbox

>> until the

>> storage capacity is pitifully low.

>>

>> POP is not designed to retain mail on the server. The "retain for x

>> days"

>> functionality was an after-thought and the implications not fully

>> understood. It would probably make more sense to retain email

>> in-house or

>> with another server. You could put your own mail server in between the

>> users and the internet, and retain mail there, but that may just be

>> shifting the problem.

>

> Thanks Ted.

>

> Possibly the tech who explained this to me did not fully explain what

> he was doing. The "test" emails are not ever actually delivered, so

> there must be something further going on; perhaps they contain a code

> that causes them to be immediately tossed into the bit bucket.

> However, if the mailbox is full when they arrive, they are, naturally,

> bounced, and any rejection is then interpreted as "sender verify

> failed". I would think that at the very least the thing should be able

> to read the actual text of the bounce message and verify the sender if

> the message contains "over quota", since such a message indicates that

> the account exists, but the guy insisted that this is not possible.

>

> Maintaining the security and functionality of an email server that

> communicates with the internet is a headache I don't want or have time

> for. (We have an internal email server but that is not a significant

> security risk.) I'm a one-man IT department in an agency of nearly 100

> computer users. I barely have time to do what I already have to do. :)

>

> Thanks,

>

> Ken Dibble

> www.stic-cil.org

>

>

>

[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/517EC785.6000209@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.

Here's a complete interactive session between a telnet application (the

sending server being impersonated by the telnet program and a human) and

the receiving server. At the end, based on the response of the receiving

server, you could have a conditional branch to abort with a "thumbs up"

or "thumbs down" depending on the response.

By the way, you can duplicate this test from any computer workstation,

using telnet, although depending on the telnet OS and the receiving

server's email application, the dialog will vary some.

In the example, "telnet: >" is what the sender types, and "server:" is

the response from the receiver. (The "client:" is the sender's prompt,

after the connection has been established.)

telnet:> telnet mx1.example.com 25

telnet:Trying 192.0.2.2...

telnet:Connected to mx1.example.com.

telnet:Escape character is '^]'.

server:220 mx1.example.com ESMTP server ready Tue, 20 Jan 2004 22:33:36 +0200

client:HELO client.example.com

server:250 mx1.example.com

client:MAIL from: <sender@example.com>

server:250 Sender <sender@example.com> Ok

client:RCPT to: <recipient@example.com>

server:250 Recipient <recipient@example.com> Ok

You'll also need to know what port the receiving server uses...many

email servers no longer support the old smtp standard port 25, instead

using 587, or if they are forcing secure connections via SSL, 465 is common.

Mike

-------- Original Message --------

Subject: Re: [NF] Standard Email Sender Verification Procedures

From: Ken Dibble <krdibble@stny.rr.com>

To: profoxtech@leafe.com

Date: 4/29/2013 2:05 PM

_______________________________________________

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/517ECA3C.2030103@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.

At 02:18 PM 4/29/2013 -0500, you wrote:

>One of the first steps in the connection and sending of email from server

>to server is to identify who the message is for (sender) and a response

>from the receiving server as to whether that person (address) is known to

>them. At that point, based on the receiver's response, the sender can

>abort the transaction.

>

>Look up the SMTP command RCPT TO.

>Example:

> RCPT TO: User@Domain.Com

>If the user is known, the receiving server will respond with something like

> 250 OK - Recipient User@Domain.Com

So it should return 250 if the recipient exists, regardless of whether that

mailbox is full?

The provider's system didn't work this way originally. It didn't stop

refusing to verify a sender whose mailbox was full until after they

implemented a "security update" I think, in late 2011 or early 2012.

According to the Wikipedia article linked by Ted, I think if the SMTP

server attempts RCPT TO: and gets 250 back, it can stop the process at that

point, thereby not delivering a message to the recipient, and can also

refuse to send a bounce message back to the original sender in order to

prevent a dictionary attack.

However, my email client will always display the SMTP error in that case

(550 Sender verify failed) which ought to be just as useful to a dictionary

attacker that can directly read the error message.

So it would seem that nothing really can be done within the realm of email

sender verification to protect against such attacks as long as the SMTP

server emits some kind of response to the original sender when a message

doesn't go through for whatever reason--which, it seems to me, it must do

in some manner. At least, in the case of my ISP, returning 550 ought to be

just as valuable to a spammer as anything else it could return short of

outright lying, in which case a legitimate sender would have a problem.

The Wikipedia article implies that security (over) conscious mail admins

may be misusing the protocols. However, I don't understand this well enough

to develop a response for my provider.

Can you (or anyone) perhaps suggest exactly what sequence of commands and

responses I should ask my provider to use for sender verification?

Thanks.

Ken Dibble

www.stic-cil.org

_______________________________________________

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.20130429152447.01ca6650@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.

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

provider's server using Telnet.

To see a plethora of testing procedures, just google "telnet smtp test"

Here's a pretty thorough treatment of the subject...

http://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-session-2/

For the above to work, you'll need to know exactly how the offending

connections are being performed.

As for how the email server on the receiving end handles a full

mailbox...typically the receiving server, not knowing how large the

inbound message is until it has received it, will accept the message

before it checks to see if the mailbox is 'full' and can not handle the

inbound message. So, no, the receiving server won't respond with "sorry,

all full" at the step you are expecting it to (before sending the

message.) Besides that, the "quota" or maximum size for the inbox, is

arbitrary and determined by the email server manager. Because of the

time it would take to calculate the current size (fullness) of your

inbox, the receiving server is going to delay that step in the process

until after the communication with the sending server has ended.

Instead of the receiving server responding with "oh, no, thanks but I'm

full" when you offer another delicious piece of email pie, the receiving

server will, after the receiving connection is closed and the full-osity

has been determined, bounce a message back to the sender's inbox (not

the sending server! it may not be the same) saying something like

"sorry, all full". At that point, you have another issue on your

hands...how does your SENDING email inbox server handle bounce back

messages and what happens when there is a flurry of those?

Bottom line, full email in-boxes are a big pain in the email. With

storage space so cheap though, you should have no problem getting a 10GB

to 25GB inbox (unless you're using a free service, in which case it will

only be around 2GB to 5GB.) It should take hundreds if not thousands of

spams to fill that up! So now we have another issue...inbox maintenance.

Does anyone ever clean out the inbox that is overflowing? (Sorry if you

already covered this, I just did a quick-scan of your first message a

couple of hours ago.)

If you are wanting to determine, for example through a program you

write, what the current "fullness" of your inbox on that email account

is, you can usually do that using the IMAP protocol, but it will take

several steps and you'll need to know the inbox max limit. I say usually

because it, again, depends on the receiving server.

Mike

-------- Original Message --------

Subject: Re: [NF] Standard Email Sender Verification Procedures

From: Ken Dibble <krdibble@stny.rr.com>

To: profoxtech@leafe.com

Date: 4/29/2013 2:35 PM

> At 02:18 PM 4/29/2013 -0500, you wrote:

>> One of the first steps in the connection and sending of email from

>> server to server is to identify who the message is for (sender) and a

>> response from the receiving server as to whether that person

>> (address) is known to them. At that point, based on the receiver's

>> response, the sender can abort the transaction.

>>

>> Look up the SMTP command RCPT TO.

>> Example:

>> RCPT TO: User@Domain.Com

>> If the user is known, the receiving server will respond with

>> something like

>> 250 OK - Recipient User@Domain.Com

>

> So it should return 250 if the recipient exists, regardless of whether

> that mailbox is full?

>

> The provider's system didn't work this way originally. It didn't stop

> refusing to verify a sender whose mailbox was full until after they

> implemented a "security update" I think, in late 2011 or early 2012.

>

> According to the Wikipedia article linked by Ted, I think if the SMTP

> server attempts RCPT TO: and gets 250 back, it can stop the process at

> that point, thereby not delivering a message to the recipient, and can

> also refuse to send a bounce message back to the original sender in

> order to prevent a dictionary attack.

>

> However, my email client will always display the SMTP error in that

> case (550 Sender verify failed) which ought to be just as useful to a

> dictionary attacker that can directly read the error message.

>

> So it would seem that nothing really can be done within the realm of

> email sender verification to protect against such attacks as long as

> the SMTP server emits some kind of response to the original sender

> when a message doesn't go through for whatever reason--which, it seems

> to me, it must do in some manner. At least, in the case of my ISP,

> returning 550 ought to be just as valuable to a spammer as anything

> else it could return short of outright lying, in which case a

> legitimate sender would have a problem.

>

> The Wikipedia article implies that security (over) conscious mail

> admins may be misusing the protocols. However, I don't understand this

> well enough to develop a response for my provider.

>

> Can you (or anyone) perhaps suggest exactly what sequence of commands

> and responses I should ask my provider to use for sender verification?

>

> Thanks.

>

> Ken Dibble

> www.stic-cil.org

>

>

[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/517ED0DE.4010309@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.

>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.