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 <[email protected]>
To: [email protected]
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: [email protected]
If the user is known, the receiving server will respond with
something like
250 OK - Recipient [email protected]
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: [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.
