--Jon Kyme <jrk(_at_)merseymail(_dot_)com> wrote:
> I can't see any sensible way of doing this without the publisher being
> able to indicate the intended applicability of the record.
Hey John,
I think you said that before, but I posted my "suggested workarounds" and
nobody has responded to say why those wouldn't work. Do you have some
situations (real or hypothetical) that might demonstrate why this extra
"applicability info" would be needed, and why the workarounds I posted
wouldn't work?
I get the feeling that people are just replying "No it won't work" and
not
taking the time to read the suggestions I have made or respond to them.
So
far I haven't seen any specific reasons why the single-record-per-domain
wouldn't work, or why the workarounds suggested wouldn't work. This makes
me a little frustrated.
--Jon Kyme <jrk(_at_)merseymail(_dot_)com> wrote:
Yes, I appreciate that.
Thanks for taking the time to reply.
You propose that the default should be "all contexts".
"Context workaround 1" seems to be a requirement only to make the record
wide (enough).
I don't understand "workaround 2". It doesn't seem to add anything.
You are correct: Workaround 1 is "Make the policy (MTA list) wide enough
to accomodate all permitted behavior using that name"
Workaround 2 was just a long way of saying "If you can't do 1. then just
use different domain names for each context". This seems to me to be the
only 100% reliable way to really control the recipient's behavior.
i.e. if you use the same domain for MAIL FROM: and From:/Sender: then the
policy has to match up to either usage... but if you use a different domain
for MAIL FROM: than for From:/Sender: then that is the perfect vehicle for
stating two different policies (if needed).
"Each context stands alone" seems to me to be what a recipient MUST do. It
seems clear that I (as a recipient) MUST NOT pick a domain from 2822 From
and evaluate the message as if I'd got the domain from 2821 MAIL FROM.
Right. I think among the emailers who might be inconvenienced by the "all
contexts" policy, many of them are already using different domain names in
different contexts anyway, so as long as the recipient doesn't apply the
checks in the wrong context they wouldn't be affected. 2. just states that
"use two different domains" is a workaround for forcing contexts.
"Special cases modifiers" is, of course what I, and others, have
suggested.
So, pending me figuring out what "workaround 2" means, and pending us
deciding what the default should be, what you propose is exactly
equivalent to what was suggested.
Excellent. I am not quite sure that special case modifiers like no2822 or
no2821 would really be needed or used, but I would much prefer that path
than splitting up the policy into two records and forcing the majority of
users to publish both.
I think the important thing to be clear on is what the MARID record
actually is. One view is that it's a publishers statement of what
legitimate claims for the domain are allowed. Obviously, a little language
should be as little as possible, but it also needs needs to be powerful
enough to satisfy requirements. A publisher should be able to say what
they mean, explicitly. The advantage I see with "modifiers" over
"widening" is that it is more explicit. There's a small penalty in
parsing I guess.
Agreed. Just going by the charter, it seems like we want a "specification
of MTAs" (not necessarily a "list of MTAs" but something that could be
expanded to one, such as "accept MTA with confirmed reverse DNS PTR
*.example.com".
Some of the input documents (most notably SPF) go a bit further and say
things like "pass, fail, unknown, softfail" and have macros and explanatory
text to include in the bounce message, etc. Some of that may make it into
the final proposal and some may not... but the main idea really is still
"Is this MTA among those authorized to use my domain name"
Thanks again for the reply.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>