Stephen, I hope the DMARC List moderators/chairs recognized your
antagonistic "first strike" responses to concerned comments here. It
isn't helpful.
This is a long time issue and I have been there since day one, since
MARID when all these integrated design concepts and issues began. I
don't recall your early participation in this but there is deep
history in all this. But thats ok. Welcome to the problem!! :)
Generally people get involve when they begin to see something effect
them. It did with me in 2003 when the SORBIG infamous dual blitz (DoS
RBL sites, Accept/Bounce attack the receivers) came and SMTP
developers saw we finally needed to add something into our software to
help operators. Do you know what our first support answer was? To
enable their existing but optional SMTP feature:
[_] Validate Local Recipient
You see, when people switched from UUCP/SLIP/UUCICO hosting methods to
SMTP transports, the early versions do not have a RCPT TO validation
process. So all mail was accepted and it was your existing internal
import gateway that did the user delivery check. If not there, the
mail gateway created a bounce to be sent out. So the first support
fix for very concern SORBIG suffering ESPs, ISPS, and all domains, was
to tell them to enable the local user validate checks.
By doing this check at RCPT TO, you can potentially save 40% to 60%
DNS overhead, wasted processing of all new DNS-based email security
protocols. I have 11 years of consistent and persistent automated
daily statistics recorded here:
http://www.winserver.com/SpamStats
This has always been a basic client/server negotiated protocol
engineer "lookup" discovery problem.
For DKIM, the solution was outlined in 9+ years of IETF work which
does covers ALL client/servers situations. That was the goal. The
feasibility of this was a concern and it depended on who it was
applicable to.
But overall, it was about the dealing with the BAD, the GOOD and the
UGLY. Many administrators and list operators only wish to do deal
with the good. There is a long traditional to be "fail-safe", i.e
accept all mail and let the user decide. Thats been long understood
but it only serves one part of the market needs. Increasingly, the
need for deterministic methods at the system level, not at the user
level was becoming more apparent. Again, as a SOFTWARE DEVELOPER, you
have to cater to all market needs.
The IETF has to address two fundamental protocol engineering issues:
LAYER #1: DKIM signature authorization protocol, and
LAYER #2: DKIM signature trust/reputation protocol.
This was done in all the R&D, RFC work done. The threats, the
optimizations, the expected short term overheads and redundancy issues
were all considered. In the short term, you should expect a high
waste, high redundancy and network latency, performance issues with
higher NXDOMAIN lookup results and early migration recommended paths
of using relaxed Policies. But in the long term with higher expected
adoption, there would be some greater payoffs, efficacy, efficiency
realized, especially as the domains migrated and got their network in
order and began to switch over stronger policies.
This was ALL expected and it didn't begin with DKIM, it began with
SPF. It also had the same issues of scalability, network performance,
nxdomain, relaxed vs strong policies design concerns. But as expected
and it took years for domains, but many did finally switch their SPF
policy to the hardfail -ALL policy.
As it was predicted, we have the same dilemma with DKIM now. It is yet
another philosophical, wasteful discussion on the merits having strong
signature policies. This concept has long been resolved by the
market. It is a highly desirable feature and idea to be able to take
control of your domain again. As it was done with SPF, over time, the
private domains, the higher value domains, began to use SPF -ALL
policies, even the IETF is telling the world only their machines send
out @ietf.org related mail:
"v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56
ip4:64.170.98.0/24 ip6:2001:1890:126c::/56
ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64
ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64
ip4:72.167.123.204 -all"
As you can understand, you technically do not need DMARC to process
this SPF parameter and is highly inefficient with a high payload
overhead if DMARC told implementators not to process SPF or wait until
the DATA state is reaches in order to receive the 5322 payload
overhead to get the Author Domain DMARC policy first to only to see
if, for sure, the domain has a "p=reject."
Do you understand why the SUBMITTER protocol was invented for
SENDER-ID? Well, all these ideas apply because they all dealt with
the same kind of 5321 vs 5322 implementation issues. DMARC can have
a similar optimizer for SPF:
C: MAIL FROM:<[email protected]> dmarc=(p=reject; ruf=dmarc-ruf);
This could tell the OPTIMIZED RECEIVER thats ok to reject before DATA
is reached, even though the SPF -ALL already tells you its ok. The
"DMARC friendly" integrated difference is that it can tell the
receiver to collect and send reports.
Etc, etc, etc. The whole point, the IETF has long lost time in the
entire DKIM+POLICY framework and its about time it gets serious about
it (again). Only with IETF endorsement will it begin to get wider
adoption within the market. The IETF job's is to enable it. Let them
the implementations and deployments learn how to manage the DNS
records and eventually come back and write a BCP for it or come up
with a better DNS query concept.
Where do you end up with all this? When do you actually begin to
explore the proposed solutions that are technically sound? There is
software change cost. But the framework is sound. Have you tried
ADSP/ATPS or DMARC with ATPS updated for DMARC instead?
--
HLS
On 6/7/2014 11:20 AM, Stephen J. Turnbull wrote:
Vlatko Salaj writes:
> > What I [== stephen] gather from Vlatko's posts is that there is a
> > use case where an entity (eg, a small business; called "ENTITY"
> > below) wants its own domain (called "OWNDOM" below) referenced in
> > correspondence, but prefers not to maintain a single presence
> > (even as a VPS) on the Internet.
>
> nope.
OK, so it's not. The solutions I propose still work if you have a
physical presence but *choose* not to use it to send mail, and Franck
Martin says that ESPs are open to cooperation as required by a subset
of those solutions.
The only difference is that there *may* be issues of spoofing or
losing mail that happens to be delivered directly from your personal
MTA. I didn't want to make the effort to be *sure* so I chose a
setting where it wasn't an issue.
> i want DMARC to upgrade itself to be able to respect that.
Please stop writing things like that. It's either a semantic null or
a troll. Somebody has to do the work, RFCs don't write themselves.
If you can't write a whole draft, at least write an outline of the
parts of the protocol your idea requires.
> http://www.ietf.org/mail-archive/web/dmarc/current/msg00813.html
Now that's more like it!
Unfortunately there's no protocol in there, you leave it implicit. :-(
And you must have some new (undefined) forms of "alignment", as mail
"From: [email protected]" can never satisfy DMARC identity
alignment with yahoo.com credentials. Eg, what is being aligned" in
(2)? Your "example" isn't a conforming DMARC record, in fact it even
usurps existing protocol (that's a no-no, even if a spec is only at
draft stage; it's not that hard to choose a new name, and adjust
nomenclature whan publishing a new draft). Finally, the post is full
of minor inaccuracies, like writing "Sender-ID instead of SPF" when
Sender-ID depends on SPF.
Unfortunately, AFAICS it doesn't address my needs (ie, MLMs), so I
doubt I will be able to find time to work through it and figure out
what you're suggesting in concrete terms.
> also, it's easier than VBR, ATPS, TPA, TPA-Label, and moves
> trouble of authorizing legitimate email from receivers'
> error-prone, DMARC-policy-disrespecting, essential
> whitelisting to domain-owner's control, where it should be.
I disagree with "where it should be". The receiver has ultimate say
on what messages it will accept, whether for relay to third parties or
local delivery (or even "silent discard").
> what u r proposing, Stephen, instead, is not at all trivial or easy
> to implement,
Huh? Define "trivial" and "easy." Technically speaking, AFAICS DKIM
signing in the MUA is a SMOP (and in fact it can easily be done
outside of the MUA but on the same host as the MUA by a separate
application), many users with a personal domain can handle setting
DMARC and DKIM resources, and I see no reason why ESPs would alter the
signed portion of a message.
If the user *can't* handle setting those resources or your preferred
ESP insists on corrupting your messages, asking the ESP to handle all
of SPF, DKIM, and DMARC for mail purporting to be from your domain is
an obvious solution, and if the ESP goes rogue or has a security
breach compromising your private keys, you delete the authorizing
resources from your DNS.
> nor does it solve more than just my special use case.
So what? It's easy to implement and solves a use case that must be
fairly common out there. Get real, man -- you're bitching *because*
it solves your use case?!
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
