ietf-mxcomp
[Top] [All Lists]

Re: Caller-ID group is hiring!

2004-04-30 07:30:11


----- Original Message ----- 
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "'Dave Crocker'" <dcrocker(_at_)brandenburg(_dot_)com>; "Margaret Olson"
<margaret(_at_)margaretolson(_dot_)com>
Cc: "IETF MARID WG" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Friday, April 30, 2004 9:41 AM
Subject: RE: Caller-ID group is hiring!



Actually, there is an interesting hole in many of our discussions:
What about spoofing from _within_ an organization?  Since most
organizations suffer data theft from within, this is not a small
concern.

This is certainly an issue. Google 'Larry Ellison' and 'Adelyn Lee'
to see why.

But it is reasonably easy to fix this inside an enterprise. You
just need to implement an appropriate security policy, implement
authentication on your mail server, eliminate all relayed mail
that claims to come from inside the enterprise.

Which is why I say, relaxed provisions should be time-limited.  AOL has this
problem with using a MAIL FROM AOL.COM domain resulting in a neutral result
however, the HELO domain is also a AOL domain, with PTR/A records all
correct.

I see this as part of the chain of trust and mix policy issue.

HELO needs to taken very seriously.  I hope the following to become part of
the domain policy definition outlined by Pete.

In my view,  HELO lookups can only logical yield a  none, accept or fail and
in situations where HELO SPF result other than none conflicts with the
return path SPF result, HELO should prevail.

    marid(HELO::IP) -> none, accept, reject
    marid(RPD::IP) -> none, accept, reject, other (currently neutral,
softfail)

It would be fundamentally illogically to have a conflictive mix policy, thus
subject to rejection based on technical compliancy.

This helps address a group of the possible forwarding scenarios:

If you have a marid(RPD::IP) reject, neutral of softfail,  a check HELO
should be done for a MARID conflict.

If marid(HELO::IP) returns ACCEPT, this is either a forwarding situation or
we have an open relay/proxy at the machine.

The issue then resorts to the "chain of trust" problem which I believe can
be solved, but we need more thinking here.  Kind of feels like the answer so
simple, it is within grasp! <g>

On the other hand, if marid(HELO::IP) returned REJECT, then in my view, this
is a illegal transaction and subject to rejection.

So when you think about it,  if there is a policy for HELO define, I feel it
must prevail in the logical decision making process  It can't be violated
but RPD policies.

I also have some comments about Game Theory concepts will help play a role
here but first I want to see if the above comments are ignored. :-)


-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com







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