Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
On 6/30/2020 1:49 PM, Alessandro Vesely wrote: On Sat 27/Jun/2020 03:44:55 +0200 John Levine wrote: This makes me wonder how many mailing lists still don't add DKIM signatures. Lists at vger.kernel.org and savannah.nongnu.org are not signed. There are also some which don't seem to have found a way to deliver valid DKIM signatures, such as those at lists.sourceforge.net. Not all List Systems (MLM, MLS) have a transport system, so it is left for the outbound mail processor (mail router) to handle the signing for all outbound mail. That is how our MLS behaves. The MLS only needs to control the subscription and submissions process by checking the DMARC record for restrictive domains. Really no code change in MLS at all related to DKIM. Abandoned Legacy MLS many be a problem, but any operator who wishes to be part of the DKIM/DMARC era, needs to understand it needs some controls with subscription and submission checking. It doesn't need to worry about getting support for the abandoned MLS. He just needs to control the entry points like subscription and submission. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
On 6/30/20 10:49 AM, Alessandro Vesely wrote: > There are also some which don't seem to have found a way to deliver > valid DKIM signatures, such as those at lists.sourceforge.net. Yes; they seem to be signing with both sf.net and sourceforge.net, but neither signature verifies successfully. Wonder why. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
On Sat 27/Jun/2020 03:44:55 +0200 John Levine wrote: This makes me wonder how many mailing lists still don't add DKIM signatures. Lists at vger.kernel.org and savannah.nongnu.org are not signed. There are also some which don't seem to have found a way to deliver valid DKIM signatures, such as those at lists.sourceforge.net. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
You were partially right. Outlook allows me to pick columns, but I forgot that the feature was available. I don't see the feature on two web MUAs or two phone MUAs that I checked. Doug Foster -Original Message- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Alessandro Vesely Sent: Tuesday, June 30, 2020 4:52 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers On Mon 29/Jun/2020 15:01:07 +0200 Doug Foster wrote: > Very creative suggestion. We need some new ideas. > > However, I just checked my MUAs. All of them assume that "To" is > unimportant, so it is not displayed in the message list. "To" only appears > in the message view (including the Preview pane).Without more > visibility, it probably does not sufficiently solve the user interface need. > Which also suggests why I have not seen spammers try to manipulate > that field. Can't you select what fields to display in the folder view? The Sent folder must look boring if it only displays From:. How about catchall folders? Hm... I though all email clients featured customizable views nowadays. Thank you for replying Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
On 6/29/2020 9:01 AM, Doug Foster wrote:
Very creative suggestion. We need some new ideas.
However, I just checked my MUAs. All of them assume that "To" is
unimportant, so it is not displayed in the message list. "To" only appears
in the message view (including the Preview pane).Without more
visibility, it probably does not sufficiently solve the user interface need.
Which also suggests why I have not seen spammers try to manipulate that
field.
I have designed all my MUAs and I presumed all the 3rd party MUAs do
something similar with a "Message List" view (MLV).
Imeo, this would be one part of a "Recommended MUA Guide" to help
maximize user viewing security.
First, we have a limited space in what columns to show in a MLV. In
TUI (Text User Interface) display, you can correctly assume it will at
least 80 columns and optionally offer extended 132 columns is
supported by the terminal. With GUI, there is more flexibility.
Second, it is not that "To: is unimportant, the mail is mostly likely
targeted directly to you or to All for groupware environments, i.e. a
mailing list, NNTP newsgroups, local public or private
conferences/fora. The designer(s) can choose not to include a "To:"
column, or decide it is off by default. For GUI, the better ones will
offer a right click of the MLV table header or via some View Option to
manage the viewable MLV columns.
Third, our MUA, among others, offer this MLV as a quick way to tag
multiple messages to mark/unmark as read, delete, move, etc, and also
sort by column field(s).
Forth, our MUA, among others, also shows a Thread view which is
"Tree-View" display generated as a function of the Message-ID and
References: fields.
There are other display views for a MLV, for example, our MUA offers a
TOPIC view which is basically a thread view linked by the subject and
date fields or a flat table view with sorted subject/date columns. It
helps with the problem where a segment of a thread view is broken by a
"reply" not having a references id.
This illustrate the multiple TUI/GUI design considerations, allow me
to summaries what I have to deal with:
For a TUI view, the MLV is showing:
{Mail.Number}
{Mail.From}
{Mail.To}
{Mail.Subject}
and just to show you how limitations under 80 columns and 25 rows
standard terminal display:
Conference 0 - E-Mail (Internet & Local)
[ 1] Msg:63210 Fm:ANTONIO RICOTo:HECTOR SANTOS Sb:github wcsdk
[ 2] Msg:49893 Fm:secur...@bbt.no To:HECTOR SANTOS Sb:BB&T SECURITY
SERVICES
[ 3] Msg:49894 Fm:list-wildcat-be To:HECTOR SANTOS Sb:Re:
[list-wildcat-beta]
[ 4] Msg:49895 Fm:CNNEarningEdito To:HECTOR SANTOS Sb:Double Your
Income... I
[ 5] Msg:49896 Fm:list-wildcat-be To:HECTOR SANTOS Sb:Re:
[list-wildcat-beta]
[ 6] Msg:49897 Fm:list-wildcat-be To:HECTOR SANTOS Sb:RE:
[list-wildcat-beta]
[ 7] Msg:49898 Fm:list-wildcat-be To:HECTOR SANTOS
Sb:[list-wildcat-beta] RE:
[ 8] Msg:49899 Fm:list-wildcat-be To:HECTOR SANTOS Sb:RE:
[list-wildcat-beta]
[ 9] Msg:49900 Fm:ProjectMgmtTrai To:HECTOR SANTOS Sb:Project
Management Trai
[10] Msg:49901 Fm:list-wildcat-be To:HECTOR SANTOS Sb:Re:
[list-wildcat-beta]
[11] Msg:49902 Fm:Developers@wins To:HECTOR SANTOS Sb:[Developers] pxw
[12] Msg:49903 Fm:mrsshirlevine20 To:HECTOR SANTOS Sb:Donation of
Mrs. Shirle
[13] Msg:49904 Fm:mrsshirlevine20 To:HECTOR SANTOS Sb:Donation of
Mrs. Shirle
[14] Msg:49905 Fm:list-wildcat-be To:HECTOR SANTOS Sb:RE:
[list-wildcat-beta]
[15] Msg:49906 Fm:morris.cooper@l To:HECTOR SANTOS Sb:Indebted for
driving on
[16] Msg:49907 Fm:group.consultin To:HECTOR SANTOS Sb:MUTUAL OFFER
[17] Msg:49908 Fm:ad428352916@for To:HECTOR SANTOS Sb:Fwd: For Sale
by Owner
[18] Msg:49909 Fm:easyhrsoftware@ To:HECTOR SANTOS Sb:HR Software
[19] Msg:49910 Fm:sa...@toyska.co To:HECTOR SANTOS Sb:Canada Goose -
The Ulti
[20] Msg:49911 Fm:ad428352916@gin To:HECTOR SANTOS Sb:Reply: Plus
size fashio
[21] Msg:49912 Fm:incoming@interf To:HECTOR SANTOS Sb:You have new
fax, docum
[22] Msg:49913 Fm:FreedomGenerato To:HECTOR SANTOS Sb:Power
Companies Caught
[R]ead, [M]ark, [C]ontinue, [N]onstop, [Q]uit? []
yes, mucho spam!
Wit limited screen dimensions, you end up with truncated field
displays. That was the original display we had for TUI. Based on our
discussions, I will pencil in a change consideration to not show the
To: which will extend the FM:. I could put the date here too. But
again, we are limited.
For a Native GUI View, it borrowed similar to Windows Explorer display
views. The default columns are:
{mail.subject}
{mail.From}
{mail.to}
{mail.date}
For the HTML GUI view, the backend renders the following default columns:
Msg#
Date:
From:Subject:
To:
Replies (count)
So it is one 1 table row with a message item displayed like so:
++
|{mail.number}| {mail.from} | {mail.to} | {mail.References.count}|
|
Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
In article you write: >On Fri, Jun 26, 2020, at 9:44 PM, John Levine wrote: >> This makes me wonder how many mailing lists still don't add DKIM >> signatures. Unlike the header rewriting hacks, they don't affect the >> way recipients see or handle the mail in their inboxes. > >The HTTPbis list and Full Disclosure immediately come to mind. IIRC, >Bugtraq didn't use DKIM, either. Bugtraq was started in 1993 and is now dead so I'm not sure how useful an example it is. Don't know which httpbis list but the IETF signs all its mail and if W3C doesn't, they use Exim which is easily adjusted to do so. The question isn't whether everyone signs, clearly some don't. The question is how much of an imposition it would be to ask them to do so. Unless they're using incredibly ancient mail and list software, not much. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
This makes me wonder how many mailing lists still don't add DKIM signatures. Unlike the header rewriting hacks, they don't affect the way recipients see or handle the mail in their inboxes. DKIM signing would certainly make it easier for receivers but I'm hesitant to try and mandate it for intermediaries. Well, gee, it's easier than ARC signing which is what we're asking now. I am not opposed to asking list operators to make changes, so long as they are not changes that force their users to change the long standing way they use the lists. These days all of the MTAs and list managers I know can do DKIM signing, so it's not a lot to ask. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
On Fri, Jun 26, 2020 at 9:45 PM John Levine wrote: > In article <20200626032027.b7efa1bb5...@ary.qy> you write: > >In article < > caj4xoyecbh4ycofhzmv+a0336aifx55blvsdh-u21kkj+gr...@mail.gmail.com> you > write: > >>B) Specifying the specific Intermediary in the Intermediary Field. This > >>would indicate that the users domain recognizes that the user uses the > >>intermediary and by policy exempts this use even though it breaks both > DKIM > >>and SPF validation. The receiving domain would need to recognize some > >>potential risk of malicious modifications or additions to the message. > > > >Sounds like what I proposed several years ago: > > > >https://tools.ietf.org/html/draft-levine-dkim-conditional-03 > > Mike clarified that his suggestion is simpler in that the recipient > can recognize that intermediary however it wants, not necessarily with > a DKIM signature. > > This makes me wonder how many mailing lists still don't add DKIM > signatures. Unlike the header rewriting hacks, they don't affect the > way recipients see or handle the mail in their inboxes. > DKIM signing would certainly make it easier for receivers but I'm hesitant to try and mandate it for intermediaries. The 2nd signature from the originator is a good indicator and depending on which additional fields are signed should provide reasonable protection against replay attacks. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] An alternative proposal to the known intermediary problem
On Fri, Jun 26, 2020, at 9:44 PM, John Levine wrote: > This makes me wonder how many mailing lists still don't add DKIM > signatures. Unlike the header rewriting hacks, they don't affect the > way recipients see or handle the mail in their inboxes. The HTTPbis list and Full Disclosure immediately come to mind. IIRC, Bugtraq didn't use DKIM, either. Stan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Setting From: MLM, To: author, Bcc: subscribers
On Mon 29/Jun/2020 15:01:07 +0200 Doug Foster wrote: Very creative suggestion. We need some new ideas. However, I just checked my MUAs. All of them assume that "To" is unimportant, so it is not displayed in the message list. "To" only appears in the message view (including the Preview pane).Without more visibility, it probably does not sufficiently solve the user interface need. Which also suggests why I have not seen spammers try to manipulate that field. Can't you select what fields to display in the folder view? The Sent folder must look boring if it only displays From:. How about catchall folders? Hm... I though all email clients featured customizable views nowadays. Thank you for replying Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
