On Jul 16, 2004, at 5:21 PM, Roy Badami wrote:
Currently MARID records (as defined by draft-ietf-marid-protocol-00)
and SPF records (as defined by draft-mengwong-spf-01) are not
distinguishable. Given they are broadly compatible, this isn't a
major problem, but they are not semantically equivalent since they
check different identifies: the PRA in the case of MARID and the MAIL
FROM
Technically, But draft-ietf-marid-protocol-00 doesn't specify which
identity to check. Using the records to check PRA is defined in
draft-ietf-marid-core-02. But yes, there is a semantic difference
here.
Add a new mechanism 'null' to MARID, the null (or no-op) mechanism....
I think you correctly point out that for most situations, domains
publishing records don't care, and what they publish to be checked
against PRA, they can accept that it will be used to check MAIL FROM in
older configurations. For those situations where they do care, your
'null' mechanism is a nice idea.
But the real question in my mind is, while I understand the semantic
difference from a purely technical point of view, I'm not sure that I
can find a practical difference. Specifically, I'm not sure I can find
a case where:
There is a domain that identifies at least one host that it permits to
be used as the PRA
but not as envelope MAIL FROM.
or
There is a domain that identifies at least one host that it does not
permit to be used as
PRA, but does permit as envelope MAIL FROM.
For simple mail, the envelope MAIL FROM and PRA are the same. So any
case must involve more complicated mail set ups: forwarding, lists, or
bulk mail.
On Jul 17, 2004, at 6:57 AM, Margaret Olson wrote:
Problems occur with domains where the MAIL-FROM matches the PRD in one
system (for example the mail sent by an ISP), and that domain has
published an SPF v1 record, and that domain is used as the PRD (2822
from) in another system with it's own error handler. In other words,
in domains that have an ISP for personal mail and at least one
outsourced service that sends specialized mail (for example a shopping
cart or a email service provider for marketing messages).
Margaret gives two examples, the first of which she declares to be "not
a problem", since it is solved by businesses having their own domain
name. I'm going to restate the second example to be sure I understand
it, and to see if it fits the test above:
mybikeshop.com normally sends it's mail via its ISP's servers at
bigisp.com, however, it sometimes sends bulk mailing to its customers
via bulkmailer.com. Hence, we see normal messages as:
SMTP client: mx.bigisp.com
envelope MAIL FROM: amy(_at_)mybikeshop(_dot_)com
header PRA: amy(_at_)mybikeshop(_dot_)com
and we see bulk messages:
SMTP client: mx.bulkmailer.com
envelope MAIL FROM:
bounce+mybikeshop(_dot_)com(_at_)bulkmailer(_dot_)com
header PRA: amy(_at_)mybikeshop(_dot_)com
So the records involved are the SPF records for bulkmailer.com and
mybikeshop.com. We'll take these in this order.
bulkmailer.com needs to publish a record that old, envelope MAIL FROM
checking SPF implementations will pass when seeing the second type of
e-mail. So it publishes:
bulkmailer.com. IN TXT "v=spf1 +a:mx.bulkmailer.com -all"
If this record is used by a newer implementation that checks PRA, this
almost certainly valid since bulkmailer.com could send its own mail
(where it is in the PRA) from this machine. Even if it didn't, it
administratively controls this machine, and is already accepting
accountability for it. Such a declaration doesn't result in a loss of
reputation or an opportunity for a spammer.
mybikeshop.com needs to publish a record that envelope MAIL FROM
checking SPF implementations will pass when seeing the first type of
mail, and newer implementations will pass with either. So it
publishes:
mybikeshop.com. IN TXT "v=spf1 +a:mx.bigisp.com +a:mx.bulkmailer.com
-all"
This record is slightly more liberal than the requirements. In
particular, implementations checking envelope MAIL FROM against this
record will Pass an envelope MAIL FROM with mybikeshop.com when coming
from mx.bulkmailer.com. Given that mybikeshop.com already trusts
bullkmailer.com to use its name as PRA on e-mail, it seems unlikely
that mybikeshop.com would be unwilling to trust that they could set up
the envelope MAIL FROM correctly.
So while this case again shows that there could be a difference on
purely technical grounds, (bulkmailer.com isn't expected to use
mybikeshop.com in envelope MAIL FROM) as a practical matter it fails
the tests: mybikeshop.com trusts bulkmailer.com with it's domain name
for PRA and loses nothing by trusting them with it for envelope MAIL
FROM, even if they agree not to use it that way. (Though I suspect the
vast majority of mybikeshop.com-s in the world don't even understand
the difference and happily grant the bulkmailers of the world the
rights to use the domain name in e-mail sent on their behalf in any way
the bullkmailer sees fit!)
To recap --
1) There is concern that since the proposed use of SPF format records
is changing from envelope MAIL FROM checking to PRA checking, that the
difference in semantics might cause problems for some domains: Older
implementations of SPF will use records intended for PRA against
envelope MAIL FROM; Newer implementations will use older records
intended for envelope MAIL FROM against PRA.
2) The 'null' mechanism is a very simple and clean solution to the
first of these to problems.
3) While one can construct cases that show the technical difference in
the semantics, I still cannot find one that demonstrates a practical
need for distinguishing a host between them.
Hence, I'm not convinced we need the 'null' mechanism, or two versions,
or scoping declarations in the record, or multiple records at different
DNS names (all proposed solutions I've reviewed to this issue), since
I'm not convinced the issue is real enough to warrant the change.
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_dot_)com