Dear Tony,
See comments inline:
On May 29, 2014, at 8:11 PM, Tony Hansen <t...@att.com> wrote:
> On 5/28/14, 6:46 PM, Barry Leiba wrote:
>> Anything that requires mailing list software to change won't work.
>
> I'm going to push back on this statement. I think we keep getting stuck on
> the mantra that "the mailing list software won't change". However, the
> majority of the mailing list software packages that are out there now DO
> generate proper List-* headers. It took some time, and it may not be 100%
> coverage, but by gosh and by golly, most of them do so and do it correctly.
I agree with Barry. It is not just getting tens of thousands of mailing-lists
updated into something that offers what is surely going to be a substandard
user interface. This also means ensuring the added list headers allow selecting
a particular participant in a straight forward manner. And that this selection
also operates in conjunction with MUAs. There is a sizable variation in this
regard, many of which will not facilitate this ability.
The next question that needs to be considered is the timeframe for such
migration. How many years is reasonable?
Secondly, what can be done to help facilitate various informal services to
permit them to be effective at acting on behalf of their clients while still
ensuring the From header field contains an identity the eventual recipient will
recognize? It seems that in order to be able to do this, a way to make
exceptions for Sender header fields is needed as well. If making exceptions for
Sender header fields can be accommodated, then simply make this exception for
List-ID headers too.
Any effort at arranging domain alignments will be shuffling around where people
must look to understand who substantially originated the content. Keeping
these changes to a minimum would be ideal. After all, these changes will
create a fair amount of confusion for recipients, where they then become
vulnerable to a whole new range of deceptions. As it is now, most have already
begun to ignore DMARC assertions placed against user accounts which then
degrades even modest protections this may have initially offered.
Perhaps you might also consider:
https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly
I know of several other professional services sending email on behalf of their
clients. It seems these situations also run afoul of this rather simplistic
DMARC approach.
> Why? There were a few things: 1) a well defined spec about what change was
> desired, AND 2a) there was perceived benefit to adding those headers, or 2b)
> there was perceived harm in not adding those headers.
Hmmm. Perhaps we could call this new header "Sender". ;^)
>> If mailing list software is changed, the right answer is for the mailing
>> list to re-sign the message.
>
> I think this is exactly the correct solution for mailing lists to pursue.
> This is an excellent start of a spec for what mailing lists should be doing
> in a world where systems are using DKIM and SPF, and more systems are
> expecting such mail to pass validation. (A post-DMARC world, if you will.)
How many people have problems with mailing-lists? After all, problematic lists
fade away rather quickly.
The real issue was caused by millions of users accounts being compromised. The
providers that even played a small role in that problem should contribute to
what should also be an expedient solution.
The described changes to lists and many many other services will never offer an
expedient solution for several very difficult and important reasons.
Mailing-lists have not caused this problem, and yet the same ESPs are expecting
mailing-lists and the like to handle a major portion of the change. This change
is to permit From header field alignment with the source or a replay-able
signed message fragment. This rather dramatic change moves email a large
distance into becoming a far less versatile peer-to-peer protocol. Perhaps it
would be simpler to move SMTP to historic and adopt use of XMPP instead? After
all, that service already offers the concept of federated services and does not
offer any mailing list feature at this time. After all, it is hard to get ad
impressions shipping around signed messages. ;^P
> There may be alternative solutions that are less optimal that will also get
> mailing list messages delivered more reliably. (For example, delete all DKIM
> signatures and force the From: header to use the originator's name in the
> comment but with the mailing list address instead of the originator's
> address. It works, but isn't pretty.) It might be worth doing some
> investigation of those alternatives, and showing their advantages and
> disadvantages.
I have setup and run systems that tracked email from several very large ISPs of
all used IPv4 addresses. Taking in the entire inbound traffic and comparing it
to what was hitting various spam-traps was done on a moderate server producing
updates for the entire dataset in less than 15 minutes (often in less than 5).
While this was all done using mostly C code, it was rather small and extremely
efficient. Even so, this could have been done much more efficiently for
domains using Judy techniques, instead of IP addresses, especially IPv6
addresses. In addition, today's servers have become much faster. A good guess
would be corrective information can be produced using two DNS servers in
conjunction with two log aggregation servers. The use of two is for
redundancy. DNS offers low latency and very good edge caching.
Doing this by domain makes the problem much easier. Even then, the actual
domain alignment problems only comprise a very small sub-portion of the email
stream. The systems needed to manage this would also be fairly small, nor would
this require operators to learn a new language. :^)
The sender information necessary to overcome difficulties would be deployed by
the same entities demanding that email be handled differently. This only seems
fair.
There are some very real benefits by handling the problem in this manner. This
requires senders to actually monitor their DMARC and user web portal feedback.
Gasp. At least their support staff would have fewer angry complaints. After
doing this, they'll discover two important pieces of information that receivers
are unable to divine. Which sources represent rogue servers, and which appear
to be legitimately handling their users messages. What is left and is still
hitting their spam traps are likely compromised customers. This would offer
their customers better protection from spoofing permitted by loss of account
credentials and exposed messages and contact lists. Don't think for one minute
authorizing responsible domains means this will permit a torrent of abuse. The
effected domain is still able to just their authorization and shut done a
source in minutes.
> Mailing lists have an expectation of being able to get their mail delivered.
> That is no longer the case. The benefit of them making changes is that their
> messages will get delivered more reliably. The harm in not making changes is
> that their service will continue to be unreliable.
>
> But clear specs detailing what they CAN do and SHOULD do is the starting
> point.
>
>> That doesn't help the DMARC situation
>> now, but DMARC could be given other options once that happens.
>
> I agree completely that a change to DMARC is needed in conjunction with
> having clear ML specs.
May I recommend:
http://tools.ietf.org/html/draft-otis-tpa-label
Saying that it would be too hard is simply being lazy. It can also be
implemented fairly quickly, as this impacts those actually wanting this change.
Regards,
Douglas Otis
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
