"Alan DeKok" <aland(_at_)ox(_dot_)org> wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and
are spam: the recipient may choose to blacklist the domain.
I would restrict this to the EHLO domain. Using the MAIL FROM is making
an assumption of the integrity of the mail channel providing the
message.
Perhaps you didn't read the sentence you quoted. I explicitly
stated that the message passed DNS checks, and there is therefore NO
need to make assumptions about the integrity of the mail channel
providing the message.
A DNS check that obtains a list of addresses for a mailbox-domain, MUST
assume channel integrity when holding the apparent originator of the
message accountable. A mailbox-domain administrator may delegate mail
services to many disparate sending domains which may also be shared with
many other mailbox-domains. Publishing an SPF record does not include an
implied acceptance of accountability for these other sending domains or
the receiving domains within the recipient's realm.
Due to forwarding issues, expect many lists to be left "open" to allow
other unknown domains to forward messages. It is unfortunate, with the
SPF draft, the expressed MTA/mailbox-domain relationship is used to also
authorize the sending MTA. This means an "open" relationship will likely
invite a problem the SPF record hoped to prevent. Complex macros aimed at
rediscovering the actual sending MTA or, in the case of Sender-ID, the PRA
algorithm used to indirectly resolve the sending MTA where the RFC2822
From had been superceded, can simply be replaced by authenticating the MTA
EHLO.
There are clearly two steps needed, but these two steps have been
collapsed into a one very broken step with SPF or Sender-ID.
Step 1: Authenticate the MTA EHLO name.
Step 2: Compare the mailbox-domain/EHLO list to this name.
If spam is detected at the MTA, the EHLO name is held accountable.
By having this second step, confusion regarding which entity must be held
accountable is removed and safely allows any level of restriction to be
placed upon either the MAIL FROM or the From mailbox domains. By making
the authenticated EHLO domain visible within the MUA and allowing a few
institutions to publish a comprehensive rather than nominal
mailbox-domain/EHLO list as an exceptional restriction, will provide
superior consumer protection than possible with either SPF or Sender-ID.
In the scenario I described, by *definition*, the mail channel has been
verified to have integrity, so far as the RFC 2821 headers go.
It is not a trivial matter defending a reputation service. Listing a name
has potentially greater impact than an IP address. One can not defend
assumptions of accountable entities by suggesting the mail channel is
"defined" to have integrity. Nor is it reasonable for those seeking to
have their mail accepted to be held accountable for the actions of others.
SPF with "open" lists is seriously flawed, to say nothing about other
security issues. Anyone sharing a domain and publishing an "open" list is
susceptible to being spoofed. Because of the collapsing of the MTA
authorization with the domain relationships and allowances for "open"
lists, this actually invites spoofing. While listing "nominal" outbound
servers may be useful for "coloring" the mail, these mailbox domains MUST
NOT be held accountable for any abuse that may occur.
Please address that issue. Repeating the claim that a blacklist is
based on "assumptions" when I explicitly described a scenario where it
could be based on verifiable information is... not nice.
Listing a name and blocking their mail because you don't care which entity
actually caused the message to be sent is also... not nice.
There is naturally a reasonably strong authentication of the IP
address through transport protocol interaction.
Yes, you've said that many, many times. I understand that's your
position. I'm trying to get you to understand my position.
Those checks with respect to MAIL FROM and even the more extreme From
with Sender-ID, still assumes the mail channel is secure.
For Sender-Id, maybe. For MAIL FROM checks, absolutely not.
Security != authentication. You can authenticate someone in an
insecure system.
MAIL FROM checks work in an insecure mail channel. They *don't*
interact well with ".forward" systems, but that's an authentication
issue, not a security issue.
What entity should be held accountable? The entity authenticated as
sending the mail, or the mailbox-domain that authorized the mail to be
sent? Obtaining an authorization is not the same as authentication of the
acting entity.
In fact, MAIL FROM checks use the source IP address (which you claim
is the only secure/verifiable entity) to answer the question "is this
IP permitted to use this domain name in MAIL FROM?" If we put
additional conflicts with ".forward" systems aside for a moment, then
MAIL FROM and EHLO based checks are identical in security.
These checks are not the same. You are devising a system that requires
mailbox-domains authorize other domains to send their mail. Those
actually sending the mail can be authenticated as performing this
directly. Simply authorizing a domain does not imply they accept
accountability for these sending domains. If the sending MTA EHLO name is
authenticated and authorized by the EHLO domain, then it does not matter
what mailbox-domain is sent, this EHLO entity can be safely held
accountable for the MTA actions. If there is a problem, only this entity
can take immediate action or provide logs in the event of a crime.
Shared services means shared accountability. If the recipient is
unable to distinguish between a "good" party on a shared MTA and a
"bad" party, then by definition, both parties fall into the same
classification.
Sharing an MTA is a highly effective method used by ISPs to abate abuse.
Reserve painting this technique with such a broad brush.
I'm not. I'm talking about what information is out there, and what
decisions can possibly be made, independent of any technical proposal.
If someone can't tell the difference between two things, then it
MUST treat the two things as identical.
But these things can be identified by an authenticated EHLO name. They
MUST NOT be treated as identical.
This is a well-known concept, and based solely on the available
information. If you choose to disagree with this, that's your perogative,
but it means that any system you come up with will be based on using
information which is unavailable to anyone.
SPF is proposing to add information, but then uses this information
inappropreiately. CSV and MPR attempt to add information and use this
information to establish accurate accountability. There is a difference
and anyone can use this information.
Holding those unable to take immediate corrective action accountable
will cause a most unwelcome backlash.
This is a political response to a technical problem: the recipients
cannot technically distinguish between two parties, and therefore
treats both the same. If one party doesn't like it, the solution
isn't political, it's technical: give the recipient additional
information which lets him distinguish the two parties.
That is what CSV does. It allows a reputation service to distinguish
those directly responsible without any assumptions of the mail channel
integrity.
The party that must be held accountable is the entity administrating
policies of the MTA. That party is only identified by an
authenticated EHLO domain or the IP address.
And other parties using that MTA will, by definition, get associated
with the reputation of that MTA. This is what you call "a broad brush".
A reputation service spends most of their efforts ensuring information.
Using the IP address makes this process rather straight forward. Using an
authenticated EHLO name follows the same model and directly identifies
those sending the messages. To suggest that because the EHLO domain was
not considered, means a reputation service can safely hold entities
accountable for the action of others will not have much sway. Again, this
is not a trivial matter.
-Doug