ietf-asrg
[Top] [All Lists]

Re: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID Verification)

2004-03-30 16:10:10

----- Original Message ----- 
From: "Eric S. Raymond" <esr(_at_)thyrsus(_dot_)com>
To: "Bart Schaefer" <schaefer(_at_)brasslantern(_dot_)com>

Yakov's point (unless I'm completely confused) is that it would
constitute
a new requirement for *sending* systems if the return-path "MUST" always
be
a valid address.  Hector says that it would not be a new requirement,
and I
still haven't been convinced that Hector is correct.

Yakov is correct that that would be a new requiremwnt.  But "MUST
always be a valid address" is not what I am maintaining, nor is it
Hector's position unless I have misunderstood him.

No, we are there! (pointing finger head to head back and forth) <g>

We are simply maintaining that sending MTAs MUST issue a valid return
path at time of transmission.

Lets put it this way.

SMTP server software vendors have no provisional logic that presumes the
return path address is NOT valid until a natural BOUNCE logic occurs prove
that is invalid.    You can only determine if it is indeed invalid by
PRESUMING it is valid in the first place.

Someone sends you a snail letter.   You look at the envelope, the first
thing you will see ask yourself is

            "Who sent this letter?"
            "Who is from?

I don't know about you.  For the most part, I am a skeptic.  But even then I
am not going to make any initial presumption that address is possibly false.
I am naturally going to presume it is valid and the only way to find out is
to check it out.

Now, this raises an very interesting point.  Here is something I did.  I put
a survey out there on my support mailing list last week about TRUST.

By far, the results was that people will put more TRUST into they recognize
as standard behavior over that is different.

The survey question ask was:

Scenario:

You are in your home sitting on the couch and you can see out the window
where you can see in front of your home your Mail Box near the street.
Everyday, almost at the same exact time, you see your friendly US Postal man
dressed in his official US Postal uniform drive up in his US Postal truck
and put something into the mail box.  You go out and get your mail.

One day, something very strange happens, you see the following happen:

a) An uniformed person, in a US Postal truck drop of mail,
b) An uniformed person, in a unknown car, drop of mail,
c) An non-uniformed person, in a US Postal truck drop of mail,
d) An non-uniformed person, in a unknown car, drop of mail,

What is common between ALL persons is that they drop off the SAME piece of
mail.

Questions:

1)  Please give the ORDER of mail delivery from Highest trust to lowest
trust.   In other words, who do you trust more delivering your mail?

2)  Please give the ORDER of mail scrutiny from highest TRUST to lowest
trust.  In other words, each person has delivered/dropped off the same exact
letter.  Whose mail will you scrutinize less or more?  Whose mail will you
open and  whose mail will you throw away?

I didn't tell them what I was intending to get from this.

My goal was to see if there is a level of trust that can be applied to:

  - BRAND of VENDOR software  (Truck/Company)
  - With a PERMIT to send mail (Uniform/Badge)

The most common address were:

A C B D in both questions.

Between B and C, people tend to trust a delivery person have a truck over
being uniformed. :-)

What I found most interesting is that many people indicated that in their
neck of the woods, there is no uniform or truck.  But a recognizable person
whose job is to be the post-person.  So if they did indeed see a change to a
UNIFORM and/or TRUCK, they will scrutinize the who delivered it and the mail
content.

Pretty natural I think, but  basically, in short,  people will react to what
is different and not standard behavior.

We can apply this basic "change in behavior" idea to SMTP as well.

---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>