-solution until BEEP becomes actually
available...
Any feedback is highly appreciated,
Rainer Gerhards
Adiscon
beep is designed in such a way that you basically pay for
what you use. if you know before hand that you're going to
have at most two channels open (channel zero for management,
and another channel for data exchange), then you can write
the transport mapping stuff in one screen of C (maybe
As I have written the original message, I feel I should post a quick
reply to clarify...
As responsible for the RoadRunner software project I'm
curious as to exactly how you find the library hard to use
for closed-source projects. I'm quite
confident there's a misunderstanding regarding the
On the other hand, if we started with syslog-as-it-is-today,
added TCP transport, took off the line length limits,
delimited records in the TCP stream with newline, and
permitted (as an option) ISO 8601 / RFC 3339 timestamps[1]
instead of the ambiguous and hard-to-sort ones currently
Chris,
Rainer is saying that no one is following the timestamp as
described in 3164 anyway so we should take this opportunity
to standardize upon something suitable to the community.
Making this change will entail the
following:
- Text will have to be provided.
- A note will have to be
payload format. Out of scope. I'll allow discussion on the
WG mailing
list (here) but anything coming from that cannot
be a document
of this WG. After we accomplish our Charter
Goals, we may ask
the ADs to allow the WG to reCharter the WG to
address
Bazsi,
- the timestap SHOULD be formatted in UTC format (zulu time)
I think the requirement of sending the stamp in GMT is not
good. You'd lose the time zone information. It is possible to
convert to a given timezone (be it Zulu or something else) on
the receiver side.
A relay MUST NOT
Hi all,
Based on the feedback on this list, I have re-worded my suggestion for
the change to syslog-sign:
begin suggestion
The TIMESTAMP field is either a RFC3164-TIMESTAMP or a
RFC3339-TIMESTAMP. A sender SHOULD format the timestamp as a
RFC3339-TIMESTAMP. A receiver MUST accept
... While digging deeper into BEEP and it's implementation, I see a
security issue with its deployment. BEEP is a multiplexing protocol,
thus multiple profiles can run concurrently on a given BEEP connection
at a given time. From the firewall point of view, we can simply enable
or disable BEEP.
Harald,
But you don't enable or disable BEEP. You enable or disable
syslog; syslog happens to use BEEP for its messaging
protocol. Ditto anything else that uses BEEP; you're still
enabling the individual protocol.
Are there multiple TCP ports involved? I haven't found this mentioned
anywhere
Harald,
That's my understanding. We don't have a single port for SSL,
instead running blah-over-SSL; BEEP is the same.
Sure - but we know to expect HTTP traffic at port 80 and HTTPS at 443.
So if we don't like HTTPs, we simply block 443 at the firewall. End of
the story.
HTTP opens a
Perhaps ---, since we often use - to indicate missing
stuff. But pretty much anything that is an out of badn,
e.g. not a digit, would be acceptable.
Unfortunately, this would violate [RFC3339]. I think we should try to
stick with the accepted standard rather then inventing yet another time
can not be configured by the MIB.
Anyhow, I think providing a guideline to vendors is definitely helpful and there are
many syslog devices out that can work perfectly with the provided config info.
Just my 2 cents...
Rainer Gerhards
Adiscon
Chris,
I conceptually agree with the proposed change.
At the same time, at the risk of duplicating prior comments,
I see this allows for the HOSTNAME to reference a logical
entity which may be a subset or superset of a physical
entity. For example, foo.bar.com may easily refer to a web
I agree with Andrew,
We so often have seen those limits that we do not envision to become
limits turn into hard ones... Did you ever envision having 1 GB of
memory in your laptop...
Rainer
Maximum TIMESTAMP field length of 30 characters (that should give 4
secfrac characters if the rest of
*really* lengthy (16 KB is even
moderate in some cases). But I also think that we will run into the size
limit in other cases (if it is around the MTU size). RFC3195 could
handle larger messages. Does it do so? If not, is there any support for
such in this WG?
Rainer Gerhards
Adiscon
appreciated. Hopefully I am overlooking something
obvious.
Rainer Gerhards
-Original Message-
From: Darren New [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 5:31 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]
Subject: Re: Syslog Internationalization - Message size
Rainer Gerhards wrote:
Comments are highly appreciated. Hopefully I am overlooking
Eric,
Thanks for the good pointer.
Why not use Unicode UCS-2 with UTF-8 encoding?
http://www.unicode.org/faq/utf_bom.html
ftp://ftp.rfc-editor.org/in-notes/rfc2279.txt
UTF-8 encoding would be backwards-compatible with ASCII in
many (most?)
cases for syslog.
I think there is one issue
Hi Andrew,
Can anyone come up with a way that the initial message header
can be read in any character set and still make sense?
I strongly think the header should NOT be changed. In my view, i18n
should apply to the payload, only. Besides that, US ANSI is always
present in foreign character
only limited information. I'll probably post some text
once I have enough together to do so relatively intelligently...
Rainer
-Original Message-
From: Tom Perrine [mailto:[EMAIL PROTECTED]
Sent: Friday, July 11, 2003 8:56 PM
To: [EMAIL PROTECTED]
Cc: Rainer Gerhards;
Subject: Re
Any one have any thoughts on the syntax to specify the encoding?
Encoding=USASCII
Encoding=Base64
How about borrowing somthing from mime?
Anyhow, I think the sequence must start with some unusual sequence so
that it most probably can not mistakenly occur within a non-i18n
message. For
will know that it is
encoded and in what form.
Cheers
Andrew
-Original Message-
From: Rainer Gerhards [mailto:[EMAIL PROTECTED]
Sent: Friday, 18 July 2003 1:10 a.m.
To: Andrew Ross
Cc: [EMAIL PROTECTED]
Subject: RE: Syslog Internationalization - Message size
Any one have any
feedback deeply appreciated.
Rainer Gerhards
overlooking something obvious...
Rainer
-Original Message-
From: Richard E. Perlotto II [mailto:[EMAIL PROTECTED]
Sent: Monday, July 21, 2003 6:56 PM
To: Rainer Gerhards
Cc: [EMAIL PROTECTED]; 'Andrew Ross'
Subject: RE: Syslog Internationalization /UDP
I was not arguing in favor
over RFC 3195/RAW. Of course, with COOKED, there are some issues,
but RAW would be a big advantage. As of now, I think we could not do a
standard-compliant sign via RAW implementation.
Comments?
Many thanks,
Rainer Gerhards
. :-)
Many thanks,
Rainer Gerhards
Thanks,
Chris
Hi all,
RFC2277 says:
Protocols MUST be able to use the UTF-8 charset, which consists of
the ISO 10646 coded character set combined with the UTF-8 character
encoding scheme, as defined in [10646] Annex R (published in
Amendment 2), for all text.
Protocols MAY specify, in addition,
the initial project goal was. If you have an opinion, I
would appreciate your thoughts. Please contact me off-list, as this is
not really a protocol issue.
Rainer Gerhards
Hi WG,
In RFC 3195, page 15, the samples reads
---
This would be relayed as follows:
C: MSG 1 0 . 2235 242
C: Content-Type: application/beep+xml
C:
C: entry facility='160' severity='6'
C: hostname='bomb'
C:
Hi Anton,
Now the second response ;)
First of all, I will revise the ID in respect to
ftp://ftp.rfc-editor.org/in-notes/rfc3536.txt, which I initially did not
pay proper attention to. This may bring a number of changes. I can not
do it this week, but most probably have done so by the end of next
Chris and all,
I am still strugling with UTF-8 ALL syslog RFCs.
http://www.ietf.org/internet-drafts/draft-yergeau-rfc2279bis-05.txt, in
4. says:
For the convenience of implementors using ABNF, a definition of
UTF-8
in ABNF syntax is given here.
A UTF-8 string is a sequence of octets
Hi all,
I am right now implementing the raw listener. Question: once the raw
channel is up (let's assume channel 1), is it valid to send an error
response (ERR message) if my syslogd experiences a problem. For
example, it may happen that a false calling sequence leaves the library
without a
John and Jon have updated syslog-sign:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt
I believe that Albert suggested that more characters be added
to the TAG
field. He said that @ would be good. Are there any others
that should
be added in Section 2.2? I'd like to
Hi WG,
just so that you can count the number of implementations: today we
released MonitorWare Agent 1.3 which, among others, contains a RFC
3195/RAW server and client. This product is closed source and targeted
towards the Windows platform. I guess it still counts towards the
implementation
WG,
I posted too quickly. Maybe Chris can hold the post. I once again
reviewed RFC 3339 and it says:
--
4.4. Unqualified Local Time
A number of devices currently connected to the Internet run their
internal clocks in local time and are unaware of UTC. While the
Internet
I think, we need to add / as valid char in the TAG.
Would it hurt if we just said:
The TAG is a string of visible (printing) characters excluding SP,
that MUST NOT exceed 32 characters in length.
The first occurrence of a colon (:) or SP character terminates
the TAG
field.
WG,
I am, too, currently implementing an -sign message parser (but not yet
signing). I am parsing the timestamp.
In ABNF, we say:
full-time = partial-time time-offset
That means I must have a time-offset in any case. What should I do (when
generating messages) if I simply do not
Hi,
sorry for raising an additional suggest, but I am currently implementing
and as Albert said, questions arise while doing so ;)
Cookies, as first appeared in syslog-sign, are a simple, efficient and
elegant way to add new functionality to syslog without the need to
change anything in older
Issue 8: Length of syslog messages
http://www.employees.org/~lonvick/draft-ietf-syslog-sign-12.ht
ml#format
From Archive:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01118.html
http://www.mail-archive.com/syslog-sec%40employees.org/msg01119.html
I would like to add an Issue#9 to Chris list ;)
RFC3195/COOKED allows us to specify meta data (like the path element).
This is very valuable information. However, it can be forwarded inside a
relay chain only if all realys speak COOKED.
Let's take my (somewhat artifical) sample from the issue #8
I would, however, like to extend the core syslog format to
support [...] needs to send a larger message
Syslog does support this already. All the programmers has
to to is call
syslog(...) several times (or any other function that is part
of the API.
Well, not talking about API, but if
Anton Albert,
Please note that by providing the sample I was focussed on the length of
the message. I agree with Anton that introducing line breaks is *not* a
good idea. As I said, we have software that forwards Windows event log
data. Let me explain a little how it deals with it - I think this
Albert,
I would, however, like to extend the core syslog format to
support [...] needs to send a larger message
Well, I know Microsoft does not necessarily do it smartly. Many
--- BEING LOG ENTRY ;) -
[deleted about 3k]
END LOG ENTRY --
Still
Hi WG,
this is an important issue for interoperability between -sign and the
upcoming -international. -sign redefines the MSG part of the message as
follows:
(@@@ is included to point out the important fragment)
### -sign ###
The MSG part contains the details of the message. This has
Hi WG,
I am preparing a large edit on -international which will include all
those good comments into the draft. I will probably raise a number of
questions just so that I can verify my understanding of the discussion.
This is the first of those messages.
I think we have consensus that there are
While re-reading -sign, some clarification...
Neither -sign-12 nor my proposed text below specifies US-ASCII as
mandatory. As such, any character set would be appropriate. The encoded
characters would just need to be visible and not be SP or colon. As
such, UTF-8 would be perfectly fine in this
... and some more comment:
However, anyone trying to convey information of
Myproc[PID,Threadid]:
may have a problem with something like
syslog[12345,C:\usr\sbin\cron]:
I would place the burden on the emitor. The colon must be disallowed.
The emitor could use something like
Actually, I was unprecise. Sorry, been too deep in BEEP for a while..
agree on resolved, but something for the security considerations:
RFC 3195 collectors may have severy issues if the packet is
oversized. I will try with my implementation, but this could
lead to a stalling connection.
As
Hi WG,
I had some off-list discussion with Anton Okmianski on the proposed
fragmentation issue in here. I think he raised some very good points and
I am now posting some of his important thoughts (with his permission):
I don't have any beef with reboot id... On the contrary, if it is
defined
Hi WG,
as agreed upon, I have written some wording of how the concept of the
cookie may be described within the syslog format itself. Although it
looks quite straightforward on the first look, there are some nasty
things to consider when it comes to nested cookies and keeping the
namespace clean.
Hi WG,
we have begun working on a signature verifier for -sign-12 (thanks to
Albert's work, we have something to verify:)).
We have come accross an issue with online verification. -sign-12 tella
redundadenncy parameters in section 5. Among others, they specify when a
resend should occur.
Hi WG,
the reboot session id as defined in -sign-12 has potential for
implementations errors. I think is not a really big issue, but I would
like to at least make sure everybody is aware of it.
The range for reboot session id is defined to be 0..9. This is
beyond the scope of unsigned 32
Hi WG,
with this mail, I am again asking for some clarification. This question
may sound silly, but it actually is an issue to me. I am currently
implementing the COOKED server part.
The entry element (RFC3195, 4.4.2) contains a number of pre-parsed
entities, like facility, priority, tag,
In the context of -sign, this is NO issue at all,[...] However, in
the light of -international, things are quite different.
This line is important.
It means (to me:)
-sign is about security
-international is about functionality, NOT about security!
I am on the move and
Hi Albert,
sorry for the slow response, as I wrote I was out of office ... and the
Internet connection was so bad that it was virtually non existant.
I am trying to address all issues you raise. But first of all, by going
through the mail archives, I have noticed that you may find I had picked
On Mon, 2003-10-06 at 10:24, Albert Mietus wrote:
Rainer Gerhards writes:
TAG = full-stat-id [full-dyn-id] (':' / SP)
full-stat-id = [path] progname
full-dyn-id = '[' proc-id [thread-part] ']'
path = path-part 1*(path-sep [path])
path
The closest thing to a standard XML description is in RFC 3195, in the
Cooked profile. But it looks like you don't like that. We have created
our own format for storage, as I think have others. I would try to stick
with the same names used in 3195 - don't make the mistake we made to use
others...
Hi list,
I have observed that at least PIX as well as the popular sysklogd package
under Linux place a LF at the end (last char) of the syslog message. I am
not sure about other syslogd implementations.
Anyhow, I wonder if we should allow LF and (enventually CR in front of it)
as the last
Hi folks,
sorry, a long mail and this on a friday...
I have thought quite a while over the new specification for the TAG. In
the new wording, the path is explicitly defined. Let's see an excerpt:
###
TAG = full-stat-id [full-dyn-id] (':' / SP)
Hi all,
I would like to drag your attention to this yet undiscussed posting:
http://www.mail-archive.com/syslog-sec%40employees.org/msg01338.html
It is regarding the syslog TAG. The format described was discussed in
the context of syslog-sign-13 but now also applies to
syslog-international-00.
Hi WG,
Chris has proposed a XLM-like cookie format in private mail. I received
permission to quote him on this. I would appreciate any feedback from
the WG.
Chris said (Chris, please correct me if you feel I am quoting out of
context):
The thought just struck me about the use of cookies,
Hi David and others,
There is a real demand in the industry for leveraging
existing standards
rather than creating new languages or special syntaxes. The
demand is to
reduce the number of special languages an operator needs to learn, and
to make it possible to integrate the data from one
Hi David,
Let me start about by saying that I am often curmudgeonly, so please
forgive any negative tone to this message; I am making the
comment to be
constructively critical. I have had experience dealing with problems
similar to those I find in this proposal, so please pay
attention to
Hi Doug,
thanks for your interesting mail. I will reply in more detail when I am
through with the papers (looks like it takes some time), but I have an
immediate comment...
The Integrating the Healthcare Enterprise (IHE) initiative
has specified the use of syslog as the mechanism for logging
Hi WG,
I have created an (partial) archive of WG postings. Other than the full,
official one, this is manually structured according the contents of the
messages (at least as far as *I* think what content they belong to).
I had the idea to do this when I began to track the issues for
] Behalf Of Rainer Gerhards
Sent: Wednesday, December 17, 2003 12:55 PM
To: [EMAIL PROTECTED]
Subject: syslog-protocol: Cookie Format
Hi WG,
Chris has proposed a XLM-like cookie format in private
mail. I received
permission to quote him on this. I would appreciate any
feedback from
Happy new year to all! I am finally back from an extended holiday season
(January 6th is also a holidy over here) and I fear I will be posting
some responses today... ;)
Rainer has proposed adding metadata as a field in the
protocol (formerly
called cookies)
I count this as a vote for the
From: Albert Mietus [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 18, 2003 8:44 AM
Rainer Gerhards writes:
It is regarding the syslog TAG. The format described was
discussed in
the context of syslog-sign-13 but now also applies to
syslog-international-00.
You will understand
Meta-data is ok, although I would have preferred referring to these as
just tags
I try to stay away from this, as we have a field (even traditionally)
called TAG in the header. I think a second tag causes at least light
confusion ;)
since this part of the message is not necessarily going to
another message after a too-long vacation season ;) Because I had lots
of time to think, this is a LONG message. It's the reply PLUS a
suggestion for an -international-00 change in regard to the metadata
(formerly cookie) format. I am outling a specific problem and potential
solution, so please
Below some thoughts...
Use strict XML such as:
cookie msgno=123 encoding=USASCII /
Use loose rules so the information can be easily converted to
XML (if one wishes) such as:
cookie msgno=123 encoding=USASCII
Define the format and delimiters with little regard to any
Hi WG,
as you may have seen, the draft editor has posted protocol-01:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-01.txt
First things first: this was a quick edit (while not as quick as I
hoped... ;)). My main objective was to get out some text as quickly as
possible. There
Anton:
Thanks for the great feedback. I would just like to reply to one thing
now, simply because it is 9:30p over here now - but that one is
important for all others reviewing the draft. I should have mentioned it
in my mail:
I did not review section 7 and beyond yet. It seems a lot of it is
Hi all,
I have to admit I am not following that closely with SNMP due being busy
with -protocol.
As it looks SNMP trap may be useful, I would suggest that this is
implemented as a transport mapping for -protocol. -protocol is transport
ignorant by design. Some of the structured data elements may
Message-
From: Andrew Ross [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 24, 2004 9:33 AM
To: 'Anton Okmianski'; Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: syslog-protocol-01 posted comments
Like Anton, I would like to ensure that RFC.new uses a new, specific
message format
Anton,
one more comment:
implementation will be out for many years to come. Obviously,
all real-world syslogds will need to support those older
clients - or they will not receive market acceptance.
I think nothing prevents a syslog server implementation from complying
with both RFC 3164
for the
edit, but also in the hope to do things quickly before the meeting ;)
Thanks,
Rainer
-Original Message-
From: Andrew Ross [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 11:20 AM
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: syslog-protocol-01 posted comments
Hi WG,
as I am editing -international, I noticed that the TRAILER specified may
be worth looking at. Now that we do not need to remain
backward-compatible, I would opt to have a simple tailer in the message.
It was defined as:
SYSLOG-MSG = PRI HEADER MSG [TRAILER]
TRAILER = [CR]
Hi WG,
while editing -protocol to 02, I also work through Anton's early
comments with a lot of good points. I hadn't commented on them so far
because we were on the broader topics. Most of the comments now smoothly
go into the new version, but I found this here that I would like to
bring to the
Hi WG,
again on the edit: I am replacing the few fixed facilities by a 4-digit
number right now. I wonder if it would still make sense to mention the
traditional facilities in -protocol. Same goes for severity, where we
now also allow additional values.
I would appreciate comments on this. For
Hi WG,
just a by-note, so that everybody is aware of this: we are changing the
facility from a few defined values to a very broad range (unsigned int
32, if nobody objects). Please note that some existing implementations
of syslog (namely at least the stock linux versions) use a table of PRI
Hi Rainer,
This pretty much matches with the image I have in mind.
Till there is no original sender in the syslog message
itself I guess that we will have to do with the last sender.
I assume we are talking about a syslog relay chain BEFORE the realy that
issues the trap here. Actually, in
Let me make a comment here that applies to issue #2 (BSD Centric)
-Original Message-
From: Glenn Mansfield Keeni [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 25, 2004 3:05 PM
To: Harrington, David
Cc: [EMAIL PROTECTED]
Subject: Re: SyslogMIB Issue-#4
Hi Dave,
Thanks for
Hi WG,
I had a recent off-list discussion regarding transport mappings. This
discussion targeted the quite important point what transport mappings
are good for - and wether or not -protocol should contain an UDP
transport mapping.
My position is that -protocol should NOT contain any transport
Anton,
I am using your initial message as an additional guide during my edit to
-protocol-02. I will provide some comments on what I did in reply to
your post, so that everyone finds the reasoning. I will eventually leave
some issues open...
-Original Message-
From: Anton Okmianski
Hi WG,
I have updated my page of open issues in -protocol. I would appreciate
if you could comment on the open issues. They can be found here:
http://www.syslog.cc/ietf/protocol.html
Please note that these are just the issues which have definitely been
identified. Others are lurking around, so
David,
-Original Message-
From: Harrington, David [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 05, 2004 9:53 PM
To: Rainer Gerhards; Glenn Mansfield Keeni; [EMAIL PROTECTED]
Subject: RE: SyslogMIB Issue-#4 // Issue-#2
Hi,
SNMP is good at monitoring systems, but not as good
David,
thanks for your wake-up call...
I believe we should move to UTF-8 to allow operators who
UTF-8 is actually a MUST in syslog-protocol.
I have to admit that I did not fully understand UNICODE until now... I
always read RFC 2279 (UTF-8 encoding). It specifies (page 2):
- Character values
Hi all,
thanks for all the great comments. Let me try to sum up the current
concensus:
- multiple transport mappings are a good thing
- it is at least helpful to have one required transport. Some do not
really like this idea, but would tolerate it (correct me if I got
this wrong!)
- a
Given that state of the discussion, I propose that we
actually require
each implementation that talks to a transport MUST support the
to-be-written UDP transport mapping.
I disagree with this on principle. This that talks to a transport
crappy-little-rule is being done to accommodate a
not a priority for
this group here.
Rainer
-Original Message-
From: Harrington, David [mailto:[EMAIL PROTECTED]
Sent: Friday, February 06, 2004 9:26 PM
To: Rainer Gerhards; Anton Okmianski; [EMAIL PROTECTED]
Subject: RE: -protocol: transport mappings
Hi,
Comments inline.
*snip
This is a reply to a direct question - general comment following with
other reply.
With Kiwi Syslog and WinSyslog, the config file is not
created or edited
by the user.
Just FYI: we (WinSyslog similar products) are heading towards either
human-readable config file or skilled-human-readable,
, 2004 7:20 PM
To: Rainer Gerhards; [EMAIL PROTECTED]
Subject: RE: -protocol open issues
On issue #7 - enterprise ID:
I am relatively neutral to this idea. But I am trying to
understand how
it will be used. What are the anticipated use cases for it?
If we want to use it to differentiate
: Sunday, February 08, 2004 12:52 AM
To: Rainer Gerhards; 'Harrington, David'; 'Anton Okmianski';
[EMAIL PROTECTED]
Subject: RE: -international: trailer
It is not just the 0x00 that we have to worry about. For
TCP transport
mappings, we need to have a stream
Hi WG,
I am trying to close up the current open issues for protocol before I
create new ones ;)
I would like to turn to issue 8, that is structured data element
placement. I have put together the (few) most important thoughts here:
http://www.syslog.cc/ietf/protocol/issue8.html
Anton proposed
Anton,
this is a tough one ;)
Well, I think demanding that capability is more about host
implementation. I think it is better to focus on the
protocol and what
the client/sender must put into the UTC offset field if one is not set
on the system.
This is right. And I have to admit it is an
above, mainly because of the
insufficient max size. I am also not sure if it can cause troubles with
other transport mappings (syslog over snmp trap was already discussed
recently in this WG).
What does the rest of the WG think?
Rainer
Anton.
-Original Message-
From: Rainer Gerhards
Hi Anton,
thanks for this very helpful post.
I have to admit I am not 100% sure what the UDP spec says: If
a UDP packet becomes fragmented (due to MTU), is it
guaranteed that the packet will be re-assembled by the
receivers IP stack before it is passed up to the app layer?
What if a
The problem that I have with these solutions is that they require the
syslog daemon to know if the time and timezone on the machine
are valid.
I can't think of any way of doing that.
Actually, I think this is the easy part. Its a trivial solution, but I
think it works. I think we can require
1 - 100 of 127 matches
Mail list logo
