Say DMARC isn't going away and lists just deal with it

[jrlevine]

Redid end of interop section per discussion with AD

[alevesely]

The ending sentence sounds overly gloomy. ARC is nascent was better than there is little reason to believe that any future methods will be more successful.

[jrlevine]

It sounded better but it wasn’t true. ARC is a dead end which is going nowhere. Maybe DKIM2 will be better but I don’t want anyone to think, OK, we will just stall DMARC until everyone uses DKIM2.

[alevesely]

I disagree. ARC just misses a protocol to verify forwarding setups, which could be implemented with minimal software. DKIM2 requires more complex changes and will be available at a later stage.

I like your saying that DMARC is here whether you like it or not, but holding that is will stall in such state for ever is not fair, and corroborates the misguided definition in the upcoming SMTP standard.

[jrlevine]

No large mail system will do any more with ARC than they do now. That's what they've told me. There is no way that a mail provider with billions of unsophisticated users can "verify forwarding setups".

[alevesely]

Users who manage to subscribe with COI are not so unsophisticated. The rest, those who subscribe to newsletters which, methinks, pay for private whitelistings, need no special DMARC settings.

I talked to Wei about a possible thing and he found it too complicated, similar to your That's what they've told me. Yet, there must be something like that which works, and it's not so difficult to implement... I hope this can be discussed on the DMARC list, when the current docs are AUTH48.

[mskucherawy]

I hope this can be discussed on the DMARC list, when the current docs are AUTH48.

Except in very rare situations AUTH48 is not an opportunity to revisit this discussion. It's for reviewing changes proposed by the RFC Editor prior to issuance of the RFC.

[alevesely]

I mentioned AUTH48 as a way to say that the current documents are good to go, and therefore the WG has time to discuss other things. In particular, a protocol whereby receivers can (automatically) manage their customers' subscriptions (mailing lists with COE and dot-forward recipes) by syncing with senders. That would result in a per-recipient white list of <ARC-signer, List-ID> pairs.

Such a discussion won't affect the current documents. We cannot freeze DMARCbis until ARC is ready for mass deployment, so the current documents are to be published as an incomplete solution. If the WG won't be shut down right after publication, that is.

[jrlevine]

Large mail providers have repeatedly told us that per-user whitelists do not scale. There is no possibility whatsoever that they will do that. I do not understand the point of repeatedly making a proposal that will not work and will not be implemented.

[alevesely]

I'm unable to understand that point. Large providers maintain reputation systems, which are only effective if they cover a majority of the world's MTAs. Per-user, they maintain all the IMAP stuff, plus lists of contacts, list of devices, ad preferences and various other options. But not a whitelist!? Why on Earth? A simple estimate says that storage and power needs would be negligible compared to the rest, while required customer support would tend to zero if the protocol is well designed.

I hope you can grasp why I don't believe per-user whitelists don't scale. Could large mail providers (or you) tell us (once more) why that wouldn't scale, please?

[abrotman]

You may want to confirm you're talking about the same kind of white/exemption lists. I could see about four different lists being applied at some point in this discussion.