I think people are looking at the 'authority' issue from the
wrong end.
<mantra>I won't say it. It's too easy.</mantra>
Who has the 'right' to tell me how I can use an IP address?
'rights' to send traffic are tempered with 'rights' to refuse
or accept it at the other end. It is a whole other theological
argument that was beaten to
death a decade ago and I wouldn't want to see repeated here.
Then you are in the wrong place.
The argument that 'this was already decided elsewhere' has zero
credibility. If you don't want to argue your case, fine, don't.
Just accept the other point of view :-)
This tactic is part of what is called 'agenda denial' in the
propaganda litterature. Instead of answering legitimate issues
you attack the question. It is terribly unpatriotic of you to
attempt tactics of this kind, it only gives encouragement to
the enemies of this country.
The consistent point of view here is that we are not talking
about an access control problem except at the receiver end.
The asset we are trying to protect here is the end user's
indox and the resources at the receiving end.
I believe it's often referred to as: "Flogging the greasy
spot on the pavement where the dead horse used to be".
(Posted to SPAM-L by John Mozena, although he stated
that he got it someplace else. :-)
Unfortunately we are not talking about a spam problem any more.
We are talking about a security specification. The discussions
on spam mailing lists don't have a lot of bearing. They were
not writing a standards specification.
I have been doing this stuff since before SPAM-L existed. so
don't try to pull rank here, you will lose that game.
The reason that Hadmut's attempted definitions do not fit the
traditional nomeclature of access control is that the point of
view is 180 degrees arround from the point of view where they
are written for.
The confusion that is created in the group is going to be repeated
each time someone tries to implement. Consider what you are going
to tell people to configure:
1) Enter a description of the use of the IP address
_ Allocated to a DHCP dynamic address pool
_ Allocated to a dialup modem bank
_ Allocated to a broadband modem connection
_ Statically allocated to an external service
2) Enter the domain name that your mail server announces itself
using in the HELO command:
3) Enter the IP address(s) of the mail server(s) used to send
outgoing mail from xyz.com:
Think in terms of the web page or wizard you would want to present
to the system administrator. Do you want to use terms like 'permitted'
or authorization here? do you want to have to explain them? do you
want to have to explain them in a vocabulary that is out of skew with
the terms used in the security world?
If you do it my way a lot of the problems disappear. For example the
whole confusion between CallerID style message header validation and
SPF style envelope validation. This is no longer part of the NORMATIVE
specification. Sure we give an INFORMATIONAL algorithm for interpretation
but that does not have to be updated to track the changing configurations
of the Internet.
We should not be arguing over how the receiver uses this information,
it is not relevant. A lot of that stuff is going to be proprietary.
It is appropriate for a server at the edge to verify HELO and MAIL FROM.
It is appropriate for an inner server or a client to verify the message
origin indication.
It also means that we can have two distinct descriptions here:
forwarder.com "If the IP address is 10.2.3.2 forwarder.com can
be held liable for the messages sent through it"
"forwarder.com is accredited by the association of
email freight forwarders"
company.com "If the IP address is 10.5.3.2 and the message FROM
is company.com the message is authentic and company.com
can be held liable"
"Accreditation of company.com"
Until we have mail servers that are configured to verify their
configuration before sending each piece of outgoing mail it is unlikely
that anyone is going to reject outright email that fails SPF validation.
instead they will attach a negative score and run the mail through the
spam filters.
Phill