"Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org> writes:
I find it difficult to imagine the licensing terms to be reasonable for
most. See:
I agree. From the research that I have done, it appears that the
SenderID license is incompatible with several important free software
packages (exim, postfix, spamassassin, bogofilter, etc.).
As far as I'm concerned, this makes the PRA a non-starter. Even if
the PRA RFC makes it past the working group last call, I see very
little chance that it would make it through the general IETF last
call.
I think that Microsoft's failure to come up with an acceptable license
has created a very unfortunate waste of time for this working group.
An alternative with the _same_ feature set can be found as follows:
1) Authenticate and verify the authorization of the EHLO domain with
CSV.
2) To restrict the RFC 2822 From domain, list all acceptable EHLO
domains
for From domain allowed in a MARID TXT record.
Yes, this general idea has been suggested many times by many people,
including me near the beginning of the on the SPF lists and PHB during
the interim meeting. I'm sure I'm not the first, nor will you be the
last to see this obvious idea.
So, the one I-D with the PRA algorithm could be replaced with:
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt
This has a problem with scaling. As a means to reduce the information and
to simplify publishing and support, use the CSV authorized and
authenticated name for the channel, rather than repeating this address
information.
CSV provides a means for accreditation to be related exclusively to the
polices of the domain sending the mail. This domain must be watching
their logs to detect SMTP errors. If they see too many errors, these must
be investigated further and matched against the abuse@ reports. The
holder of the log, as denoted by the EHLO response, is the gatekeeper for
the mail sent. They have the greatest effect in blocking abuse.
Build upon CSV, where mail domain permission records do not need to
include any IP address. As example, if a record wishes to restrict the
RFC 2821 MAIL FROM and RFC 2822 From for *(_at_)big(_dot_)bank(_dot_)com to be
emitted by
SMTP servers offering the EHLO mx1.big.isp.com mx2.big.isp.com and
java.ads-r-us.com ...
These records could be something like:
"Marid_1 rf=*.big.isp.com, *.ads-r-us.com;"
This record puts a restriction on both the RFC2822 From and the return
path (RFC2821 MAIL FROM). If to just to limit the MAIL FROM, then the
text may be:
"Marid_1 r=*.big.isp.com, *.ads-r-us.com;"
If the identity of the sender includes a display something like-
From: fred(_at_)some-domain(_dot_)com <mx1.big-isp.com.>
If the ehlo domain did not offer CSV records, then the it could be:
From: fred(_at_)some-domain(_dot_)com <mx1.big-isp.com!>
This would offer a means for people to recognize the identity of the
sender by both their return address and their channel identifier. If
there is a crime, then the channel identifier becomes the place to look
for the logs.
If big.bank.com puts a restriction on their From field, one would not
expect them to be sending from a list server with this domain. Even
without the restriction, the user would be able to see if they were
talking to someone on the same channel.
This would allow the same methods for filtering, with Sender-ID. Assume
that most major ISPs would have reacted by putting Resent-From: headers
into outgoing mail to isolate thier customers from the problems Sender-ID
cause. The EHLO domain places the same role. It is already being sent.
CSV simply fixes the problem discovered with STMP EHLO domain
authentication.
For those domains that prevent abuse, but don't wish to restrict the From
address for their domain, then only the CSV SRV records are needed for
this MAIL-ID to be useable and beneficial.
-Doug