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: u...@domain.com
If the user is known, the receiving server will respond with something like
250 OK - Recipient u...@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.01ca6...@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.
