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.