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.