On Tue, 4 Sep 2007, Peter Eisch wrote:
Would it be possible to implement -id as a hook? The actual key could then
be left to the creativity of the user. The plugin could then implement the
other hooks and tune the id as necessary (connect, mail, queue, etc.).
Yes, it's possible to do it
$instance_id # could be opaque or structured to include server name
# or IP, PID, etc.
$instance_id.$connection_id # identifies a connection handled
# by this instance
$instance_id.$connection_id.$transaction_id # identifies a
On 2007-09-04 07:59:15 -0700, JT Moree wrote:
$instance_id# could be opaque or structured to include server name
# or IP, PID, etc.
$instance_id.$connection_id # identifies a connection handled
# by this instance
On 4-Sep-07, at 12:43 PM, Peter J. Holzer wrote:
I was playing around a bit on the weekend, yes. Since neither Matt nor
Ask have cried out in horror on what I did,
FWIW I didn't object simply because it seems so pointless with
everyone having such conflicting ideas about what this should
On Sep 4, 2007, at 9:43, Peter J. Holzer wrote:
I was playing around a bit on the weekend, yes. Since neither Matt nor
Ask have cried out in horror on what I did, I guess it's time to
present
that to a wider audience:
I just got back from vacation and is hopelessly behind on reading up
On 9/4/07 1:14 PM, Matt Sergeant [EMAIL PROTECTED] wrote:
On 4-Sep-07, at 12:43 PM, Peter J. Holzer wrote:
I was playing around a bit on the weekend, yes. Since neither Matt nor
Ask have cried out in horror on what I did,
FWIW I didn't object simply because it seems so pointless with
How does qmail do it?
On Sun, 2007-09-02 at 17:52 -0500, David Nicol wrote:
How does qmail do it?
Uses the inode number ... doesn't work for qpsmtpd ... and it's crap for
logging (see my comment earlier in the thread) since the inodes get
recycled.
--
--gh
On 2007-08-31 13:44:44 -0400, Charlie Brady wrote:
On Fri, 31 Aug 2007, Peter J. Holzer wrote:
On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
127.0.0.1 is a problem even after establishing the connection: With
normal routing arrangements the remote IP address will be 127.0.0.1,
too, so
On 2007-08-31 11:28:55 -0400, m. allan noah wrote:
On 8/31/07, Peter J. Holzer [EMAIL PROTECTED] wrote:
On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
However, there is still an issue with Peter's proposed zero out remote
address components proposal - prior to accept(),
On 2007-08-29 19:15:37 -0400, Guy Hulbert wrote:
On Thu, 2007-08-30 at 00:49 +0200, Michael Holzt wrote:
or even
10 + 1 + 16 + 1 + 39 + 1 + 5 + 1 + 39 + 1 + 5 = 119 characters
Better encode it binary. E.g. for IPv4:
And better get the number of bits correct. An IP address is a
On Sat, 2007-09-01 at 10:08 +0200, Peter J. Holzer wrote:
Better encode it binary. E.g. for IPv4:
And better get the number of bits correct. An IP address is a 32
bit
integer, not 15 characters.
You've snipped the context. JT was calling the
Qpsmtpd::Connection::local_ip method
On 2007-08-30 21:12:15 -0400, Charlie Brady wrote:
On Thu, 30 Aug 2007, Peter J. Holzer wrote:
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
On Fri, 31 Aug 2007, Michael Holzt wrote:
You can't have multiple processes bound to the same
local_IP/local_port,
Of course you can.
bind - listen - fork
Yes, brain fart at my end. s/$/ except by inheritance post-fork/.
If we stop listening post-fork (as qpsmtpd-forkserver does) then
On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
On Fri, 31 Aug 2007, Michael Holzt wrote:
You can't have multiple processes bound to the same
local_IP/local_port,
Of course you can.
bind - listen - fork
Yes, brain fart at my end. s/$/ except by inheritance post-fork/.
If we
On Fri, 31 Aug 2007, Peter J. Holzer wrote:
On 2007-08-31 10:42:37 -0400, Charlie Brady wrote:
However, there is still an issue with Peter's proposed zero out remote
address components proposal - prior to accept(), qpstmpd-forkserver may
have multiple listening sockets. Some of those sockets
On 2007-08-30 10:08:36 +0200, Peter J. Holzer wrote:
Here are some (measured) resolutions of gettimeofday on various systems:
Linux/i386: 1 ms
Linux/SPARC: 2 ms
HP-UX/PA-RISC: 2 ms
Linux/Alpha: 976 ms (1024 Hz)
Ok, so the Alpha is obsolete, and Sun and HP hardware seems to
On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote:
On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
[snip]
Just assume that time() can have the granularity of the CPU instruction
counter[1].
It could (if your perl implementation uses 128 bit long doubles), but it
Or you could have
On Thu, 2007-08-30 at 10:45 +0200, Tony L. Svanstrom wrote:
Would this be a bad time to mention that people might get the idea that
they want to run two different setups of qpsmtpd on the same server?
No that's fine. PID is still in there taking care of that.
True, but the code
On 30-Aug-07, at 4:45 AM, Tony L. Svanstrom wrote:
True, but the code makes both the security guy and the programmer
in me
twitch...
Well, don't think of it for security then :-)
The part of the unique ID meant to identify the server is now
focusing on the
OS/computer instead of the
On Thu, 2007-08-30 at 09:14 -0400, Matt Sergeant wrote:
The part of the unique ID meant to identify the server is now
Is this unique ID the transaction ID we've been discussing.
Has someone already implemented it in svn - I thought it was a new
proposal (I'm just a bit confused here) ?
On 30-Aug-07, at 9:34 AM, Guy Hulbert wrote:
On Thu, 2007-08-30 at 09:14 -0400, Matt Sergeant wrote:
The part of the unique ID meant to identify the server is now
Is this unique ID the transaction ID we've been discussing.
Yes.
Has someone already implemented it in svn - I thought it
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH wtf does this mean - the *purpose* of the discussion is to *fix* a
GH *unique* transaction ID when the discussion is over it is *fixed* and
GH the discussion *documents* the implementation.
I meant undocumented as in it in Transaction.pm
On Thu, 2007-08-30 at 10:01 -0400, Matt Sergeant wrote:
That is not true. Random numbers do not give unique results.
True enough. But I'm going out on a limb to assume that it's good
enough for logging. It's not a security feature.
But this (by design[*]) doesn't meet the requirement.
On Thu, 2007-08-30 at 16:07 +0200, Tony L. Svanstrom wrote:
To qpsmtpd the hostname isn't as unique as the IPs + port used by it
is.
But for qpsmptd the hostname is configurable ( config('me') ). As
long as a hash is not used (see my follow-up to Matt) and the function
used is documented,
On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote:
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
GH wtf does this mean - the *purpose* of the discussion is to *fix* a
GH *unique* transaction ID when the discussion is over it is
*fixed* and
GH the discussion *documents* the
On Thu, 2007-08-30 at 10:30 -0400, Matt Sergeant wrote:
On 30-Aug-07, at 10:07 AM, Tony L. Svanstrom wrote:
On Thu, 30 Aug 2007 the voices made Guy Hulbert write:
[snip]
GH the discussion *documents* the implementation.
I meant undocumented as in it in Transaction.pm currently says
On Aug 26, 2007, at 10:02, Matt Sergeant wrote:
On 25-Aug-07, at 8:37 PM, Guy Hulbert wrote:
The mod_uniqueid module in apache has quite a reasonable
implementation.
There is a perl implementation on CPAN (in my directory).
I'm assuming Ask is referring to
Woah - bikeshedding galore!
I just got my email downloaded to my mac (I'm traveling) and Mail.app
says there are 61 mails in this thread (plus those I deleted
earlier!?!).
Enough already.
If anyone has a serious realistic concern with what Matt did, please
provide a perl implementation
Guy Hulbert wrote:
me = linux1
- linux1__
me = linux2.example.com
- linux2.e
If you run two instances you can call them 'thing1' and 'thing2'.
I'd rather not.
--
JT Moree
On Fri, 2007-08-31 at 00:59 +0800, Ask Bjørn Hansen wrote:
Woah - bikeshedding galore!
I just got my email downloaded to my mac (I'm traveling) and Mail.app
says there are 61 mails in this thread (plus those I deleted
earlier!?!).
Enough already.
There might have been a little less
Ask asked us to stop ... but what the heck ;-).
Perhaps we should drop the list after this one though.
On Thu, 2007-08-30 at 14:19 -0400, Matt Sergeant wrote:
On 30-Aug-07, at 10:57 AM, Guy Hulbert wrote:
Nope. I reject this. The design ASSUMES that the clock has
sufficient
On 30-Aug-07, at 2:52 PM, Guy Hulbert wrote:
Actually, I think the right answer is just a sequence generator (mod
1). That guarantees different consecutive results.
I think so too. In my testing perl only switches to floating point at
or around 2**50 on 32 bit platforms, which should
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
according to RFC 793), so you don't even need a high resolution timer.
However, what if there is
On 2007-08-30 07:07:51 -0400, Guy Hulbert wrote:
On Thu, 2007-08-30 at 10:08 +0200, Peter J. Holzer wrote:
On 2007-08-29 18:36:12 -0400, Guy Hulbert wrote:
Here are some (measured) resolutions of gettimeofday on various systems:
Linux/i386: 1 ms
Linux/SPARC: 2 ms
On Thu, 30 Aug 2007, Peter J. Holzer wrote:
On 2007-08-29 17:50:28 -0400, Charlie Brady wrote:
A four-tuple identifying the TCP connection also identifies the server.
Right. And the tuple must not be reused for some time (2*MSL or 4 minutes
according to RFC 793), so you don't even need a
On Tue, 2007-08-28 at 23:04 -0400, Charlie Brady wrote:
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
hires_time.pid.local_port
...
my $conn = $args{connection};
my $ip = $conn-local_port || 0;
my $start = time;
my $id = $start.$$.$ip;
Some people have suggested adding
On 28-Aug-07, at 11:04 PM, Charlie Brady wrote:
Err, actually I had a brain fart. It should be remote_port.
No, it should be remote_IP.remote_port.local_port and should
include a transaction_within_connection count. I don't think that
pid adds anything.
Please try any way you can to get
From: Charlie Brady [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 23:04:56 -0400 (EDT)
No, it should be remote_IP.remote_port.local_port and should include a
transaction_within_connection count. I don't think that pid adds anything.
Isn't localport always 25?
Chris
--
Chris Garrigues
Chris Garrigues wrote:
From: Charlie Brady [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 23:04:56 -0400 (EDT)
No, it should be remote_IP.remote_port.local_port and should include a
transaction_within_connection count. I don't think that pid adds anything.
Isn't localport always 25?
Charlie Brady wrote:
On Tue, 28 Aug 2007, Matt Sergeant wrote:
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
hires_time.pid.local_port
...
my $conn = $args{connection};
my $ip = $conn-local_port || 0;
my $start = time;
my $id = $start.$$.$ip;
Some people have suggested adding the
On 8/29/07, JT Moree [EMAIL PROTECTED] wrote:
Given that we are still disagreeing on what is the best way to do it;
Can we use all information used so far to get the most unique possible
for now? Even if it's not perfect, it's a start. Even if some of the
information seems extraneous to some
On Wed, 2007-08-29 at 11:53 -0400, m. allan noah wrote:
On 8/29/07, JT Moree [EMAIL PROTECTED] wrote:
Given that we are still disagreeing on what is the best way to do it;
Can we use all information used so far to get the most unique possible
for now? Even if it's not perfect, it's a
Isn't localport always 25?
the most time: yes.
But it can also be 465
Also port 587 (message submission as per RFC2476).
Regards
Michael
--
It's an insane world, but i'm proud to be a part of it. -- Bill Hicks
If you leave out any of the local info, an installation with two
servers with un-synced times could still gen the same id. if you add
it, then the only way you could have a collision is if your time is
not granular enough or gets set back.
I'm ok with that
Using HiRes::Time
my $lip =
On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH Why is there all this confusion about security ? The goal is to have
GH a unique MessageID for logs ...
Then forget about the word security, and let's just say that people might
want to have unique IDs that'll be unique even when
On 8/29/07, Guy Hulbert [EMAIL PROTECTED] wrote:
if you want to be paranoid, you have to have all 4 data points from
Why is there all this confusion about security ? The goal is to have
a unique MessageID for logs ...
i never said security. i said paranoid, specifically about collisions.
On Wed, 2007-08-29 at 12:23 -0400, m. allan noah wrote:
On 8/29/07, Guy Hulbert [EMAIL PROTECTED] wrote:
if you want to be paranoid, you have to have all 4 data points from
Why is there all this confusion about security ? The goal is to have
a unique MessageID for logs ...
i never
On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH Why is there all this confusion about security ? The goal is to have
GH a unique MessageID for logs ...
Then forget about the word security, and let's just say that
A UUID is preferable to the other solutions because you can condense it
down to 128 bits of binary data ... and put it in a database. :)
The other solutions are not as database friendly. It seems to me if
we're trying to solve the problem of guaranteeing unique transaction ids
for extremely high
On Wed, 2007-08-29 at 10:14 -0700, David Sparks wrote:
A UUID is preferable to the other solutions because you can condense it
down to 128 bits of binary data ... and put it in a database. :)
HiRes::Timer is 64 bits ... leaving 64 bits for the server tag.
The other solutions are not as
Guy Hulbert wrote:
There have been several adequate suggestions. This is only a problem if
it goes into the qpsmtpd core since some of the suggestions are reported
to be in use already.
how is this a problem. those uses should still work even if we start
with the same variable because they
Tony L. Svanstrom wrote:
Then forget about the word security, and let's just say that people might
want to have unique IDs that'll be unique even when they've got more than one
server and centralized/aggregated logging... But we're not even there right
now, we are still stuck on how to make
On Wed, 2007-08-29 at 11:16 -0700, JT Moree wrote:
Guy Hulbert wrote:
There have been several adequate suggestions. This is only a problem if
it goes into the qpsmtpd core since some of the suggestions are reported
to be in use already.
how is this a problem. those uses should still work
On 2007-08-29 13:07:06 -0400, Guy Hulbert wrote:
On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH Why is there all this confusion about security ? The goal is to have
GH a unique MessageID for logs ...
Then
On 2007-08-29 09:08:56 -0700, JT Moree wrote:
If you leave out any of the local info, an installation with two
servers with un-synced times could still gen the same id. if you add
it, then the only way you could have a collision is if your time is
not granular enough or gets set back.
On Wed, 29 Aug 2007, Guy Hulbert wrote:
1. A unique ID per message (on one server).
2. Ability to distinguish per recipient.
3. Ability to identify the server.
A sequence solves (1) except for simultaneous processing of
incoming messages via:
a) async
On 29-Aug-07, at 1:07 PM, Guy Hulbert wrote:
On Wed, 2007-08-29 at 18:15 +0200, Tony L. Svanstrom wrote:
Then forget about the word security, and let's just say that
people might
want to have unique IDs that'll be unique even when they've got
more than one
server and
On 29-Aug-07, at 5:50 PM, Charlie Brady wrote:
Except with multiple CPUs is a big problem. OTOH, as has been
mentioned multiple times, a four-tuple identifying the TCP
connection plus a timestamp will be satisfactory with any number of
CPUs, and with very fast networks.
pid entirely
On Wed, 29 Aug 2007, Matt Sergeant wrote:
On 28-Aug-07, at 11:04 PM, Charlie Brady wrote:
Err, actually I had a brain fart. It should be remote_port.
No, it should be remote_IP.remote_port.local_port and should include a
transaction_within_connection count. I don't think that pid adds
On Wed, 29 Aug 2007 the voices made Matt Sergeant write:
MS I've added in a basic hashed version of hostname now.
Would this be a bad time to mention that people might get the idea that they
want to run two different setups of qpsmtpd on the same server? Like one for
incoming e-mails and one
Peter.
I think it might help if you were to just rewrite the requirements
properly. I don't have strong opinions on what the solution should be
nor what the requirements should be. As long as the total number is
small and they are written concisely they will either converge or, if
necessary, we
my $lip = $conn-local_ip();
up to 15 characters (39 with IPv6)
my $rip = $conn-remote_ip();
up to 15 characters (39 with IPv6)
my $rport = $conn-remote_port || 0;
up to 5 characters
my $lport = $conn-local_port || 0;
up to 5 characters
my $start = time;
up to 16
On 8/29/07, Matt Sergeant [EMAIL PROTECTED] wrote:
On 29-Aug-07, at 5:50 PM, Charlie Brady wrote:
Except with multiple CPUs is a big problem. OTOH, as has been
mentioned multiple times, a four-tuple identifying the TCP
connection plus a timestamp will be satisfactory with any number of
On 29-Aug-07, at 6:03 PM, Charlie Brady wrote:
That is just asserting that no single process could receive two
connections in the same tick of time() (because if it could, it's
trivial to arrange for them to have the same remote port). I can
conceive of that happening, so we should do
On 29-Aug-07, at 6:38 PM, Tony L. Svanstrom wrote:
On Wed, 29 Aug 2007 the voices made Matt Sergeant write:
MS I've added in a basic hashed version of hostname now.
Would this be a bad time to mention that people might get the idea
that they
want to run two different setups of qpsmtpd on
On 29-Aug-07, at 7:02 PM, m. allan noah wrote:
On 8/29/07, Matt Sergeant [EMAIL PROTECTED] wrote:
On 29-Aug-07, at 5:50 PM, Charlie Brady wrote:
Except with multiple CPUs is a big problem. OTOH, as has been
mentioned multiple times, a four-tuple identifying the TCP
connection plus a
James W. Abendschan wrote:
The check_earlytalker plugin ensures at least a one
second pause in every SMTP session, so time() + peer IP
+ peer port will be far more unique than a random number :-)
This has been suggested a few times but I'd rather not have to have ids
for the system depend on
On 8/28/07, JT Moree [EMAIL PROTECTED] wrote:
James W. Abendschan wrote:
The check_earlytalker plugin ensures at least a one
second pause in every SMTP session, so time() + peer IP
+ peer port will be far more unique than a random number :-)
This has been suggested a few times but I'd
Why not use something like Data::UUID?
http://search.cpan.org/~rjbs/Data-UUID-1.148/UUID.pm
There is reads:
It provides reasonably efficient and reliable framework for generating
UUIDs and supports fairly high allocation rates -- 10 million per second
per machine -- and therefore is suitable
remoteIP + remotePort + fineGrainedTime is what we use in-house for
some high-speed http logging that needs a unique handle. it works just
fine with a fair number of concurrent clients behind a nat or proxy.
but, my installation is not massive :)
Add PID and a per-process message-counter and
I've checked in $transaction-id support now. Please let me know if
you think it's OK.
Matt.
Matt Sergeant wrote:
I've checked in $transaction-id support now. Please let me know if you
think it's OK.
which method did you use?
--
JT Moree
On 28-Aug-07, at 3:12 PM, JT Moree wrote:
Matt Sergeant wrote:
I've checked in $transaction-id support now. Please let me know
if you
think it's OK.
which method did you use?
hires_time.pid.local_port
Matt.
Matt Sergeant wrote:
On 28-Aug-07, at 3:12 PM, JT Moree wrote:
Matt Sergeant wrote:
I've checked in $transaction-id support now. Please let me know if you
think it's OK.
which method did you use?
hires_time.pid.local_port
I found the svn web interface:
# generate id
my $conn =
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
I found the svn web interface:
# generate id
my $conn = $args{connection};
my $ip = $conn-local_port || 0;
my $start = time;
my $id = $start.$$.$ip;
Some people have suggested adding the remote IP address. I'm curious
why use local port
On Tue, 28 Aug 2007, Matt Sergeant wrote:
On 28-Aug-07, at 3:51 PM, JT Moree wrote:
hires_time.pid.local_port
...
my $conn = $args{connection};
my $ip = $conn-local_port || 0;
my $start = time;
my $id = $start.$$.$ip;
Some people have suggested adding the remote IP address.
On 24-Aug-07, at 6:40 PM, David Sparks wrote:
I'm using the poll server which means that there aren't threads to
worry
about. However the future probably means running multiple daemons to
take advantage of multi-core systems so there would need to be a
daemon
id encoded in there.
Yeah,
On Fri, 24 Aug 2007, Guy Hulbert wrote:
fqdn + time + peer TCP port will be pretty unique, regardless of
fqdn is the trivial part
rand will be pretty unique ...
Initial connection time, peer IP, and peer port will only
repeat if the connection is torn down and restablished with
the same
JT Moree wrote:
Is this uique enough? what is the chance of getting the same random
number again? should it be a combination of the PID + time + rand?
my @sname = split(/\./, $self-qp-config(me));
= $sname[0].$$.'r'.int( (( time ^ $$ ) * rand($$)) / rand(time/$$));
= sprintf(%08X,
On Fri, 2007-08-24 at 11:52 -0700, JT Moree wrote:
JT Moree wrote:
Is this uique enough? what is the chance of getting the same random
number again? should it be a combination of the PID + time + rand?
my @sname = split(/\./, $self-qp-config(me));
= $sname[0].$$.'r'.int( (( time ^
On Fri, 24 Aug 2007, Guy Hulbert wrote:
These are the approaches suggested so far. I added the last one as a
combination of the others. Can we see a show of hands for the one
Using rand is bogus. A random number generator will repeat values.
Time (with sufficient resolution) is
On Fri, 24 Aug 2007, James W. Abendschan wrote:
On Fri, 24 Aug 2007, Guy Hulbert wrote:
These are the approaches suggested so far. I added the last one as a
combination of the others. Can we see a show of hands for the one
Using rand is bogus. A random number generator will repeat
James W. Abendschan wrote:
On Fri, 24 Aug 2007, Guy Hulbert wrote:
These are the approaches suggested so far. I added the last one as a
combination of the others. Can we see a show of hands for the one
Using rand is bogus. A random number generator will repeat values.
Time (with
On Fri, 24 Aug 2007, Jens Weibler wrote:
mmh, multiplexed?
A mailserver can send multiple mails within one tcp-connection:
There may be zero or more, transactions in a session. - RFC2821
Ah, good point. Okay then, obviously qpsmtpd now needs to be rewritten
to make me right -- after leaving
Guy Hulbert wrote:
Using rand is bogus. A random number generator will repeat values.
So you would definitely not like #2 and probably not #1. How about #3
and $4?
Time (with sufficient resolution) is equivalent to a sequence ... but
with threads, you would need a lock on the sequence
= sprintf(%.4f, time()) ... $self-qp-config(me) . \
sprintf(%08X, rand(2**32 - 1)); #how expensive is this?
These are the approaches suggested so far. I added the last one as a
combination of the others. Can we see a show of hands for the one
Using rand is bogus. A random number
On Fri, 2007-08-24 at 13:18 -0700, James W. Abendschan wrote:
On Fri, 24 Aug 2007, Guy Hulbert wrote:
These are the approaches suggested so far. I added the last one as a
combination of the others. Can we see a show of hands for the one
Using rand is bogus. A random number
On Fri, 2007-08-24 at 13:22 -0700, JT Moree wrote:
Guy Hulbert wrote:
Using rand is bogus. A random number generator will repeat values.
So you would definitely not like #2 and probably not #1. How about #3
and $4?
I can't think of anything that guarantees a unique number ... except
89 matches
Mail list logo
