1* libESMTP 1.0.3 stable release. 2004-04-20
2
3- This release contains TLS improvements from
4  Pawel Salek <pawsa@theochem.kth.se>
5  See ChangeLog for details.
6
7* libESMTP 1.0.2 stable release. 2004-01-06
8
9- See ChangeLog for details.
10
11* libESMTP 1.0.2 stable release. 2004-01-06
12
13- See ChangeLog for details.
14
15* libESMTP 1.0.1 stable release. 2003-09-12
16
17- See ChangeLog for details.
18
19* libESMTP 1.0 stable release. 2002-11-09
20
21  Tarball builds correctly again!
22
23- See ChangeLog for details.
24
25* libESMTP 1.0 stable release. 2002-11-09
26
27  LibESMTP is now considered stable.  Version 1.0 is the best available
28  release of libESMTP and all users are urged to upgrade as soon as is
29  practicable.
30
31  There have been some minor changes to the configure script such that
32  ./configure with no arguments includes all non-experimental features.
33  This means that some features formerly not enabled by default are now
34  included and, conversely, some features formerly enabled by default must
35  now be requested explicitly.  It is intended that, with the exception of
36  features such as setting --prefix or --with-gnu-ld, ./configure will
37  build the correct configuration for most OS distributions.
38
39- See ChangeLog for details.
40
41  This release fixes a minor compilation issue and a potentially more
42  serious memory reference after freeing.
43
44* libESMTP 1.0rc1 stable release candidate 1.	2002-06-24
45
46- See ChangeLog for details.
47
48  o Support for the non-standard AUTH= syntax used by some broken
49    servers is now on by default.  This does not appear to interefere
50    with correctly implemented SMTP AUTH and having it on by default is
51    less confusing for users whose ISPs insist on deploying broken
52    servers.
53
54  o Added experimental support for RFC 3030 CHUNKING and BINARYMIME;
55    enable with ./configure --enable-chunking.  Feedback on the success
56    or otherwise of this code is solicited.
57
58  o New API function to set protocol timeouts.
59
60* libESMTP 0.8.12 development release.	2002-04-24
61
62- See ChangeLog for details.
63
64  o Added missing check for STARTTLS if server does not support ESMTP.
65
66  o Revoked deprecated status from smtp_option_require_all_recipients
67
68* libESMTP 0.8.11 development release.	2002-03-06
69
70Fixed a buffer overflow which could be exploited by a malicious SMTP
71server.  By overwriting the stack a carefully crafted response could
72cause arbitrary code to be executed.
73
74* libESMTP 0.8.10 development release.	2002-01-29
75
76- Usual autoconf stuff, see ChangeLog for details.
77
78Added an NTLM authentication module.  Currently this requires OpenSSL to
79build.  This has not seen much in the way of testing as I don't have
80regular access to a server which requires NTLM authentication for SMTP.
81However it does generate the correct responses for the test cases I have
82tried.  Feedback on the success or otherwise of this module is solicited.
83
84Compilation with --enable-more-warnings=picky seems to be clean again.
85
86* libESMTP 0.8.9 development release.	2002-01-02
87
88- See ChangeLog for details.
89
90Important:
91    The use of libltdl is now deprecated in favour of dlopen().  libltdl
92    is no longer distributed with libESMTP reducing tarball size.  This
93    change simplifies installation for the majority of users, however
94    users with platforms which do not supply dlopen or libltdl must now
95    obtain and install libltdl separately.
96
97Also Important:
98    Building with --enable-more-warnings=yes/picky might prove akward.
99    Recent glibc versions seem to have changed their mind about the
100    status of strcasecmp and friends to being GNU extensions.
101    Naturally, autoconf 2.13 detects the functions in the library but
102    not that their declarations are unavailable. For this reason,
103    _GNU_SOURCE is defined on gnu type platforms but this might cause
104    inconsistent pointer declarations wrt. signedness, YMMV.  If you
105    have problems, try ./configure --disable-more-warnings.
106
107A horrible hack:
108    Added tentative support/hack for the non-standard AUTH= syntax in
109    EHLO responses.  It might work.  Don't complain to me if it doesn't.
110    You need to ./configure --enable-nsauth for this support.
111      This syntax was only ever described in internet drafts and never
112    made it into RFC 2554.  It should *never* have been deployed on the
113    internet.  Internet drafts are deleted after 6 months and after
114    publication of RFCs.  So there is *no* documentation for this syntax
115    and I can't even begin to guess what it is supposed to be or what
116    implementation errors there are wrt these unavailable documents.
117      My advice is if this hack doesn't work, complain to your ISP and
118    recommend that they deploy MTAs that are standards compliant.
119    Documentation exists for standards and I am happy to make sure
120    libESMTP complies with documents I can actually obtain.
121
122* libESMTP 0.8.8 development release.	2001-11-30
123
124- See ChangeLog for details.
125
126  o Fixes more autoconf issues.
127
128  o Fixed a type mismatch that prevents compilation on some systems.
129
130* libESMTP 0.8.7 development release.	2001-11-7
131
132- See ChangeLog for details.
133
134  o Fixes minor build issues.
135
136  o Improved error handling wrt getaddrinfo
137
138* libESMTP 0.8.6 development release.	2001-10-17
139
140- See ChangeLog for details.
141
142  o Fixes minor build issues.
143
144  o SASL CRAM-MD5 builds without OpenSSL
145
146* libESMTP 0.8.5 development release.	2001-10-04
147
148- See ChangeLog for details.
149
150  o Header code no longer enforces presence of recipient fields.
151
152  o Fixed some build issues related to the automake/libtool interaction.
153    Reverted to autoconf 2.13
154
155  o Removed support for gethostbyname resolver interface.  Please
156    refer to the 'Dependencies' section in README.
157
158  o Enhancements to STARTTLS support.
159
160  o Calculation of current timezone's offset from GMT (UTC) is now
161    portable and thread safe.
162
163* libESMTP 0.8.4 development release.	2001-08-13
164
165- See ChangeLog for details.
166
167* libESMTP 0.8.3 development release.	2001-07-06
168
169- See ChangeLog for details.
170
171  o Support for sendmail's XUSR extension.
172
173  o Fixed a bad bug which caused connections to the server to be dropped
174    depending on the amount of buffering provided by the server.
175
176* libESMTP 0.8.2 development release.	2001-06-26
177
178- See ChangeLog for details.
179
180  o Added lots of assertions in the code.
181
182  o Fixed a bad dangling pointer bug that could strike when sending
183    messages with lines > 510 characters.
184
185  o Fixed a polling bug that could cause deadlock.
186
187  o Resolver interface now uses Posix standard getaddrinfo.
188    Use of gethostbyname is deprecated.
189
190Please note that the current RFC 2822 header API is adequate but
191incomplete; for example, interactions between certain headers are not
192implemented.  This will not change for a while.  The current priority is
193to make the protocol engine robust.
194
195* libESMTP 0.8.1 development release.	2001-06-15
196
197- See ChangeLog for details.
198
199Fixed two uninitialised variable bugs that might cause the protocol
200to quit without sending anything to the server.
201
202Enabled many more compiler warnings when compiling with gcc.  Compiles
203should now be much cleaner.
204
205* libESMTP 0.8.0 development release.	2001-06-12
206
207- See ChangeLog for details.
208
209The libESMTP feature set and API for version 1.0 is more or less complete.
210There have been minor changes to the arguments or semantics of some of
211the API functions, particularly wrt. the callback functions.  Applications
212using previous libESMTP versions will need to be recompiled or relinked.
213
214From this point on no new features will be added and, as far as possible,
215API changes will be resisted.  Having said that, the range of error codes
216will likely be expanded.  Effort will now be directed at bug fixes and
217improving the documentation and web site, though this is likely to be a
218slow process.
219
220Many of the supported SMTP extensions have had only superficial testing
221mainly due to lack of access to servers supporting them.  Developers using
222libESMTP are encouraged to test extensions against servers to which they
223have access and to submit bug reports to <brian@stafford.uklinux.net>.
224
225The libESMTP web site will be updated in the near future to set up
226(finally!)  mailing lists and bug tracking.  In addition the web site will
227link to projects using libESMTP.  If you would like a mention for your
228project, drop a line to <brian@stafford.uklinux.net> with the details.
229
230