
Version Elm2.4ME+ PL0 (25) is based to version Elm2.4 PL24 ME8b+.
Version Elm2.4 PL24 ME8b+ is based to version Elm2.4 PL24 ME8b.

Version Elm2.4 PL24 ME8b is done by Michael Elkins <elkins.aero.org>.
For details, look file ANNOUNCE.ME

[ Equivalent of MIME code in Elm2.4 PL24 ME8b is posted to
  Elm Development Cordinator ]
   
Version Elm2.4 PL24 ME8b is based to version Elm2.4 PL24.
Version Elm2.4ME+ PLx (25) includes patch of version Elm2.4 PL25.

Changes of Elm2.4ME+ PL15 (25) to  Elm2.4ME+ PL14 (25)
------------------------------------------------------

	[ Warning: This is perhaps more buggy than PL14. ]

	- Some changes in Makefiles, Configure
	- Change of temporary mbox name, put temporary mbox to
	  back to temp directory (from home directory)
	- lib/safeopen.c
	- can_open(filename,"sw") checks if creating of _new_ file
	   is possible (O_EXCL) -- and use that in leavembox.c
	   Side-effect: New file is created
	- use isprint((unsigned char)ch) in src/curses.c
	- "I removed all fopen(file, "w") where file was a filename in /tmp 
	   and replaced these with a safeopen(file) call.  These changes 
	   should be also applied to the vanilla elm source."
	- "Also there are some minor bugfixes for PL11.  
           Elm did not asked my PGP password when I wanted to 
           read a PGP encrypted mail since it wrongly thought
           that the mail is only signed but not encrypted.  
	   That's the most serious bug."
	- "I add a ClearScreen() before the fork in pgp_decrypt_init() 
	   to make the screen look clearer."
	   From: Zoltan Hidvegi <hzoli@cs.elte.hu>

	- Routine safeopen_rdwr added to safeopen.c 

	- Test agaist special modes was WRONG in leavembox.c
		(it was 0x7000 and it should be 07000)
	- Treate files with special modes as SPOOL files (newmbox.c)
	- Handle 'intelligent' way also SPOOL files what haven't in mailhome
	- Restore also special modes of file if file is not executable
	- Don't chown file if owner is already correct -- it resets
	  special modes
	* With these changes it is possible to redirect sendmail aliases
	  to files (mode 04600) and cause that elm does not reset setgid
	  bit (what is required to be set, before sendmail accepts forwarding
	  to no world writable files).

	- Multiple To: -headers was cauisng of trashing of memory
	  and SIGSEGV
	  Noted by: Richard Allen <ra@rhi.hi.is>

	- Elm fail in resyncing if mailfile is created after initial
	  entering to mailbox.
	  Noted by: Miroslav Ruda <ruda@ics.muni.cz>
	  { I didn't used suplied patch. }

	- Elm fails to create received -folder
	  Noted by: Jussi Kaurola <kaurola@dionysos.FMI.FI>
	- Added function open_end_update to file_util.c

	- Replace iscntrl((unsigned char)*pending) with
	  !isprint((unsigned char)*pending) in builtin++.c
	  because Configure asks that is isprint 
	  working with 8-bit values, but it does not ask about iscntrl

	* Notice: Seems that someones does not agreed with interpretation
	  of ASCII_CTYPE defination. My interpretation is:

                ASCII_CTYPE defined:    isprint works only with arguments
                                        0-127

                Conclusion:             We can't test that is characters in
                                        range 128-255 printable or not, so
                                        don't print them

	  ASCII_CTYPE is defined when you answer "no" to following question:
	  "Should Elm assume that isprint() won't break on 
            non-ASCII characters?"

	  To get 8-bit characters to work you need:
		1) 8-bit clean ctype functions and macros
		2) ASCII_CTYPE is not defined
		3) setlocale exists (Configure have found locale.h;
		   that is: I_LOCALE is defined)
		4) Correct locale defination (environment variable
			$LANG or $LC_CTYPE usually)
		   Look manual page of setlocale
		- If you are not using builtin(++) pager in Elm, thinks
		  can go more complicated -- all pagers does not use
		  locale definations

	- Use kill(getpid(), SIGSTOP) instead of  kill(0, SIGSTOP)
	  so that delivering of mail does not stop when user suspends
	  Elm.
	  Reported by: Richard J. Auletta <rauletta@erebor.cudenver.edu>

Changes of Elm2.4ME+ PL14 (25) to  Elm2.4ME+ PL13 (25)
------------------------------------------------------

	- PGP signed (or encrypted) MIME mail was not quoted when 
          replying. Quick fix for pgp_decode in pgp.c. It still 
	  perhaps have broken...

Changes of Elm2.4ME+ PL13 (25) to  Elm2.4ME+ PL12 (25)
------------------------------------------------------

	- Compiler was giving warning that 'char *' and
	  'unsigned char *' are not assignment-compatible
	  (for code in mime_encode.c)
	  Noted by: Arkady Altman <aya@cae.cig.mot.com>

	- Include headers of forwarded message to editor
	  buffer even when you have noheader = ON
	  (that is in situation mimeforward = OFF).
	  That is now controlled with elmrc variable "noheaderfwd"
	  (default: OFF)

	- Elm was getting SIGSEGV in remailer_parse_opts in remailer.c
	  Noted by: V Menayang <victor@slip-50-11.ots.utexas.edu>
	  [ Notice that this REMAILER code is still broken! ]

	- remailer.c was calling finger without resetting egid!

	- FreeBSD changes to utils/newmail.c also pertain to NetBSD
	  From: Jeff Thieleke <thieleke@icaen.uiowa.edu>

Changes of Elm2.4ME+ PL12 (25) to  Elm2.4ME+ PL11 (25)
------------------------------------------------------

	Warning: This version is probably much more buggy
		 than PL11 !!

	- The blank line between two messages in a folder 
	  was missing.
	  Noted by: Juergen Obermann <Juergen.Obermann@hrz.uni-giessen.de>

	- If nohdrencoding = TRUE and there is 8bit  characters in subject,
	  treat as there was 8bit characters in body.
	  From: Andrey A. Chernov <ache@astral.msk.su>
	  [ This does not work very well... ie. It works only when
            Content-Type is Text/plain. ]
          " Before RFC 1522 issued, too many users (f.e. Russian users) use
            8bit chars in Subject: header field. There is a lots of 8bit 
            capable MUA & MTA exists now, much more then RFC1522 compatible 
            ones. In existent variant when you enter 8bit subject with ASCII 
            body result content charset stays as ASCII, it makes impossible to
            recognize Subject: charset. I UNDERSTAND that my method violates 
            MIME slightly (no 8bit characters must be in header field) but it 
            is adoptation of real life practic."

	- Add /usr/sbin to default path, there is sendmail on FreeBSD
	- Disable national extensions of 'date'
	- Add FreeBSD lock directory
	- Add KOI8-R charset to user prompt, it is officially registered, 
	  RFC1700
	- Fix utime_buffer declaration for FreeBSD
	- Allow mailbox editing for Expert user level only. Total disabling
          of this option makes life harder for experienced users and total
          enabling cause accidental 'e' hitting damage novice users mailboxes.
          It seems that enabling it for Expert user leve is the best solution.
	  From: Andrey A. Chernov <ache@astral.msk.su>

	- "I also discovered another small 'bug'... Michael Elkins changed 
	   someday in pgp.c a get_address_from() call to a simple strcpy() 
	   which caused my pgp not to find my secret key because of a 
           leading blank:
	   " Volker Paulsen <paulsen@gmd.de>"
	    ^
           After I changed it back to get_address_from() the leading blank
           becomes removed and pgp matches the key correctly against its key
           ring ."
	  From: Volker Paulsen <Volker.Paulsen@gmd.de>

	- Add binary -flag for header_rec. No longer hack for remail.c.

	- Make more clear what part of message was PGP signed or encrypted.
	  (Why pgp returns exit status 0 even when signature doesn not
	   match???)

	- Some massive rewriting of copy_message. Now should decoding of
	  RFC 1522 encoding work correctly when replying (and forwarding).
	  Side effects:
		- Headers which have longer than 32 KB after unfolding
		  are truncated
		- Exact folding is not preserved

Changes of Elm2.4ME+ PL11 (25) to Elm2.4ME+ PL10 (25)
-----------------------------------------------------

	- Elm wrote incorrect Content-Length: -header when 
	  updating Status: -header
	  Noted by: Juergen Obermann <Juergen.Obermann@hrz.uni-giessen.de>
	  [ That content-length is lightly too big and is not fixed
	    if it is last mail in folder (it is not big enough that
	    newmbox.c notices) also incorrent Content-Length: -header
            causes in other situations that it is ignored. This causes
	    problems when "From ":s are not escaped. ]

Changes of Elm2.4ME+ PL10 (25) to Elm2.4ME+ PL9 (25)
---------------------------------------------------

	- CM_DISPLAYING was wrong value in hdrs/defs.h

	- Elm was corrupting folder by adding number to end of mail...
	  And therefore causes that next mail does not start
	  with "From " in folder.
	  Noted by: Volker Paulsen <Volker.Paulsen@gmd.de>

	- REMAILER code does not compile.
	  From: Andrey A. Chernov <ache@astral.msk.su>
	  From: Arkady Altman <aya@cae.cig.mot.com> 

Changes of Elm2.4ME+ PL9 (25) to Elm2.4ME+ PL8 (25)
---------------------------------------------------

	- Attach viewer does not completely fill header_rec 
          so "lines" was uninitiazed, which may cause
          "metapager()" to choose randomly whether to use the 
          built-in pager or not, if you haven't set "pager" to 
          "builtin" or "internal". Now structure is pre-initialized
	  completely. "lines" is set to number of bytes / 60
          (not saticfactory, but actually metapager should use 
           number of lines in decoded message -- 
          not in original anyway.)
          Prompted by: Guy Harris <guy@netapp.com>

Changes of Elm2.4ME+ PL8 (25) to Elm2.4ME+ PL7 (25)
---------------------------------------------------

	- In syscall.c, around line 180, the space for p 
          was allocated but the actual string was never built.
	  From: Mark Johnson <Mark.Johnson@ustc.vlsi.COM>
	
	- At the end of a message with the buildin pager I 
	  sometimes get the prompt "MORE (you've seen 101%):"
	  and I can not read the next message with 
	  pressing the space bar.
	  From: Juergen Obermann <Juergen.Obermann@hrz.uni-giessen.de>

	- "rfc822_reap_comments()" wasn't properly handling 
	  Content-Type: headers like

	  Content-Type: Multipart/Mixed;
		boundary="--Next_Part(Wed_Feb_14_09:54:49_1996)--"

	  because it didn't realize that the ")" in the boundary 
          was inside a quote, and therefore should be copied rather 
          than being stripped out.
	  From: Guy Harris <guy@netapp.com>

	- It wasn't RFC 1522-decoding the name in the "From:" header 
	  when it put in the "Forwarded message from" and 
	  "End of forwarded message from" lines.
	  From: Guy Harris <guy@netapp.com>

	- Put defualt disposition for attachment to be 'attachment'
	  when sending.

	- Check that attachment is not deleted before mail is sent.

	- Because copy_message is now called from metapager, it
	  needs two more arguments (mailfile and current_header).
	  I hope that this change breaks nothing! 
	  Detected from report of: Mark Johnson <Mark.Johnson@ustc.vlsi.COM>

Changes of Elm2.4ME+ PL7 (25) to Elm2.4ME+ PL6 (25)
---------------------------------------------------

	- Incorrect subject

Changes of Elm2.4ME+ PL6 (25) to Elm2.4ME+ PL5 (25)
---------------------------------------------------

	- Sometimes extra newline was added when message or
	  body of it was copied.

	      > copy_message in fileio.c was gone too hairy.
		Tried to reorganize it. I hope that nothing
		breaks.

	      > Semantic of flag CM_DECODE is now changed.

	      > Now message is decoded before replying and forwarding
		(excpet when mime_forward is true -- forwarded message
		as attachment is not decoded).

	      > Well, now [encode] [clear] does not work when metamail
		is called.

	      > [encode] ... [clear] is now internally handled as
		application/X-ELM-encode (in MIME -message)

	- Do RFC 1522 decoding only in MIME messages.

	- builtin++ code in metapager was broken [encode] ... [clear] 

	      > I simplified metapager. I hope that nothing
		breaks.

	> Notice that [encode] ... [clear] is broken when sending
	  multipart messages.

	- Now also headers of message/rfc822 are prefixed when replying

	- Nicer printing of folded headers (in metapager and rfc822_decode)

	- Letter 'e' (= uses Elm's [encode] ... [clear]) added to status
	  letter of mailbox menu.

Changes of Elm2.4ME+ PL5 (25) to Elm2.4ME+ PL4 (25)
---------------------------------------------------

	- "nohdrencoding" was in wrong place in list

	- To instead of From in headers was always displayed:
	  From: Petr Lampa <lampa@fee.vutbr.cz>

	- There was some confusion in (char *) versus (unsigned char *)
	  in rfc1522_encode_text.
	  Pointed by: Petr Lampa <lampa@fee.vutbr.cz>

	- Replaced check of R_OK with ECCESS_EXISTS in can_save 
	  in attach_menu.c

	- Reordering of attach_viewer so metamail is not called 
	  when it isn't needed (new defination of 'pagemultipart'
	  was broken it.)

	- Message "Parsing MIME structure..." is printed

	- Added to some unlink and elm_chown calls to attach_menu.c

	- Now prints "Executing metamail..." if metamail is called for
	  display message.

	- Tried fix MIME decoding of headers in copy_message
	  (well, it still can't work correctly.)

	- MIME (RFC 1522) encoding of In-Reply-To -header

		> Address headers and headers from .elm/elmheaders are still
		  not encoded.

	- Don't try print To: address in menu if it does not exists.

Changes of Elm2.4ME+ PL4 (25) to Elm2.4ME+ PL3 (25)
---------------------------------------------------

	[ Warning: This is perhaps more buggy than PL 3 (25). ]

	* Sending of simple Text/Plain messages with quoted-printable encoding
	  was broken when remailer -code was added.
	  Noted by: Petr Lampa <lampa@fee.vutbr.cz>

	- In the index screen Tag all, Delete all and Undelete all 
	  didn't show the new status of the messages.
	  From: Juergen Obermann <Juergen.Obermann@hrz.uni-giessen.de>

	- In readmsg the Cc-header line is always shown.
	  From: Juergen Obermann <Juergen.Obermann@hrz.uni-giessen.de>
	  [ This should be also posted to Elm Development Cordinator ]

	- Add a "Status: RO" line to all outgoing messages (when the "copy" 
	  option is turned on), so that they do not show up as "New" when you 
	  look at a folder.
	  From: Pete Wenzel <pete@stc.com> 

	- The macro X_OK is undefined in some systems. 
	  Use EXECUTE_ACCESS instead.
          From: Gunnar Ekolin <ekolin@carlstedt.se>

	> Failing to include <unistd.h>. 
	  Test agaist I_UNISTD instead of ANSI_C.
	  Noted by: Petr Lampa <lampa@fee.vutbr.cz>

	> Now EXECUTE_ACCESS, WRITE_ACCESS, READ_ACCESS, ACCESS_EXISTS,
	  EDIT_ACCESS is defined in terms of X_OK, W_OK, R_OK, F_OK
	  from unistd.h (if available)

	- Fix defination in hdrs/mcprt.h to match with lib/mcprt.c
	  From: Claus Assmann <ca@informatik.uni-kiel.de>

	- DisplayAddress not work (well, I really not used that patch).
	  That needs still reconsideration.
	  From: Claus Assmann <ca@informatik.uni-kiel.de>

	- Mime (RFC 1522) encoding of following headers:
		- From 	(fullname)
		- Subject
		- Content-Description

		Encoding of In-Reply-To, To, CC or headers in 
		.elm/elmheaders is NOT done.

	- New elmrc variable "nohdrencoding". If this variable is TRUE,
	  then MIME encoding of headers isn't done.

	- Wrong tests with allow_no_encoding in src/mailmsg2.c.
	  Noted by: Petr Lampa <lampa@fee.vutbr.cz>

	- Use strincmp for lib/strincmp.c instead of strcasecmp.
	  Noted by: Petr Lampa <lampa@fee.vutbr.cz>

	- Added check for write errors in mime_encode.c
	
Changes of Elm2.4ME+ PL3 (25) to Elm2.4ME+ PL2 (25)
---------------------------------------------------

	- Fix to builtin++.c SIGSEGV fix

Changes of Elm2.4ME+ PL2 (25) to Elm2.4ME+ PL1 (25)
---------------------------------------------------

	- Really fix In-Reply-To -header
	  [ This is also posted to Elm Development Cordinator ]

Changes of Elm2.4ME+ PL1 (25) to Elm2.4ME+ PL0 (25)
---------------------------------------------------

	- SIGSEGV in builtin++.c when looking full headers of mail
          and Ctrl-L was hit.

	- Typo in remailer.c (causes that it don't link)
	  From: Ollivier Robert <roberto@keltia.freenix.fr>

	- Ultrix patch from comp.mail.elm
	  From: John Simonson <gort@wildcat.ceas.rochester.edu>,
                Sydney Weinstein <syd@myxa.com>, 
		Bill Gianopoulos <wag@swl.msd.ray.com>

	- Now Elm's Configure search for metamail -program

	- DisplayAddress: Don't munge sender with get_real_name

	- Elm was generating syntactically incorrect In-Reply-To -headers

	- Because some peoples seems have trashed src/state.c that patch
	  includes file src/state.c.PL1. 
	  If src/state.c.PL1 and src/state.c don't have identical,
	  use command: mv src/state.c.PL1 src/state.c
	  otherwise:   rm src/state.c.PL1

	- SIGSEGV when hitting 'G' in builtin++.c


Changes of Elm2.4ME+ PL0 (25) to version Elm2.4 PL24 ME8b+
----------------------------------------------------------

	- Added (security) patch PL24 -> PL25 and 
	  added same kind (security) fixes for MIME code

	- Version number is now formed with new style :-)

	- elmrc -variable 'displaycharset' is propgated to
	  environment variable $MM_CHARSET when calling metamail.
	  Environment variable $MM_CHARSET overwrides default value
	  of 'displaycharset'.

	- New elmrc -variable 'metamail'. So now you not need define
	  environment variable $NOMETAMAIL, if you want compile Elm
	  with MIME support, and you don't have metamail. Special values:
		none		Don't call metamail
		metamail	Call metamail, if environment variable
				$NOMETAMAIL is not defined
		/path		Call tiss, if this is executable

	- Meaning of elmrc -variable 'pagemultipart' is changed. If
	  this is FALSE (default), then call metamail if elm can't
	  handle all subpart of multipart -type or if type is other
	  than multipart/mixed, multipart/digest or multipart/report.
	  If 'pagemultipart' is TRUE, then always handle multipart type
	  without metamail (and treate unknown subtypes as multipart/mixed).

	  Decision can Elm handle that type, is done when message is 
          displayed. So there is now 'M' -letter (= metamail needed) in
	  multipart mails until message is displayed even when Elm can
          show it (that is because that defination is recursive and
	  requires parsing of structure of message.)

	- Multipart/digest now works correctly when viewing attachment
	  what we have sending and we have put type for it to be 
	  Multipart/mixed.

	- Configure now tries test if sendmail supports -B8BITMIME and
	  -BBINARYMIME (unlikely).

	- Makefile now don't compile or install 'filter' because security
	  problems in it.

Changes of Elm2.4 PL24 ME8b+ to version Elm2.4 PL24 ME8b
--------------------------------------------------------

	- New version of my Reply-To patch included
	  [ Old version of that patch is posted to Elm Development Cordinator ]

	- Made MIME part 2 (RFC 1522) decoding more accoriding of RFC.

	- Some bugfixes

Elm mailbox menu's status letters
---------------------------------
	- First letter:		D	Deleted
				E	Expired
				N	New
				O	Unread
				r	replied

	- Second letter:	C	Confidental
				U	Urgent
				P	Private 	(or ...)
				A	Action
				F	Form letter
				e	Uses Elm's [encode] ... [clear]
				P	PGP message	(or ...)
				S	PGP signed message
				K	PGP public key
				?	MIME message with unknown
						MIME version
				M	MIME message wich requires metamail
						or isn't yet parsed
				m	Pre-MIME message wich requires metamail

Warnings
-------- 

	- Not compiled with MMDF or REMAILER support defined, so
	  probably they don't work (or even compile).

	- As far I know REMAILER code have newer worked.

	- This is not tested very much so there can be bad bugs. Bug
	  Reports to: Kari E. Hurtta <hurtta+elm@dionysos.FMI.FI>

	- There still don't be support for multipart/alternative, but
	  now metamail will be called for it because new semantic of 
	  'pagemultipart' (assuming that 'pagemultipart' have default
	  value.)


Collector of these patches
--------------------------

	Kari E. Hurtta <hurtta+elm@dionysos.FMI.FI>
