Andrew Newton wrote:
On Jul 31, 2004, at 5:18 AM, Michel Bouissou wrote:
I'm sure that it's what will happen. Any mail coming out from big
providers or forwarders will bear a "Resent-From:
<MAILER-DAEMON(_at_)big-provider(_dot_)com>"
and then PRA/Sender-ID will then show completely useless.
I'm not sure if this is meant to be an opinionated assumption or a
statement regarding a flaw in PRA.
If some providers force others to publish SPF records by rejecting mail
without them, then both normal and spoofing access to SPF records would
raise the loads on DNS. These records would likely be "open" records.
Eventually a solution of placing a Resent-From header into outbound mail
could be a defensive strategy as a means to "close" the record to curtail
DNS abuses. If not done in this manner, there would be massive support
calls, as normal mail practices would otherwise cease functioning. I
would regard this as an eventual consequences, where what may have seemed
to be a small percentage of list traffic, now becomes the norm. PRA
becomes little more than a channel identifier using a rather complex
method to authenticate it.
On Jul 31, 2004, at 11:59 AM, Douglas Otis wrote:
I meant to say <RFC2822_From : RFC2821_EHLO> could be called
Sender-ID. This would identify the sender with the channel, assuming
the EHLO domain was authenticated and was authorized. This would
stop spoofing, phishing and allow accreditation. It would not impact the
way mail is used, nor break anything. Unlike the current definition,
this could abate spam.
So do you now believe that a Sender-ID record at EHLO host name is more
desirable than an SRV record?
The SPF record would change to only require a list of EHLO domains, if to
limit the allowed use the RFC2821 MAIL FROM and RFC2822 From domains.
These lists could use a wildcards. If there were no record discovered,
then there would be no restriction. If there was a record, then only
these EHLO domains for the specific fields would be allowed.
The record could look something like "marid_1 rf=*.my-domain.com;"
CSV-CSA would remain an efficient means of publishing an MTA hostname
client authentication and authorization, that would also be difficult to
abuse. By visibly exposing an authenticated EHLO domain, together with
the From field, users would be able to recognize normal channels used by
various individuals making identity spoofing difficult, but adaptable.
Users could then easily white-list these identities and be wary of changes
in channel use. This would greatly reduce complexities of SPF, while
still allowing the same feature set, for those wishing to impose external
domain restrictions. From the perspective of the user, the results would
be extremely similar to the scenario described as a provider's defensive
strategy.
One major benefit to this approach would be the ability to accredit based
upon this <From:EHLO> (New Sender-ID) identity, as it would be the entity
granting access, and it would also indicate where a log could be obtained
to review any claims of abuse. This would also be far less disruptive to
mail use and practices and, of course, related software. It would also
allow a reduction in the amount of spam and increase network protections.
It would be a win-win-when solution. : )
-Doug