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]
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:[email protected] notify=success,failure
At least that's my understanding.
Mike
-------- Original Message --------
Subject: Re: [NF] Standard Email Sender Verification Procedures
From: Ken Dibble <[email protected]>
To: [email protected]
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: [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.
