to the new address. (You presumably already seen the
announcement of your auto-subscription to the new address.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
over there.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
applicable to this list. They are
the same as you had so much trouble with, previously.
Then please consider unsubscribing, since restraint within the bounds of
professional behavior appears to (continue to) be absent from your
repertoire.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
offers no actual value, is about as
practical as any standards issue can get.
Protocol complexity matters, especially for features that have no
immediate use.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates
syntactic and semantic
aspects of the changes that are being signaled.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
internal to the DKIM module. the
former merely requires a new table entry.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
natural, existing point for going to a different protocol.
Different protocol? Yes. Current DKIM does not require support for
unrecognized tags, beyond the initial set. You want to require support
for additional tags. That's a fundamental change; so it isn't 'DKIM'.
It's somet
likes it or doesn't.
That is there are no contingent behaviors in the exchange.
In a unilateral activity like DKIM, the mere presence of the usage
"featurex=..." serves to flag that featurex is used. There is no
incremental benefit into moving the flag elsehwere.
d/
--
Dave Crock
) have no dependency on the email
transport mechanism.
In fact, you've tripped into the core debate that originally triggered
the parallel, /competing/ efforts that produced ESMTP and MIME.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
SMTP?
Which is to day, thanks for demonstrating my point: the 'version' flag
is implicit with the features that are added. If they are present, you
have the 'newer' version.
These are not 'version' flags. They are feature indicators.
d/
--
Dave Crocker
Brandenburg InternetWork
technically has worked to avoid learning any lessons from this disparity...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 2/8/2018 4:42 PM, Michael Thomas wrote:
Besides if you wanted to go from DKIM to EKIM, you'd be opening
pandora's box imo.
The pandora's box is creating an incompatible new version. All the rest
is just engineering and operations tradeoffs.
d/
--
Dave Crocker
Brandenburg
e = 1*ftext
NEW:
field-name = 1*ftext
; case insensitive, per sections 2.2 and 3.6
or somesuch.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
-level switching versus
low-level, and the long-term costs of transition mechanisms.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ing at least back to RFC 733. Violation of 'intent' is the
criterion for an RFC erratum.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that fails if a verifier
can't handle it.
Change to basic semantics of the protocol. Hence, new protocol.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 2/8/2018 9:45 AM, John R. Levine wrote:
Huh? v=1 code doesn't know what the new features would be.
Re-read what I wrote.
The code that knows to dispatch to v=2 can, just as easily, parse for
the strings associated with the new features.
d/
--
Dave Crocker
Brandenburg InternetWorking
invalid, which isn't
ideal but isn't wrong.
the code that tests for the v= parameter could, just as easily, check
for the presence of the new features.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according
ignatures
Publication Date: September 2011
Author(s) : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
Category: DRAFT STANDARD
Source : Domain Keys Identified Mail
Area: Security
Stream : IETF
Verifying Party : IESG
--
Dav
n. As you note, a new header-field would be
appropriate here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
cross all technical cultures, experiential sets, and
protocol layers.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
the followup.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
. Send an erratum, we'll probably accept it as
hold for update.
In RFC 6376, note Section 3.2 on tag lists. The ABNF shows no
sensitivity to ordering. (The linkage to DKIM-Signature is Section 3.5,
first paragraph.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
of a message and even its authorship.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 12/5/2017 1:33 PM, Steve Atkins wrote:
It's a DMARC issue rather than a DKIM one.
How is it a DMARC issue?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
this distraction. You are now returned to
matters of substance...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
er, the ABNF specifies %76 which is the letter "v", not the letter
"k". The correct value is %x6b.
oops.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
b [FWS] "=" [FWS] key-k-tag-type
Notes
-
The key-k-tag should (presumably) start with the letter "k" to match the other key-LETTER-tag definitions and
to match the "k=" heading. However, the ABNF specifies %76 which is the letter "v", not the lette
em cleaner to me.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
e tag-value is empty/omitted.
Hitting 'obsolete' RFC5322 syntax doesn't bother me all that much, given
that there is now a long history of non-enforcement; the constructs were
never seriously deprecated.
But the proposed change does seem cleaner to me.
d/
--
Dave Crocker
Brandenburg Inte
C5322 syntax doesn't bother me all that much, given
that there is now a long history of non-enforcement; the constructs were
never seriously deprecated.
But the proposed change does seem cleaner to me.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
don't think the difference matters,
in this case, in terms of IETF process or actions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
st
folk know what it is and is not useful form.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
e
considerably more crisp.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, punctuation, or syntax error that does not
affect the technical meaning
The current error has technical import, since we are talking about a
broken validation.
So, I'm not at all clear that this qualifies as only an 'Editorial' error.
Mumble.
d/
--
Dave Crocker
G'day.
Looking for a community determination, here: The DKIM spec's examples
in A.2 and A.3 do not explicitly claim to be related to each other.
However they do contain the same message, so that assuming a
relationship seems pretty reasonable.
As such, calling the point raised in this
Am I missing it?
But basically, yeah, this looks to me like something needing to be fixed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
;. That DKIM might have other benefits is nice, and might be added
benefits, they weren't the issue that was raised.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc
ary of private keys to be associated with the
domain name. So assigning one solely for use by a third-party -- and
deciding when to terminate it -- is convenient and carries no effect on
other uses.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
of algorithm and
key-length, it needs to be asserted as an operational convention, not in
the base protocol
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
lists, to make sure that everyone there
sees this. But please post any followups to the SMTP list.)
Thanks!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
, perhaps.
However we could develop a referential norm, independent of that, and
then call for its use whenever docs are modified. Something like the
email header naming convention would make sense.
Hence:
Signature.v =
Key.h =
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, but sure, why not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that. It means
that it has no community traction. ADSP more than qualifies on the
pragmatics of failure.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
/
Original Message
Subject: Request to move RFC 5617 (ADSP) to Historic
Date: Wed, 11 Sep 2013 16:09:14 -0700
From: Dave Crocker dcroc...@bbiw.net
Organization: Brandenburg InternetWorking
To: Barry Leiba barryle...@computer.org, Pete Resnick
resn...@episteme-software.com
Folks
relevant to this
thread, nor the first at all within IETF participation guidelines.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 7/11/2013 12:48 PM, rfc-edi...@rfc-editor.org wrote:
RFC 6376 has been elevated to Internet Standard.
cool. congrats to us all.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
On 6/20/2013 10:00 AM, Jon Callas wrote:
It has many potential uses, but within DKIM itself, it's an expansion socket.
I tend to characterize it as an opaque cookie.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list
in the DKIM d= field, or at
least have an organizational domain match (that is, match at the name
portion that was delegated by a registry.
Oh, wait. That's DMARC.
See? It's possible.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
that a minor point, for the kind of question
being asked here.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
different views. None of the
alternatives was in the spec and therefore none were standardized.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 7/23/2012 8:20 AM, Murray S. Kucherawy wrote:
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net
mailto:d...@dcrocker.net wrote:
Here are two small tweaks that might correct things:
y This domain is testing DKIM. Verifiers MUST NOT treat
messages
wish to track and report testing mode results to
assist the Signer.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Maturing DMARC implementations through an interoperability event...
At the end of January, the DMARC (Domain-based Message Authentication,
Reporting Conformance) specification was publicly announced with
extensive media coverage, blog posts and discussion. Since that time
various folk have
+1
/d
--
Dave Crocker
bbiw.net
-Original Message-
From: Barry Leiba barryle...@computer.org
To: RFC Errata System rfc-edi...@rfc-editor.org
Cc: dcroc...@bbiw.net dcroc...@bbiw.net, tony+dki...@maillennium.att.com
tony+dki...@maillennium.att.com, m...@cloudmark.com m
raises a small question of needing notes to the editor advising hands off for
such segments.
/d
--
Dave Crocker
bbiw.net
-Original Message-
From: Barry Leiba barryle...@computer.org
To: Barry Leiba barryle...@computer.org
Cc: RFC Errata System rfc-edi...@rfc-editor.org, dcroc
is that the existing notation for communicating inline to the RFC
editor is sufficient. That is, I'd expect the real issue being one of getting
us all to tell you what not to format, rather than one of creating a new
notation.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
(or other non-standard measures) for it to be
something we should care about.
I think the language we've proposed in response to the DISCUSS covers this
appropriately.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL
, particularly not tutorials that constantly repeat
first principles.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
it is relevant to
DKIM, and some indication of concern for that threat among a range of people
The main effect of responding to isolated, terse concerns is to create a record
that can be read as giving credence to those threats.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
a recipient. A signer cannot attack DKIM's mechanisms.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
is countering?
The word reliability has no meaning in this context. On the other had,
misunderstandings about implied or actual data validity is /exactly/ the issue
this text is /intended/ to cover.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 7/7/2011 7:18 AM, John R. Levine wrote:
I would also be interested in seeing an example of a case where adding an
extra
From: line changles the d= in a DKIM signature.
no you wouldn't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
a From: field of bad-ac...@bad-host.example.com does
provide
any obvious basis for giving more 'credence' to the trustworthiness of the
author or the message content.
but this does raise the question of how many times this point needs to be made?
d/
--
Dave Crocker
Brandenburg
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
for such an effort and the community's demonstrated problems with the
problematic text are all clear enough to easily justify our continuing to
expend
significant effort and to further delay publication of this document.
Not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
category an attack falls
into?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to trick filters and users.
We should have the DKIM signing specification normatively require checking
for every known technique, since we cannot be sure that any other part of the
system will perform the necessary checks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/
now automatically provides a copy of a diff between the new version and the
previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871bis-11
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
the difference between formulatng a model
of trusting the sequence of message handlers, versus devising an authentication
technique that survives the sequence of handlers.
Unfortunately, operational changes for security tend to make a more fragile
model.
d/
--
Dave Crocker
bbiw.net
existing practices and treating them as definitive of future needs and uses.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
with additional types of breakage,
since there is no attempt to cover such additional examples.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
' is a useful construct when
projecting Internet-scale transitions of infrastructure service...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
me as far to complex
and fragile to be reasonable.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
One would have expected a former author of the spec who so-often proclaims
their
expertise to understand the semantics of DKIM better. On the other hand, it
does nicely show that implementing code doesn't mean understanding what it is
for...
d/
--
Dave Crocker
Brandenburg
and there are already efforts ongoing that will make is
/less/ useful. To gain extremely widespread deployment, those efforts will
need
a very long time, of course, but nonetheless, they are happening.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
when included in the set of h=
covered header fields.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
work is actually about behavior, except when the
identity-related certification couples one identifier to another (or, my
familiarly, one identifier to an identity.)
d/
ps. none of this has anything to do with the current DKIM wg tasks, of
course...
--
Dave Crocker
Brandenburg
share it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
The proposed change tries to move some of the processing into the parameter, and
hence is not an interface specification (unless, for example, the goal is to
tell the caller to truncate the body, rather than have the subroutine do the
truncating.
d/
--
Dave Crocker
Brandenburg InternetWorking
of algorithms is defined to be extensible, anyone feeling that
an
additional algorithm is warranted is free to define it and seek community
consensus for it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates
deal of debate,
and I see no evidence that the definition is defective.
+1 to the -1.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
a standards-track specification for it being adopted, it's not
interoperable.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
+1. No.
John R. Levine jo...@iecc.com wrote:
No.
+1 to the No.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
/11/2011 10:36 AM, John R. Levine wrote:
... but you should blame me for
the whole thing, borrowed or otherwise.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org
is the
benefit of introducing a possible linkage?
3. As negotiating model's go, it is counter-productive to open with a
fall-back
offer.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according
it as a
*better* mechanism for this document than BCP, if the IESG decides
that it agrees. The experiment is seeing if the IESG agrees, and
the fall-back is BCP.
Perhaps I missed the working group discussion that agreed to this approach?
d/
--
Dave Crocker
Brandenburg InternetWorking
.
The construct is currently unused and is also currently under discussion.
IMO, we should stay away from nascent experiments about fuzzy topics with a
poor
track-record.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list
material.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
, it occurs to me that the folks doing this form of +1 might mean ship it
or they might mean preference for replacing with one-page doc or, failing
that,
ship it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL
cleaner to drop it now and explore re-introducing it
in the effort to develop that template.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On 5/9/2011 1:14 PM, Steve Atkins wrote:
On May 9, 2011, at 7:56 AM, Dave CROCKER wrote:
Oddly, I'm finding myself coming to believe that its use within a coordinated
template for mediators might actually being helpful. This assumes, of
course,
that the template can be specified and gain
for claiming that those
using it find no benefit in it.
Hence (and with regret):
-1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to be correct.
In practical terms for the current world, what is the likelihood that a signer
has any information about the 'type' of an email address? How can a signer
possibly know that an addressee is a mailing list???
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
of a DKIM signature. That's not
benignly unnecessary. That's actively counter-productive.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
that
someone chooses to keep raising settled or non- issues does not obligate others
to respond.
That would make things go considerably quicker.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
=s, then the domain name MUST
be the same as SDID. For DKIM processing,
See above.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
1 - 100 of 1246 matches
Mail list logo
