aboutsummaryrefslogtreecommitdiffstats
path: root/dist-tools/test/test-request
blob: 56c31be7b4cf080ddcfe81ddedc635f2d29f31af (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

I maintain an open-source POP and IMAP client called fetchmail.  It is
widely used in the Linux and open-source community, and is probably
the single most popular remote-mail client in that world.  You can
find out more about this project at
<http://fetchmail.berlios.de/>.

In order to be able to do thorough regression testing before each release,
I collect test accounts on as many different kinds of POP3, IMAP, and
ODMR servers as possible.  Because fetchmail is strictly conformant to the 
remote-mail RFCs, many server developers have found fetchmail a useful
standards-conformance test.

I'm writing to request test accounts on your server.  I support all flavors 
of POP2, POP3, IMAP and ODMR with either plain-password, CRAM-MD5, NTLM, 
GSSAPI, or Kerberos authentication.  I also support SSL/TLS.

It would be very helpful if I could have a separate test account for
each protocol you support (that is, separate POP3, IMAP, and ODMR
accounts) so I can do automated regression testing without worrying
about mailbox race conditions.
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-21 18:01:21 +0000
und-color: #fff0f0 } /* Literal.String.Single */ .highlight .ss { color: #aa6600; background-color: #fff0f0 } /* Literal.String.Symbol */ .highlight .bp { color: #003388 } /* Name.Builtin.Pseudo */ .highlight .fm { color: #0066bb; font-weight: bold } /* Name.Function.Magic */ .highlight .vc { color: #336699 } /* Name.Variable.Class */ .highlight .vg { color: #dd7700 } /* Name.Variable.Global */ .highlight .vi { color: #3333bb } /* Name.Variable.Instance */ .highlight .vm { color: #336699 } /* Name.Variable.Magic */ .highlight .il { color: #0000DD; font-weight: bold } /* Literal.Number.Integer.Long */
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
 <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
 <title>TRIO</title>
 <link href="trio.css" rel="stylesheet" type="text/css">
</head>
<body>
<!-- Generated by Doxygen 1.2.12 -->
<center>
<a class="qindex" href="index.html">Main Page</a> &nbsp; <a class="qindex" href="modules.html">Modules</a> &nbsp; </center>
<hr><h1>TRIO Documentation</h1>
<p>
 <dl compact><dt><b>
Author: </b><dd>
Bj�rn Reese , Daniel Stenberg</dl><a name="intro"><h2>Introduction</h2></a>

<p>
Trio is a fully matured and stable set of printf and string functions designed be used by applications with focus on portability or with the need for additional features that are not supported by standard stdio implementation.
<p>
There are several cases where you may want to consider using trio:
<p>
<ul>
<li> Portability across heterogeneous platforms. <li> Embedded systems without stdio support. <li> Extendability of unsupported features. <li> Your native version does not do everything you need.</ul>
When you write applications that must be portable to a wide range of platforms you often have to deal with inadequate implementations of the stdio library functions. Most notably is the lack of secure formatting functions, such as snprintf, or the lack of parameter reordering commonly used for the internationalization of applications, such as the &lt;num&gt;$ modifier. Sometimes the feature you need is simply not present in stdio. So you end up spending much effort on determining which platforms supports what, and to write your own versions of various features. This is where trio can help you. Trio is a platform-independent implementation of the stdio printf and scanf functions and the string library functions.
<p>
The functionality described in the stdio standards is a compromise, and does unfortunately not include a mechanism to extend the functionality for an individual application. Oftentimes an application has the need for an extra feature, and the application code can become much more clear and readable by using an extension mechanism. Trio supports a range of useful extensions such as user-defined specifiers, passing of arguments in arrays, localized string scanning, thousand-separators, and arbitrary integer bases.
<p>
Trio fully implements the C99 (ISO/IEC 9899:1999) and UNIX98 (the Single Unix Specification, Version 2) standards, as well as many features from other implemenations, e.g. the GNU libc and BSD4.
<p>
<a name="examples"><h2>Examples</h2></a>

<p>
<a name="ex1"><h3>Binary Numbers</h3></a>
 Output an integer as a binary number using a trio extension. <div class="fragment"><pre>
  trio_printf("%..2i\n", number);
</pre></div>
<p>
<a name="ex2"><h3>Thousand-separator</h3></a>
 Output a number with thousand-separator using a trio extension. <div class="fragment"><pre>
  trio_printf("%'f\n", 12345.6);
</pre></div> The thousand-separator described by the locale is used.
<p>
<a name="ex3"><h3>Fixed Length Array and Sticky Modifier</h3></a>
 Output an fixed length array of floating-point numbers. <div class="fragment"><pre>
  double array[] = {1.0, 2.0, 3.0};
  printf("%.2f %.2f %.2f\n", array[0], array[1], array[2]);
</pre></div> The same with two trio extensions (arguments are passed in an array, and the first formatting specifier sets the sticky option so we do not have to type all the formatting modifiers for the remaining formatting specifiers) <div class="fragment"><pre>
  trio_printfv("%!.2f %f %f\n", array);
</pre></div> Another, and more powerful, application of being able to pass arguments in an array is the creation of the printf/scanf statement at run-time, where the formatting string, and thus the argument list, is based on an external configuration file.
<p>
<a name="ex4"><h3>Localized scanning</h3></a>
 Parse a string consisting of one or more upper-case alphabetic characters followed by one or more numeric characters. <div class="fragment"><pre>
  sscanf(buffer, "%[A-Z]%[0-9]", alphabetic, numeric);
</pre></div> The same but with locale using a trio extension. <div class="fragment"><pre>
  trio_sscanf(buffer, "%[[:upper:]]%[[:digit:]]", alphabetic, numeric);
</pre></div>
<p>
<a name="legal"><h2>Legal Issues</h2></a>
 Trio is distributed under the following license, which allows practically anybody to use it in almost any kind of software, including proprietary software, without difficulty.
<p>
"Copyright (C) 1998-2001 Bjorn Reese and Daniel Stenberg.
<p>
Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.
<p>
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE AUTHORS AND CONTRIBUTORS ACCEPT NO RESPONSIBILITY IN ANY CONCEIVABLE MANNER."
<p>
<a name="contribution"><h2>Contribution</h2></a>

<p>
<a name="contribute"><h3>Contribute</h3></a>
 We appreciate any type of contribution, from ideas over improvements to error corrections.
<p>
The project space contains references to bug and feature tracking, mailing-list, and the CVS repository. We prefer communication via the mailing-list, but do not require you to be subscribed, because trio is a small project.
<p>
The project space is located at <a href="http://sourceforge.net/projects/ctrio/">http://sourceforge.net/projects/ctrio/</a>
<p>
<a name="contributors"><h3>Contributors</h3></a>
 We have received contributions from the following persons (in alphabetic order sorted by surname)
<p>
<ul>
<li> Craig Berry <li> Stan Boehm <li> Robert Collins <li> Danny Dulai <li> John Fotheringham <li> Markus Henke <li> Ken Gibson <li> Paul Janzen <li> Richard Jinks <li> Tero J�nk� <li> Howard Kapustein <li> Mehdi Lavasani <li> Alexander Lukyanov <li> Emmanuel Mogenet <li> Jacob Navia <li> Jose Ortiz <li> Joe Orton <li> Gisli Ottarsson <li> Marc Werwerft <li> Igor Zlatkovic</ul>
Please let us know, and accept our apology, if we have omitted anybody.
<p>
<HR>
<center class="copyright">Copyright (C) 2001 Bj&oslash;rn Reese and Daniel Stenberg.</center>
</body>
</html>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-21 18:01:21 +0000