Mercurial > docs > master

comparison ch03.roff @ 101:e8e6adb14beb

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Wrote about attachments.
author markus schnalke <meillo@marmaro.de>
date Wed, 20 Jun 2012 11:48:52 +0200
parents 6ae7dc4a3a02
children a782488c85f5
comparison
equal deleted inserted replaced
100:6ae7dc4a3a02 101:e8e6adb14beb
1691 usage of the feature. If it appeared to be truly ancient, I dropped it. 1691 usage of the feature. If it appeared to be truly ancient, I dropped it.
1692 The reason for dropping is always part of the commit message in the 1692 The reason for dropping is always part of the commit message in the
1693 version control system. Thus, it is easy for others to check their 1693 version control system. Thus, it is easy for others to check their
1694 view on the topic with mine and possibly to argue for reinclusion. 1694 view on the topic with mine and possibly to argue for reinclusion.
1695 1695
1696 .U2 "MMDF maildrop support 1696 .U3 "MMDF maildrop support
1697 .P 1697 .P
1698 I did drop any support for the MMDF maildrop format. This type of format 1698 I did drop any support for the MMDF maildrop format. This type of format
1699 is conceptionally similar to the mbox format, but uses four bytes with 1699 is conceptionally similar to the mbox format, but uses four bytes with
1700 value 1 (\fL^A^A^A^A\fP) as message delimiter, 1700 value 1 (\fL^A^A^A^A\fP) as message delimiter,
1701 instead of the string ``\fLFrom\ \fP''. 1701 instead of the string ``\fLFrom\ \fP''.
1719 which restructuring in its core is \(en cause a high risk of damaging 1719 which restructuring in its core is \(en cause a high risk of damaging
1720 the intricate workings of the optimized code. This problem is know 1720 the intricate workings of the optimized code. This problem is know
1721 to the developers of nmh, too. They also avoid touching this minefield 1721 to the developers of nmh, too. They also avoid touching this minefield
1722 if possible. 1722 if possible.
1723 1723
1724 .U2 "UUCP Bang Paths 1724 .U3 "UUCP Bang Paths
1725 .P 1725 .P
1726 More questionably than the former topic is the removal of support for the 1726 More questionably than the former topic is the removal of support for the
1727 UUCP bang path address style. However, the user may translate the bang 1727 UUCP bang path address style. However, the user may translate the bang
1728 paths on retrieval to Internet addresses and the other way on posting 1728 paths on retrieval to Internet addresses and the other way on posting
1729 messages. The former can be done my an MDA like procmail; the latter 1729 messages. The former can be done my an MDA like procmail; the latter
1731 work as expected. However, it might just work well without any 1731 work as expected. However, it might just work well without any
1732 such modifications, as mmh does not touch addresses much, in general. 1732 such modifications, as mmh does not touch addresses much, in general.
1733 But I can't ensure as I have never used an environment with bang paths. 1733 But I can't ensure as I have never used an environment with bang paths.
1734 Also, the behavior might break at any point in further development. 1734 Also, the behavior might break at any point in further development.
1735 1735
1736 .U2 "Hardcopy terminal support 1736 .U3 "Hardcopy terminal support
1737 .P 1737 .P
1738 More of a funny anecdote is the remaining of a check for printing to a 1738 More of a funny anecdote is the remaining of a check for printing to a
1739 hardcopy terminal until Spring 2012, when I finally removed it. 1739 hardcopy terminal until Spring 2012, when I finally removed it.
1740 I surely would be very happy to see such a terminal in action, maybe 1740 I surely would be very happy to see such a terminal in action, maybe
1741 actually being able to work on it, but I fear my chances are null. 1741 actually being able to work on it, but I fear my chances are null.
1746 and the terminal. This could have been ensured with 1746 and the terminal. This could have been ensured with
1747 the 1747 the
1748 .Sw -nomoreproc 1748 .Sw -nomoreproc
1749 at the command line statically, too. 1749 at the command line statically, too.
1750 1750
1751 .U2 "Removed support for header fields 1751 .U3 "Removed support for header fields
1752 .P 1752 .P
1753 The 1753 The
1754 .Hd Encrypted 1754 .Hd Encrypted
1755 header field had been introduced by RFC\^822, but already 1755 header field had been introduced by RFC\^822, but already
1756 marked legacy in RFC 2822. It was superseded by FIXME. 1756 marked legacy in RFC 2822. It was superseded by FIXME.
1807 .Hd Content-MD5 1807 .Hd Content-MD5
1808 header field is useful sometimes, 1808 header field is useful sometimes,
1809 I value its usefulness less than the improvement in maintainability, caused 1809 I value its usefulness less than the improvement in maintainability, caused
1810 by the removal. 1810 by the removal.
1811 1811
1812 .U2 "Prompter's Control Keys 1812 .U3 "Prompter's Control Keys
1813 .P 1813 .P
1814 The program 1814 The program
1815 .Pn prompter 1815 .Pn prompter
1816 queries the user to fill in a message form. When used by 1816 queries the user to fill in a message form. When used by
1817 .Pn comp 1817 .Pn comp
1834 The times when this had been necessary are long time gone. 1834 The times when this had been necessary are long time gone.
1835 Today these things work out-of-the-box, and if not, are configured 1835 Today these things work out-of-the-box, and if not, are configured
1836 with the standard tool 1836 with the standard tool
1837 .Pn stty . 1837 .Pn stty .
1838 1838
1839 .U2 "Vfork and Retry Loops 1839 .U3 "Vfork and Retry Loops
1840 .P 1840 .P
1841 MH creates many processes, which is a consequence of the tool chest approach. 1841 MH creates many processes, which is a consequence of the tool chest approach.
1842 In earlier times 1842 In earlier times
1843 .Fu fork() 1843 .Fu fork()
1844 had been an expensive system call, as the process's whole image needed 1844 had been an expensive system call, as the process's whole image needed
1881 common today. 1881 common today.
1882 1882
1883 1883
1884 .H2 "Attachments 1884 .H2 "Attachments
1885 .P 1885 .P
1886 MIME 1886 The mind model of email attachments is unrelated to MIME.
1887 Although the MIME RFCs (2045 through 2049) define the technical
1888 requirements for having attachments, they do not mention the the word
1889 ``attachment''.
1890 Instead of attachments, MIME talks about ``multi-part message bodies''
1891 [RFC\|2045], a more general concept.
1892 Multi-part messages are messages
1893 ``in which one or more different
1894 sets of data are combined in a single body''
1895 [RFC\|2046].
1896 MIME keeps its descriptions generic;
1897 it does not imply specific usage models.
1898 In email one usage model became prevalent: attachments.
1899 The idea is having a main text document with files of arbitrary kind
1900 attached to it.
1901 In MIME terms, this is a multi-part message having a text part first
1902 and parts of arbitray type following.
1903 .P
1904 MH's MIME support is a direct implementation of the RFCs.
1905 The perception of the topic described in the RFCs is clearly visible
1906 in MH's implementation.
1907 Thus, MH had all the MIME features but no idea of attachments.
1908 Today, however, users don't need all the MIME features but they want
1909 convenient attachment handling.
1910 In order to solve this problem, in 2002, Jon Steinhart had added an
1911 attachment system to nmh.
1912 .Ci 7480dbc14bc90f2d872d434205c0784704213252
1913 He described his motivation to do so as such:
1914 .QS
1915 Although nmh contains the necessary functionality for MIME message handing,
1916 the interface to this functionality is pretty obtuse.
1917 There's no way that I'm ever going to convince my partner to write
1918 .Pn mhbuild
1919 composition files!
1920 .QE
1921 With this change, the mind model of attachments entered nmh:
1922 .QS
1923 These changes simplify the task of managing attachments on draft files.
1924 They allow attachments to be added, listed, and deleted.
1925 MIME messages are automatically created when drafts with attachments
1926 are sent.
1927 .QE
1928 Unfortunately, the system had been deactivated by default,
1929 like any new facilities in nmh.
1930 .\" XXX move this paragraph somewhere else
1931 Just to give one example, for me it took one year of using nmh
1932 before I became aware of the existence of the attachment system.
1933 One could argue that this fact disqualifies my reading of the
1934 documentation.
1935 If I would have installed nmh from source back then, I could agree.
1936 Yet I had used a prepackaged version and had expected that it would
1937 just work.
1938 .P
1939 During my work in Argentina, I tried to improve the attachment system.
1940 Because of great opposition in the nmh community, after long discussions,
1941 my patch died as a proposal on the mailing list.
1942 .[
1943 nmh-workers attachment proposal
1944 .]
1945 In Januar 2012, I applied the patch in an extended form to mmh.
1946 .Ci 8ff284ff9167eff8f5349481529332d59ed913b1
1947 .P
1948 In mmh, the attachment system is active by default.
1949 There are no command line switches anymore, but a pre-defined attachment
1950 header field.
1951 It is named
1952 .Hd Attach
1953 by default, but can be renamed with the
1954 .Pe Attachment-Header
1955 profile entry.
1956 To add an attachment to a draft, simply add an attachment header:
1957 .VS
1958 To: bob
1959 Subject: The file you wanted
1960 Attach: /path/to/the/file-bob-wanted
1961 --------
1962 Here it is.
1963 VE
1964 The header field can be added to the draft manually in the editor,
1965 by using the `attach' command at the WhatNow prompt, or with
1966 .Pn anno :
1967 .VS
1968 anno -append -nodate -component Attach -text /path/to/file
1969 VE
1970 Drafts with attachment headers are converted to MIME automatically
1971 on sending.
1972 The draft stored in the draft folder is always in source form with
1973 attachment headers.
1974 The convertion to MIME is done invisible to the user.
1975 If the MIMEification fails, for instance because the file to attach
1976 is not accessible, the original draft is not changed.
1977 .P
1978 Forwarding message is handled by the same attachment system.
1979 If the attachment header value starts with a plus character (`+'),
1980 like in
1981 .Cl "Attach: +bob 30 42" ,
1982 The given messages in the specified folder will be attached.
1983 This allowed to simplify
1984 .Pn forw .
1985 .Ci f41f04cf4ceca7355232cf7413e59afafccc9550
1986 .P
1987 Closely related to attachments is non-ASCII text content,
1988 because it requires MIME too.
1989 In nmh it the user needed to invoke `mime' at the WhatNow prompt
1990 to have the draft converted to MIME.
1991 This was necessary if the draft contained non-ASCII characters.
1992 If the user did not call `mime', a broken message would be sent.
1993 Therefore, the
1994 .Pe automimeproc
1995 profile entry could be specified to have the `mime' command invoked
1996 automatically for each message.
1997 Unfortunately, this approach conflicted with with attachment system
1998 because the draft would already be in MIME format at the time
1999 when the attachment system wanted to MIMEify it.
2000 To use the attachment system, the user must not run `mime' at the
2001 WhatNow prompt nor have
2002 .Pe automimeproc
2003 set in the profile.
2004 But then the case of non-ASCII text without attachment headers was
2005 not caught.
2006 All in all a bad solution.
2007 My patch from December 2010 already solved this situation.
2008 Mmh's current solution is even more elaborate.
2009 Any necessary MIMEification is done automatically.
2010 There is no `mime' command at the WhatNow prompt anymore.
2011 The draft will be converted to MIME when either an attachment header
2012 or non-ASCII text is present.
2013 Further more, the special meaning of the hash character (`#')
2014 at the beginning of the line in the draft message is removed.
2015 The user needs not at all deal about the topic.
2016 .P
2017 This improvement has a price: The new approach does not directly
2018 support arbitrary MIME compositions.
2019 Nonetheless, the full power of
2020 .Pn mhbuild
2021 can still be accessed.
2022 As long as no attachment headers are included, the user can create a
2023 nonlimited
2024 .Pn mhbuild
2025 composition draft like in nmh.
2026 Then, at the WhatNow prompt, he needs to invoke
2027 .Cl "edit mhbuild
2028 to convert it to MIME.
2029 Because the resulting draft does only contain ASCII characters
2030 and has no attachment headers, the attachment system will not touch it.
2031 .P
2032 The approach taken in mmh is taylored towards todays most common case:
2033 a text part with possibly attachments.
2034 Still, the full power of
2035 .Pn mhbuild
2036 can be accessed with a bit of overhead.
2037
2038 .\" XXX: MIME types
2039 .\" XXX: whatnow prompt commands
2040 .\" XXX: anno rework
1887 2041
1888 2042
1889 .H2 "Digital Cryptography 2043 .H2 "Digital Cryptography
1890 .P 2044 .P
1891 Signing and encryption. 2045 Signing and encryption.