Hello community, here is the log from the commit of package kmime for openSUSE:Factory checked in at 2020-08-18 11:58:57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/kmime (Old) and /work/SRC/openSUSE:Factory/.kmime.new.3399 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "kmime" Tue Aug 18 11:58:57 2020 rev:61 rq:826443 version:20.08.0 Changes: -------- --- /work/SRC/openSUSE:Factory/kmime/kmime.changes 2020-07-14 07:49:11.235827838 +0200 +++ /work/SRC/openSUSE:Factory/.kmime.new.3399/kmime.changes 2020-08-18 11:59:21.883368515 +0200 @@ -1,0 +2,24 @@ +Sun Aug 9 09:09:34 UTC 2020 - Christophe Giboudeaux <[email protected]> + +- Update to 20.08.0 + * New feature release + * For more details please see: + * https://kde.org/announcements/releases/2020-08-apps-update +- No code change since 20.07.90 + +------------------------------------------------------------------- +Sun Aug 2 07:59:54 UTC 2020 - Christophe Giboudeaux <[email protected]> + +- Update to 20.07.90 + * New feature release +- Changes since 20.07.80: + * Add autotest about invalid email + +------------------------------------------------------------------- +Sun Jul 19 10:05:01 UTC 2020 - Christophe Giboudeaux <[email protected]> + +- Update to 20.07.80 + * New feature release +- Too many changes to list here. + +------------------------------------------------------------------- Old: ---- kmime-20.04.3.tar.xz kmime-20.04.3.tar.xz.sig New: ---- kmime-20.08.0.tar.xz kmime-20.08.0.tar.xz.sig ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ kmime.spec ++++++ --- /var/tmp/diff_new_pack.OPaLyJ/_old 2020-08-18 11:59:24.315369584 +0200 +++ /var/tmp/diff_new_pack.OPaLyJ/_new 2020-08-18 11:59:24.319369586 +0200 @@ -21,7 +21,7 @@ %{!?_kapp_version: %define _kapp_version %(echo %{version}| awk -F. '{print $1"."$2}')} %bcond_without lang Name: kmime -Version: 20.04.3 +Version: 20.08.0 Release: 0 Summary: KDE PIM libraries MIME support License: LGPL-2.1-or-later ++++++ kmime-20.04.3.tar.xz -> kmime-20.08.0.tar.xz ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/.arcconfig new/kmime-20.08.0/.arcconfig --- old/kmime-20.04.3/.arcconfig 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/.arcconfig 1970-01-01 01:00:00.000000000 +0100 @@ -1,3 +0,0 @@ -{ - "phabricator.uri": "https://phabricator.kde.org/project/profile/34/"; -} diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/.gitlab-ci.yml new/kmime-20.08.0/.gitlab-ci.yml --- old/kmime-20.04.3/.gitlab-ci.yml 1970-01-01 01:00:00.000000000 +0100 +++ new/kmime-20.08.0/.gitlab-ci.yml 2020-08-02 10:19:20.000000000 +0200 @@ -0,0 +1,30 @@ +include: + - https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/ci-before.yml + - https://invent.kde.org/sysadmin/ci-tooling/raw/master/invent/ci-applications-linux.yml + +build_clazy_clang_tidy: + stage: build + image: kdeorg/ci-suse-qt514 + extends: .linux + #only: + # - merge_requests + before_script: + - zypper install -y clazy + - git clone --depth=1 https://invent.kde.org/sysadmin/ci-tooling.git $CI_TOOLING + - git clone --depth=1 https://invent.kde.org/sysadmin/repo-metadata.git $CI_TOOLING/repo-metadata + - git clone --depth=1 https://invent.kde.org/sysadmin/kde-build-metadata.git $CI_TOOLING/kde-build-metadata + - git clone --depth=1 https://invent.kde.org/sdk/kde-dev-scripts.git $CI_TOOLING/kde-dev-scripts + + script: + - export CXX=clazy + - export CC=clang + - export CXXFLAGS="-Wno-deprecated-declarations" + - export CLAZY_HEADER_FILTER='^(?!ui_)\w+.h\$' + - export CLAZY_CHECKS="level0,level1,detaching-member,ifndef-define-typo,isempty-vs-count,qrequiredresult-candidates,reserve-candidates,signal-with-return-value,unneeded-cast,function-args-by-ref,function-args-by-value,returning-void-expression,no-ctor-missing-parent-argument,isempty-vs-count,qhash-with-char-pointer-key,raw-environment-function,qproperty-type-mismatch,old-style-connect,qstring-allocations,container-inside-loop,heap-allocated-small-trivial-type,inefficient-qlist,qstring-varargs" + - python3 -u $CI_TOOLING/helpers/prepare-dependencies.py --product $PRODUCT --project $PROJECT --branchGroup $BRANCH_GROUP --environment production --platform $PLATFORM --installTo $INSTALL_PREFIX + - python3 -u $CI_TOOLING/helpers/configure-build.py --product $PRODUCT --project $PROJECT --branchGroup $BRANCH_GROUP --platform $PLATFORM --installTo $INSTALL_PREFIX + - python3 -u $CI_TOOLING/helpers/compile-build.py --product $PRODUCT --project $PROJECT --branchGroup $BRANCH_GROUP --platform $PLATFORM --usingInstall $INSTALL_PREFIX + - cd build && run-clang-tidy + variables: + PLATFORM: SUSEQt5.14 + BRANCH_GROUP: kf5-qt5 diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/CMakeLists.txt new/kmime-20.08.0/CMakeLists.txt --- old/kmime-20.04.3/CMakeLists.txt 2020-07-07 03:07:08.000000000 +0200 +++ new/kmime-20.08.0/CMakeLists.txt 2020-08-07 09:07:57.000000000 +0200 @@ -1,10 +1,10 @@ cmake_minimum_required(VERSION 3.5) -set(PIM_VERSION "5.14.3") +set(PIM_VERSION "5.15.0") project(KMime VERSION ${PIM_VERSION}) # ECM setup -set(KF5_MIN_VERSION "5.68.0") +set(KF5_MIN_VERSION "5.71.0") find_package(ECM ${KF5_MIN_VERSION} CONFIG REQUIRED) set(CMAKE_MODULE_PATH ${KMime_SOURCE_DIR}/cmake ${ECM_MODULE_PATH}) @@ -23,7 +23,7 @@ set(KMIME_LIB_VERSION ${PIM_VERSION}) -set(QT_REQUIRED_VERSION "5.12.0") +set(QT_REQUIRED_VERSION "5.13.0") find_package(Qt5 ${QT_REQUIRED_VERSION} CONFIG REQUIRED Core) ecm_setup_version(PROJECT VARIABLE_PREFIX KMIME @@ -36,10 +36,10 @@ find_package(KF5I18n ${KF5_MIN_VERSION} CONFIG REQUIRED) find_package(KF5Codecs ${KF5_MIN_VERSION} CONFIG REQUIRED) add_definitions(-DTRANSLATION_DOMAIN=\"libkmime5\") -if (EXISTS "${CMAKE_SOURCE_DIR}/.git") - add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x050e00) - add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054400) -endif() +add_definitions(-DQT_DISABLE_DEPRECATED_BEFORE=0x050f00) +add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054800) +set(CMAKE_CXX_STANDARD 14) +set(CMAKE_CXX_STANDARD_REQUIRED ON) ########### Targets ########### add_subdirectory(src) diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/README.md new/kmime-20.08.0/README.md --- old/kmime-20.04.3/README.md 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/README.md 2020-08-02 10:19:20.000000000 +0200 @@ -6,19 +6,18 @@ KMime is a library for handling mail messages and newsgroup articles. Both mail messages and newsgroup articles are based on the same standard called MIME, which stands for -**Multipurpose Internet Mail Extensions**. In this document, the term `message` is used to +**Multipurpose Internet Mail Extensions**. In this document, the term *message* is used to refer to both mail messages and newsgroup articles. -KMime deals solely with the in-memory representation of messages, topics such a transport or storage +KMime deals solely with the in-memory representation of messages. Topics such as transport or storage of messages are handled by other libraries, for example by [the mailtransport library](https://api.kde.org/kdepim/kmailtransport/html/index.html) or by [the KIMAP library](https://api.kde.org/kdepim/kimap/html/index.html). -Similary, this library does not deal with displaying messages or advanced composing, for those there -are the [messageviewer](http://api.kde.org/4.x-api/kdepim-apidocs/messageviewer/html/index.html) -and the [messagecomposer](https://websvn.kde.org/trunk/KDE/kdepim/messagecomposer/";) -components in the KDEPIM module. +Similarly, this library does not deal with displaying messages or advanced composing, for those there +are the messageviewer and messagecomposer +components in the KDE PIM [messagelib](https://api.kde.org/kdepim/messagelib/html/index.html) module. KMime's main function is to parse, modify and assemble messages in-memory. In a -[later section](@ref string-broken-down), *parsing* and *assembling* is actually explained. +[later section](@ref string-broken-down), *parsing* and *assembling* are actually explained. KMime provides high-level classes that make these tasks easy. MIME is defined by various RFCs, see the [RFC section](@ref rfcs) for a list of them. @@ -27,8 +26,8 @@ This document will first give an [introduction to the MIME specification](@ref mime-intro), as it is essential to understand the basics of the structure of MIME messages for using this library. -The introduction here is aimed at users of the library, it gives a broad overview with examples and -omits some details. Developers who wish to modifiy KMime should read the +The introduction here is aimed at users of the library. It gives a broad overview with examples and +omits some details. Developers who wish to modify KMime should read the [corresponding RFCs](@ref rfcs) as well, but this is not necessary for library users. After the introduction to the MIME format, the two ways of representing a message in memory are @@ -46,7 +45,7 @@ The MIME standard is quite new (1993), email and usenet existed way before the MIME standard came into existence. Because of this, the MIME standard has to keep backwards compatibility. The email -standard before MIME lacked many capabilities like encodings other than ASCII or attachments. These +standard before MIME lacked many capabilities, like encodings other than ASCII, or attachments. These and other things were later added by MIME. The standard for messages before MIME is defined in [RFC 5233](https://tools.ietf.org/html/rfc5322). In [RFC 2045](https://tools.ietf.org/html/rfc2045) to [RFC 2049](https://tools.ietf.org/html/rfc2049), several backward-compatible extensions @@ -55,16 +54,16 @@ Actually, there is an even older standard, defined in [RFC 733](https://tools.ietf.org/html/rfc733) (*Standard for the format of ARPA network text messages*, introduced in 1977). -This standard is now obsoleted by RFC 5322, but backwards compatibilty is in some cases supported, as +This standard is now obsoleted by RFC 5322, but backwards compatibility is in some cases supported, as there are still messages in this format around. Since pre-MIME messages had no way to handle attachments, attachments were sometimes added to the message text in an [uuencoded](https://en.wikipedia.org/wiki/Uuencoding) form. Although this is also obsolete, reading uuencoded attachments is still supported by KMime. -After MIME was introduced, people realized that there is no way to have the filename of attachments -encoded in anything different than ASCII. Thus, [RFC 2231](https://tools.ietf.org/html/rfc2231) -was introduced to allow abitrary encodings for parameter values, such as the attachment filename. +After MIME was introduced, people realized that there was no way to have the filename of attachments +encoded in anything other than ASCII. Thus, [RFC 2231](https://tools.ietf.org/html/rfc2231) +was introduced to allow arbitrary encodings for parameter values, such as the attachment filename. ## MIME by examples ## {#examples} @@ -83,13 +82,13 @@ Hello World! The above example features a very simple message. The two main parts of this message are the **header** -and the **body**, which are seperated by an empty line. The body contains the actual message content, +and the **body**, which are separated by an empty line. The body contains the actual message content, and the header contains metadata about the message itself. The header consists of several **header fields**, each of them in their own line. Header fields are made up from the **header field name**, followed by a colon, followed by the **header field body**. The **MIME-Version** header field is mandatory for MIME messages. **Subject**, -**From** and **Date** are important header fields, they are usually displayed in the message list of a +**From** and **Date** are important header fields; they are usually displayed in the message list of a mail client. The `Subject` header field can be anything, it does not have a special structure. It is a so-called **unstructured** header field. In contrast, the `From` and the `Date` header fields have to follow a special structure, they must be formed in a way that machines can parse. They are **structured** @@ -98,18 +97,18 @@ The exact details of how the header field bodies of structured header fields should be formed are specified in an RFC. -In this example, the `From` header contains a single email address. More precisly, a single email address is called +In this example, the `From` header contains a single email address. More precisely, a single email address is called a **mailbox**, which is made up of the **display name** (John Doe) and the **address specification** ([email protected]), which is enclosed in angle brackets. The `addr-spec` consists of the user name, the **local part**, and the **domain** name. Many header fields can contain multiple email addresses, for example the `To` field for messages with -multiple recipients can have a comma-seperated list of mailboxes. +multiple recipients can have a comma-separated list of mailboxes. A list of mailboxes, together with a display name for the list, forms a **group**, and multiple groups can form an **address list**. This is however rarely used, you'll most often see a simple list of plain mailboxes. There are many more possible header fields than shown in this example, and the header can even contain -abitrary header fields, which usually are prefixed with `X-`, like `X-Face`. +arbitrary header fields, which usually are prefixed with `X-`, like `X-Face`. ### Encodings and charsets ### {#encodings} @@ -139,7 +138,7 @@ byte arrays, and the other way around. A message is nothing else than a big array of bytes. The bytes that form the body of the message somehow need to be interpreted as a text string. Interpreting a byte array as a text string is called **decoding** the text. Converting a text string to a byte array is called -\b encoding the text. A **codec** (**co**der-**dec**oder) is a utility that can encode and decode text. +**encoding** the text. A **codec** (**co**der-**dec**oder) is a utility that can encode and decode text. In Qt, the class for text strings is QString, and the class for byte arrays is QByteArray. The base class of all codecs is QTextCodec. @@ -158,9 +157,9 @@ Now, what if we want to write a message that contains German umlauts or Chinese letters? Those are not in the ASCII table, therefore a different charset has to be used. There is a wealth of charsets -to chose from. Not all charsets can handle all letters, for example the +to choose from. Not all charsets can handle all letters, for example the [ISO-8859-1](https://en.wikipedia.org/wiki/ISO-8859-1#ISO-8859-1) charset can handle -German umlauts, but can not handle Chinese or Arabic letters. The [Unicode standard](https://en.wikipedia.org/wiki/Unicode) +German umlauts, but cannot handle Chinese or Arabic letters. The [Unicode standard](https://en.wikipedia.org/wiki/Unicode) is an attempt to introduce charsets that can handle all known letters in the world, in all languages. Unicode actually has several charsets, for example [UTF-8](https://en.wikipedia.org/wiki/UTF-8) and [UTF-16](https://en.wikipedia.org/wiki/UTF-16). In an ideal world, everyone would be using @@ -174,7 +173,7 @@ on the charset. One can **not** rely on the `1 letter == 1 byte` assumption. Now, what should be done when the text string "Grüezi Welt!" should be sent in the body of a message? -The first step is to chose a charset that can represent all letters. This already excludes US-ASCII. +The first step is to choose a charset that can represent all of its letters. This already excludes US-ASCII. Once a charset is chosen, the text string is encoded into a byte array. "Grüezi Welt!" encoded with the ISO-8859-1 charset produces the following byte array: @@ -192,12 +191,12 @@ letters. Then save the file and view it in a hex editor to see how the text was converted to a byte array. Make sure to try out setting different charsets in your text editor. -At this point, the text string is sucessfully converted to a byte array, using e.g. the ISO-8859-1 +At this point, the text string is successfully converted to a byte array, using e.g. the ISO-8859-1 charset. To indicate which charset was used, a **Content-Type** header field has to be added, with the correct **charset** parameter. In our example above, that was done. If the charset parameter of the `Content-Type`, or even the complete `Content-Type` header field is left out, the receiver can not know how to interpret the byte array! In these cases, the byte array is usually decoded incorrectly, and the text strings contain -wrong letters or lots of questionmarks. There is even a special term for such wrongly decoded text, +wrong letters or lots of question marks. There is even a special term for such wrongly decoded text, [Mojibake](https://en.wikipedia.org/wiki/Mojibake). It is important to always know what charset your byte array is encoded with, otherwise an attempt at decoding the byte array into a text string will fail and produce Mojibake. **There is no such thing as plain text!** If there is no `Content-Type` header field in @@ -241,7 +240,7 @@ There are two other content transfer encodings besides quoted printable and base64: **7-bit** and **8-bit**. 7-bit is just a marker to indicate that no content transfer encoding is used. This is the -case when the byte array is already completley in the 7-bit range, for example when writing English +case when the byte array is already completely in the 7-bit range, for example when writing English text using the US-ASCII charset. 8-bit is also a marker to indicate that no content transfer encoding was used. This time, not because it was not necessary, but because of a special exception, byte values outside of the 7-bit range are allowed. For example, some SMTP servers support the @@ -339,8 +338,8 @@ The `Content-Type` and the `Content-Transfer-Encoding` header fields only apply to the message body, they have no meaning for other header fields. -This means that any letter in a different charset has to be encoded in some way to statisfy the RFC. -Letters with a different charset are only allowed in some of the header field bodies, the header field +This means that any letter in a different charset has to be encoded in some way to satisfy the RFC. +Letters with a different charset are only allowed in some of the header field bodies; the header field names always have to be in US-ASCII. From: Thomas McGuire <[email protected]> @@ -358,8 +357,8 @@ in the message header. This can be seen in the bodies of the `Subject` header field and the `To` header field. In this example, the body of the message is unimportant, it is just "bla bla bla" in US-ASCII. The way the header field bodies are encoded is sometimes referred to as a **RFC2047 string** or as an **encoded word**, which has -the origin in the [RFC](https://tools.ietf.org/html/rfc2047) where this encoding scheme is defined. -RFC2047 strings are only allowed in some of the header fields, like `Subject` and in the display name +its origin in the [RFC](https://tools.ietf.org/html/rfc2047) where this encoding scheme is defined. +RFC2047 strings are only allowed in some of the header fields, like `Subject`, and in the display name of mailboxes in header fields like `From` and `To`. In other header fields, such as `Date` and `MIME-Version`, they are not allowed, but they wouldn't make much sense there anyway, since those are structured header fields with a clearly defined structure. @@ -369,7 +368,7 @@ * The encoding, which is "q" or "b" * The encoded text -These three parts are sperated with a '?'. Encoding the third part, the text, is very similar to how +These three parts are separated with a '?'. Encoding the third part, the text, is very similar to how text strings in the message body are encoded: First, the text string is encoded to a byte array using the charset encoding. Afterwards, the second encoding is used on the result, to ensure that all resulting bytes are within the 7-bit range. @@ -394,11 +393,11 @@ In the `To` header field, two RFC2047 strings are used. A single, bigger, RFC2047 string for the whole display name could also have been used. In this case, the second RFC2047 string starts with an underscore, which is decoded as a space in the `q` encoding. The space between the two RFC2047 strings is ignored, -it is just used to seperate the two encoded words. +it is just used to separate the two encoded words. There are some restriction on RFC2047 strings: They are not allowed to be longer than 75 characters, which means two or more encoded words have to be used for long text strings. Also, there are some -restrictions on where RFC2047 strings are allowed; most importantly, the address specification must no +restrictions on where RFC2047 strings are allowed; most importantly, the address specification must not be encoded, to be backwards compatible. For further details, refer to the RFC. ### Messages with attachments ### {#multipart-mixed} @@ -444,18 +443,18 @@ it is just a random mixture of parts. Later, we will look at other types, such as `multipart/alternative` or `multipart/related`. A **part** is sometimes also called **node**, **content** or **MIME part**. -Each MIME part of the message is seperated by a **boundary**, and that boundary +Each MIME part of the message is separated by a **boundary**, and that boundary is specified in the top-level content-type header as a parameter. In the message body, the boundary is prefixed with `"--"`, and the last boundary is suffixed with `"--"`, so that the end of the message can be detected. When creating a message, care must be taken that the boundary appears nowhere else in the message, for example in the text part, as the parser would get confused by this. A MIME part begins right after the boundary. It consists of a **MIME header** and a **MIME body**, which -are seperated by an empty line. The MIME header should not be confused with the message header: The +are separated by an empty line. The MIME header should not be confused with the message header: The message header contains metadata about the whole message, like subject and date. The MIME header only contains metadata about the specific MIME part, like the content type of the MIME part. MIME header field names always start with `"Content-"`. -The example above shows the three most important MIME header fields, usually those are the only ones +The example above shows the three most important MIME header fields. Usually those are the only ones used. The top-level header of a message actually mixes the message metadata and the MIME metadata into one header: In this example, the header contains the `Date` header field, which is an ordinary header field, and it contains the `Content-Type` header field, which is a MIME header field. @@ -469,14 +468,14 @@ The `text/plain` node is therefore a `child` of the `multipart/mixed` node. The `multipart/mixed` node is a `parent` of the other two nodes. The `image/jpeg` node is a **sibling** of the `text/plain` node. `Multipart` nodes are the only nodes that have children, other nodes are **leaf** nodes. -The body of a multipart node consists of all complete child nodes (MIME header and MIME body), seperated +The body of a multipart node consists of all complete child nodes (MIME header and MIME body), separated by the boundary. Each MIME part can have a different content transfer encoding. In the above example, the text part has -a `7bit` CTE, while the image part has a `base64` CTE. The multipart/mixed node does not specifiy +a `7bit` CTE, while the image part has a `base64` CTE. The multipart/mixed node does not specify a CTE, multipart nodes always have `7bit` as the CTE. This is because the body of multipart nodes can only consist of bytes in the 7 bit range: The boundary is 7 bit, the MIME headers are 7 bit, and the -MIME bodies are already ancoded with the CTE of the child MIME part, and are therefore also 7 bit. This means +MIME bodies are already encoded with the CTE of the child MIME part, and are therefore also 7 bit. This means no CTE for multipart nodes is necessary. The MIME part for the image does not specify a charset parameter in the content type header field. This @@ -496,9 +495,9 @@ The content type header field for the image MIME part has a **name** parameter, which is similar to the `filename` parameter of the `Content-Disposition` header field. The difference is that `name` refers to the name of the complete MIME part, whereas `filename` refers to the name of the attachment. The -`name` paramter of the `Content-Type` header field in this case is superfluous and only exists for +`name` parameter of the `Content-Type` header field in this case is superfluous and only exists for backwards compatibility, and can be ignored; -the `filename` parameter of the `Content-Disposition` header field should be prefered when it is present. +the `filename` parameter of the `Content-Disposition` header field should be preferred when it is present. From: Thomas McGuire <[email protected]> To: [email protected] @@ -547,7 +546,7 @@ --Boundary-00=_PjtiLU2PvHpvp/R-- The above example message consists of three MIME parts: The main text part and two attachments. -One attachment has the media type \c text, therefore a charset parameter is necessary to correctly +One attachment has the media type `text`, therefore a charset parameter is necessary to correctly display it. The MIME tree looks like this: multipart/mixed @@ -586,7 +585,7 @@ </html> --Boundary-01=_m66jLd2/vZrH5oe-- -The above example is a simple HTML message, it consists of a plain text and a HTML part, which are +The above example is a simple HTML message. It consists of a plain text and a HTML part, which are in a **multipart/alternative** container. The message has the following structure: multipart/alternative @@ -595,12 +594,12 @@ The HTML part and the plain text part have the identical content, except that the HTML part contains additional markup, in this case for displaying the word `World` in bold. Since those parts are in a -multipart/alternative container, the message viewer application can freely chose which part it displays. +multipart/alternative container, the message viewer application can freely choose which part it displays. Some users might prefer reading the message in HTML format, some might prefer reading the message in plain text format. Of course, a HTML message could also consist only of a single `text/html`, without the multipart/alternative -container and therefore without an alternative plain text part. However, people prefering the plain +container and therefore without an alternative plain text part. However, people preferring the plain text version wouldn't like this, especially if their mail client has no HTML engine and they would see the HTML source including all tags only. Therefore, HTML messages should always include an alternative plain text part. @@ -668,14 +667,14 @@ the `img` tag occurs, which is called an **inline image**. Note that inline images are different from images that are just normal attachments: Normal attachments are always shown at the beginning or at the end of the message, while inline images are shown in-place. In HTML, the `img` tag points to an -image file that is either a file on disk or an URL to an image on the Internet. To make inline images +image file that is either a file on disk or a URL of an image on the Internet. To make inline images work with MIME messages, a different mechanism is needed, since the image is not a file on disk or on the Internet, but a MIME part somewhere in the same message. As specified in -[RFC 2557](https://tools.ietf.org/html/rfc2557), the way this can be done is by refering +[RFC 2557](https://tools.ietf.org/html/rfc2557), the way this can be done is by referring to a **Content-ID** in the `img` tag, and marking the MIME part that is the image with that content ID as well. -An example will probably be more clear than this explaination: +An example will probably be more clear than this explanation: From: Thomas McGuire <[email protected]> Subject: Inine Image Test @@ -742,7 +741,7 @@ to the Content-Id header of another part. The image part contains exactly that value in its `Content-Id` header, and therefore a message viewer application can connect both. -The plain text part can not have inline images, therefore its text might seem a bit confusing. +The plain text part cannot have inline images, therefore its text might seem a bit confusing. HTML messages with inline images can of course also have attachments, in which the message structure becomes a mix of multipart/related, multipart/alternative and multipart/mixed. The following example @@ -757,13 +756,13 @@ | \- image/png \- application/x-compressed-tar -The structure of MIME messages can get arbitrarily complex, the above is just one relativley simply example. +The structure of MIME messages can get arbitrarily complex, the above is just one relatively simple example. The nesting of multipart nodes can get much deeper, there is no restriction on nesting levels. ### Encapsulated messages ### {#encapsulated} Encapsulated messages are messages which are attachments to another message. The most common example -is a forwareded mail, like in this example: +is a forwarded mail, like in this example: From: Frank <[email protected]> To: Bob <[email protected]> @@ -805,7 +804,6 @@ |- text/plain \- message/rfc822 \- text/plain - \endverbatim The attached message is treated like any other attachment, and therefore the top-level content type is multipart/mixed. @@ -819,28 +817,28 @@ ### Signed and Encrypted Messages ### {#crypto} MIME messages can be cryptographically signed and/or encrypted. The format for those messages is -defined in [RFC 1847](https://tools.ietf.org/html/rfc1847, which specifies two new +defined in [RFC 1847](https://tools.ietf.org/html/rfc1847), which specifies two new multipart subtypes, **multipart/signed** and **multipart/encrypted**. The crypto format of these new security multiparts is defined in additional RFCs; the most common formats are [OpenPGP](https://tools.ietf.org/html/rfc3156) and [S/MIME](https://tools.ietf.org/html/rfc2633). Both formats use the principle of [public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography). -OpenPGP uses **key**s, and S/MIME uses **certificates**. For easier text flow, only the term `key` will be used +OpenPGP uses **keys**, and S/MIME uses **certificates**. For easier text flow, only the term `key` will be used for both keys and certificates in the text below. -Security multiparts only sign or encrypt a specifc MIME part. The consequence is that the message headers +Security multiparts only sign or encrypt a specific MIME part. The consequence is that the message headers can not be signed or encrypted. Also this means that it is possible to sign or encrypt only some of the MIME parts of a message, while leaving other MIME parts unsigned or unencrypted. Furthermore, it is possible to sign or encrypt different MIME parts with different crypto formats. As you can see, security multiparts are very flexible. Security multiparts are not supported by KMime. However, it is possible for applications to use KMime -when providing support for crypto messages. For example, the [messageviewer](http://api.kde.org/4.x-api/kdepim-apidocs/messageviewer/html/index.html) -component in KDEPIM supports signed and encrypted MIME parts, and the -[messagecomposer](https://websvn.kde.org/trunk/KDE/kdepim/messagecomposer/) library can create +when providing support for crypto messages. For example, the messageviewer +component in KDE PIM's [messagelib](https://api.kde.org/kdepim/messagelib/html/index.html) supports signed and encrypted MIME parts, and the +messagecomposer library can create such messages. -Signed MIME parts are signed with the private key of the sender, everybody who has the -public key of the sender can verifiy the signature. Encrypted MIME parts are encrypted with the public +Signed MIME parts are signed with the private key of the sender, and everybody who has the +public key of the sender can verify the signature. Encrypted MIME parts are encrypted with the public key of the receiver, and only the receiver, who is the sole person possessing the private key, can decrypt it. Sending an encrypted message to multiple recipients therefore means that the message has to be sent multiple times, once for each receiver, as each message needs to be encrypted with a different key. @@ -947,7 +945,6 @@ -----END PGP MESSAGE----- - \verbatim multipart/encrypted |- application/pgp-encrypted \- application/octet-stream @@ -956,14 +953,14 @@ the data, it is unknown what the original content type of the encrypted MIME data is! The encrypted data could be a simple text/plain MIME part, an image attachment, or a multipart part. The encrypted data contains both the MIME header and the MIME body of the original MIME part, as the header is needed -to know the content type of the data. The data could as well by of content type multipart/signed, in +to know the content type of the data. The data could as well be of content type multipart/signed, in which case the message would be both signed and encrypted. -#### iNLINE CRYPTO FORMATS #### +#### Inline Crypto Formats #### Although using the security multiparts `multipart/signed` and `multipart/encrypted` is the recommended standard, there are other possibilities to sign or encrypt a message. The most common methods are -**Inline OpenPGP** and **S/MIME Opaque<**. +**Inline OpenPGP** and **S/MIME Opaque**. For inline OpenPGP messages, the crypto data is contained inlined in the actual MIME part. For example, a message with a signed text/plain part might look like this: @@ -988,8 +985,6 @@ WIoAn3PjVPlWibu02dfdFObwd2eJ1jAW =p3uO -----END PGP SIGNATURE----- - - \endverbatim Encrypted inline OpenPGP works in a similar way. Opaque S/MIME messages are also similar: For signed MIME parts, both the signature and the signed data are contained in a single MIME part with a content @@ -1003,8 +998,8 @@ #### Line Breaks #### Each line in a MIME message has to end with a **CRLF**, which is a carriage return followed by a -newline, which is the escape sequence`\\r\\n`. CR and LF may not appear in other places in -a MIME message. Special care needs to be taken with encoded linebreaks in binary data, and with +newline, which is the escape sequence `\\r\\n`. CR and LF may not appear in other places in +a MIME message. Special care needs to be taken with encoded line breaks in binary data, and with distinguishing soft and hard line breaks when converting between different content transfer encodings. For more details, have a look at the RFCs. @@ -1022,7 +1017,7 @@ **folded** in this case. In general, header fields can be folded whenever whitespace (**WS**) occurs. Header field values can contain **comments**; these comments are semantically invisible and have no -meaning. Comments are surrouned by parentheses. +meaning. Comments are surrounded by parentheses. Date: Thu, 13 Feb 1969 23:32 -0330 (Newfoundland Time) @@ -1030,7 +1025,7 @@ This example shows a folded header that also has a comment (*Newfoundland Time*). The date header is a structured header field, and therefore it has to obey to a defined syntax; however, adding comments and whitespace is allowed almost anywhere, and they are ignored when parsing the message. Comments and whitespace where -folding is allowed is sometimes referred to as \b CFWS. Any occurence of CFWS is semantically regarded +folding is allowed is sometimes referred to as **CFWS**. Any occurrence of CFWS is semantically regarded as a single space. # The two in-memory representations of messages # {#string-broken-down } @@ -1038,8 +1033,8 @@ There are two representations of messages in memory. The first is called **string representation** and the other one is called **broken-down representation**. -String representation is somehow misnamed, -a better term would be `byte array representation`. The string representation is just a big array of +String representation is somewhat misnamed, +a better term would be "byte array representation". The string representation is just a big array of bytes in memory, and those bytes make up the encoded mail. The string representation is what is stored on disk or what is received from an IMAP server, for example. @@ -1049,11 +1044,11 @@ is just an array of 7 bit characters that might be encoded, the broken-down representations contain the decoded text strings. -As an example, conside the byte array +As an example, consider the byte array "Hugo Maier" <[email protected]> -Although this is just a bunch of 7 bit characters, a human immediatley recognizes the broken-down structure and +Although this is just a bunch of 7 bit characters, a human immediately recognizes the broken-down structure and sees that the display name is "Hugo Maier" and that the localpart of the email address is "hugo.maier". To illustrate, the broken-down structure could be stored in a structure like this: @@ -1074,11 +1069,11 @@ On the other hand, assembling a message is for example done in the composer of a mail application, where the mail information is available in a broken-down form in the composer window, and is then assembled into a final MIME message that is then sent with SMTP. -Parsing is often quite tricky, you should always use the methods from KMime instead of writing parsing -routines yourself. Even the simple mailbox example above is in pratice difficult to parse, as many things like comments +Parsing is often quite tricky. You should always use the methods from KMime instead of writing parsing +routines yourself. Even the simple mailbox example above is in practice difficult to parse, as many things like comments and escaped characters need to be taken into consideration. The same is true for assembling: In the above case, one could be tempted to assemble the mailbox by simply -writting code like this: +writing code like this: QByteArray stringRepresentation = '"' + displayName + "\" <" + addressSpec + ">"; @@ -1103,17 +1098,17 @@ There is also a class `KMime::Message`, which basically is a thin wrapper around Content for the top-level MIME part. Message also contains convenience methods to access the message headers. -For headers, there is a class hierachy, with `KMime::Headers::Base` as the base class, and -`KMime::Headers::Generics::Structured` and KMime::Headers::Generics::Unstructured` in the next levels. Unstructured is +For headers, there is a class hierarchy, with `KMime::Headers::Base` as the base class, and +`KMime::Headers::Generics::Structured` and `KMime::Headers::Generics::Unstructured` in the next levels. Unstructured is for headers that don't have a defined structure, like Subject, whereas Structured headers have a -specific structure, like Date. The header classes have methods to parse headers, like from7BitString(), -and to assemble them, like as7BitString(). Once a header is parsed, the classes provide access to the -broken-down structures, for example the Date header has a method dateTime(). -The parsing in from7BitString() is usually handled by a protected parse() function, which in turn call -parsing functions for different types, like parseAddressList() or parseAddrSpec() from the `KMime::HeaderParsing` +specific structure, like Date. The header classes have methods to parse headers, like `from7BitString()`, +and to assemble them, like `as7BitString()`. Once a header is parsed, the classes provide access to the +broken-down structures; for example the `Date` header has a method `dateTime()`. +The parsing in `from7BitString()` is usually handled by a protected `parse()` function, which in turn call +parsing functions for different types, like `parseAddressList()` or `parseAddrSpec()` from the `KMime::HeaderParsing` namespace. -When modifing messages, the message is first parsed into a broken-down representation. This broken-down +When modifying messages, the message is first parsed into a broken-down representation. This broken-down representation can then be accessed and modified with the appropriate functions. After changing the broken-down structure, it needs to be assembled again to get the modified string representation. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/CMakeLists.txt new/kmime-20.08.0/autotests/CMakeLists.txt --- old/kmime-20.04.3/autotests/CMakeLists.txt 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/autotests/CMakeLists.txt 2020-08-02 10:19:20.000000000 +0200 @@ -1,6 +1,5 @@ include(ECMMarkAsTest) -set(QT_REQUIRED_VERSION "5.9.0") find_package(Qt5Test ${QT_REQUIRED_VERSION} CONFIG REQUIRED) # Turn exceptions on diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/contenttest.cpp new/kmime-20.08.0/autotests/contenttest.cpp --- old/kmime-20.04.3/autotests/contenttest.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/autotests/contenttest.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -302,8 +302,8 @@ "body\n"; msg->setContent(data); QByteArray content = msg->encodedContent(true /* use CRLF */); - QStringList lines = QString::fromLatin1(content).split(QStringLiteral("\r\n")); - foreach (const QString &line, lines) { + const QStringList lines = QString::fromLatin1(content).split(QStringLiteral("\r\n")); + for (const QString &line : lines) { QEXPECT_FAIL("", "KMime does not fold lines longer than 998 characters", Continue); QVERIFY(line.length() < 998 && !line.isEmpty() && line != QLatin1String("body")); // The test should be (after the expected failure disappears): @@ -880,15 +880,15 @@ QFETCH(QList<QByteArray> , contentMimeType); // test parsing - Message *msg = new Message(); - msg->setContent(data); - msg->parse(); + Message msg; + msg.setContent(data); + msg.parse(); QEXPECT_FAIL("broken", "Problem with content type", Continue); - QCOMPARE(msg->contentType(false)->mimeType(), mimetype); - QCOMPARE(msg->contents().count(), contentCount); - for (int i = 0; i < msg->contents().count(); ++i) { - QVERIFY(msg->contents().at(i)->contentType(false)); + QCOMPARE(msg.contentType(false)->mimeType(), mimetype); + QCOMPARE(msg.contents().count(), contentCount); + for (int i = 0; i < msg.contents().count(); ++i) { + QVERIFY(msg.contents().at(i)->contentType(false)); QCOMPARE(contentMimeType.count(), contentCount); - QCOMPARE(msg->contents().at(i)->contentType(false)->mimeType(), contentMimeType.at(i)); + QCOMPARE(msg.contents().at(i)->contentType(false)->mimeType(), contentMimeType.at(i)); } } diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/data/mails/crash-invalid-email-reply.mbox new/kmime-20.08.0/autotests/data/mails/crash-invalid-email-reply.mbox --- old/kmime-20.04.3/autotests/data/mails/crash-invalid-email-reply.mbox 1970-01-01 01:00:00.000000000 +0100 +++ new/kmime-20.08.0/autotests/data/mails/crash-invalid-email-reply.mbox 2020-08-02 10:19:20.000000000 +0200 @@ -0,0 +1,90 @@ +Return-Path: <[email protected]> +Delivered-To: [email protected] +Received: from tsubame.dennogumi.org ([fd4d:6169:6c63:6f77::e]) + by tsubame.dennogumi.org with LMTP + id 3amHL+oQDF8tFwAAISz+BA + (envelope-from <[email protected]>) + for <[email protected]>; Mon, 13 Jul 2020 09:44:42 +0200 +Received: from letterbox.kde.org (letterbox.kde.org [46.43.1.242]) + (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) + key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) + (No client certificate requested) + by tsubame.dennogumi.org (Postcow) with ESMTPS id 63446300E9D71 + for <[email protected]>; Mon, 13 Jul 2020 09:44:40 +0200 (CEST) +Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) + by letterbox.kde.org (Postfix) with ESMTPS id 7400F294FE4 + for <[email protected]>; Mon, 13 Jul 2020 08:44:30 +0100 (BST) +Authentication-Results: letterbox.kde.org; spf=pass [email protected] +Received: from auth by ciao.gmane.io with local (Exim 4.92) + (envelope-from <[email protected]>) + id 1jut8X-0003Ym-4p + for [email protected]; Mon, 13 Jul 2020 09:44:29 +0200 +From: Gmane Autoauthorizer <[email protected]> +To: [email protected] +References: <[email protected]> +Subject: Re: Authorization required to post to gmane.network.wireguard (b96565298414a43aabcf9fbedf5e7e27) +Message-Id: <[email protected]> +Date: Mon, 13 Jul 2020 09:44:29 +0200 +X-Scanned-By: MIMEDefang 2.83 on 46.43.1.242 +ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; + d=heavensinferno.net; s=mail; t=1594626280; + h=from:from:reply-to:subject:subject:date:date:message-id:message-id: + to:to:cc:references:references; + bh=42vAJETfmU/IpTMttSJL1ahUgLtDdi6GBDNwHvo3eu8=; + b=lPwv+oL0kA8J5U6Itmmv6pX9fHNZHaU8kiDIKW2/ate8aa4UCX4uxz5tO3J7snBwK9N//6 + nHewL7HvArUYq/KkrhqLd1kzlT5q5NVV41i8XDVOz2Y+ZF5nj5EqanCDRqH3Ue4U8GDKuE + +Zub5iTupGhk7r/28WldSDIZRniE9Dw= +ARC-Seal: i=1; s=mail; d=heavensinferno.net; t=1594626280; a=rsa-sha256; + cv=none; + b=HQlzMStsIbb0HsinnhgY0GBIw/khoZx+r4yAg+OEVV73FLrBtBWAizIAWskH0iB9vcP51o + ynf8OZMnKQTp6pYz3Pt3N4PJvaOQuIaQWLQxTPaVY5IkbxOKkFf0EpjWNFQF8a8rmGyK8W + Li3qOFS3pLab5INkAQ3glvftbiJw+0Q= +ARC-Authentication-Results: i=1; + tsubame.dennogumi.org; + dkim=none; + spf=fail (tsubame.dennogumi.org: domain of [email protected] does not designate 46.43.1.242 as permitted sender) [email protected] +X-Last-TLS-Session-Version: TLSv1.3 +Authentication-Results: tsubame.dennogumi.org; + dkim=none; + dmarc=none; + spf=fail (tsubame.dennogumi.org: domain of [email protected] does not designate 46.43.1.242 as permitted sender) [email protected] +X-Rspamd-Queue-Id: 63446300E9D71 +X-Spamd-Result: default: False [9.04 / 25.00]; + ARC_NA(0.00)[]; + RCPT_WANTS_SUBFOLDER_TAG(0.00)[[email protected]]; + FROM_HAS_DN(0.00)[]; + BAYES_SPAM(0.00)[18.65%]; + GREYLIST(0.00)[pass,meta]; + MIME_GOOD(-0.10)[text/plain]; + PREVIOUSLY_DELIVERED(0.00)[[email protected]]; + TO_DN_NONE(0.00)[]; + RCPT_COUNT_ONE(0.00)[1]; + NEURAL_HAM_LONG(-2.27)[-0.567]; + RCVD_COUNT_THREE(0.00)[3]; + ARC_SIGNED(0.00)[i=1]; + RCVD_IN_DNSWL_MED(-0.20)[46.43.1.242:from]; + MX_GOOD(-0.01)[]; + DMARC_NA(0.00)[gmane-mx.org]; + NEURAL_HAM_SHORT(-0.38)[-0.188]; + RCPT_MAILCOW_DOMAIN(0.00)[heavensinferno.net]; + FROM_EQ_ENVFROM(0.00)[]; + MIME_TRACE(0.00)[0:+]; + ASN(0.00)[asn:35425, ipnet:46.43.0.0/18, country:GB]; + RCVD_TLS_LAST(0.00)[]; + SPF_FAIL_NO_DKIM(10.00)[]; + FORGED_RECIPIENTS(2.00)[[email protected],[email protected]] +X-Spam-Flag: YES +X-Spam: Yes + +You are now authorized to post to the +gmane.network.wireguard newsgroup. + +The original message you sent to the newsgroup will be +posted within ten minutes. + +If you have any questions, they are most likely answered +in the FAQ: <URL: http://gmane.io/faq.php>. + +-- +Your friendly autoauthorizer at Gmane.io +http://gmane.io/ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/data/mails/kmail-attachmentstatus.mbox new/kmime-20.08.0/autotests/data/mails/kmail-attachmentstatus.mbox --- old/kmime-20.04.3/autotests/data/mails/kmail-attachmentstatus.mbox 1970-01-01 01:00:00.000000000 +0100 +++ new/kmime-20.08.0/autotests/data/mails/kmail-attachmentstatus.mbox 2020-08-02 10:19:20.000000000 +0200 @@ -0,0 +1,46 @@ +From [email protected] Sun Jul 01 00:00:00 2020 +From: XXXXXXXXXXXXXXXXX <[email protected]> +To: XXXXXXXXXXX <[email protected]> +Subject: XXXXXXXXXXXXXXXXXXXXX +Date: Sun, 1 Jul 2020 00:00:00 +0000 +Message-ID: <XXXXXXXXXXXXXXXXXXXXXXXX.EURP189.PROD.OUTLOOK.COM> +Content-Type: multipart/related; + boundary="_004_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_"; + type="multipart/alternative" +MIME-Version: 1.0 + +--_004_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_ +Content-Type: multipart/alternative; + boundary="_000_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_" + +--_000_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_ +Content-Type: text/plain; charset="iso-8859-1" +Content-Transfer-Encoding: quoted-printable + +Plain text message body + +--_000_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_ +Content-Type: text/html; charset="iso-8859-1" +Content-Transfer-Encoding: quoted-printable + +<html> +<head> +</head> +<body> +HTML message body +</body> +</html> + +--_000_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_-- + +--_004_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_ +Content-Disposition: attachment; filename="new.gif" +Content-Transfer-Encoding: base64 +Content-Type: image/gif; name="new.gif" + +R0lGODlhOgAWAKEAAPj8+AAAAPi4AAAAACH5BAEAAAAALAAAAAA6ABYAAAKzhI95ktzqlJwzGhGx +1Yh3CjaMRpbmyWFhpaLu6wLeepVBgN35ze+a7jPROjacAMjrHY3LH3M2rDmDQFL1+lStYEhjdRps +wlioXtekw2Ff25PZm22qmV8SCLZM7pRysT9GxJUEx5fmV4dCUTYHhzZIF6cV4pJ2VjQIdnL3Yon4 +FgnYBmZpVQkqGSVFRai0FoYa5biqdwgpFKuFp5soA4W7sAsIm/oADLwBi2pBnLosA8EMUAAAOw== + +--_004_AM7P189MB067853FA71865A9E5CD65DB3BA680AM7P189MB0678EURP_-- diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/headertest.cpp new/kmime-20.08.0/autotests/headertest.cpp --- old/kmime-20.04.3/autotests/headertest.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/autotests/headertest.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -572,11 +572,13 @@ "filename*9*=%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%2E%74%78%74"); QCOMPARE(h->disposition(), CDattachment); QCOMPARE(h->filename(), QString::fromUtf8("ЭтоВложениеСДлиннымИмемФайлаСовсемБезПробеловИЕщёРазЭтоВложениеСДлиннымИмемФайлаСовсемБезПробелов.txt")); + delete h; h = new ContentDisposition; h->from7BitString("attachment; filename*=UTF-8''%D0%AD%D1%82%D0%BE%D0%92%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5%D0%A1%D0%94%D0%BB%D0%B8%D0%BD%D0%BD%D1%8B%D0%BC%D0%98%D0%BC%D0%B5%D0%BC%D0%A4%D0%B0%D0%B9%D0%BB%D0%B0%D0%A1%D0%BE%D0%B2%D1%81%D0%B5%D0%BC%D0%91%D0%B5%D0%B7%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%D0%98%D0%95%D1%89%D1%91%D0%A0%D0%B0%D0%B7%D0%AD%D1%82%D0%BE%D0%92%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5%D0%A1%D0%94%D0%BB%D0%B8%D0%BD%D0%BD%D1%8B%D0%BC%D0%98%D0%BC%D0%B5%D0%BC%D0%A4%D0%B0%D0%B9%D0%BB%D0%B0%D0%A1%D0%BE%D0%B2%D1%81%D0%B5%D0%BC%D0%91%D0%B5%D0%B7%D0%9F%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%BE%D0%B2%2Etxt"); QCOMPARE(h->disposition(), CDattachment); QCOMPARE(h->filename(), QString::fromUtf8("ЭтоВложениеСДлиннымИмемФайлаСовсемБезПробеловИЕщёРазЭтоВложениеСДлиннымИмемФайлаСовсемБезПробелов.txt")); + delete h; } void HeaderTest::testContentTypeHeader() diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/messagetest.cpp new/kmime-20.08.0/autotests/messagetest.cpp --- old/kmime-20.04.3/autotests/messagetest.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/autotests/messagetest.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -677,3 +677,30 @@ data = "Subject: Test\r\n"; QCOMPARE(CRtoLF(data), "Subject: Test\r\n"); } + +void MessageTest::testBugAttachment387423() +{ + auto msg = readAndParseMail(QStringLiteral("kmail-attachmentstatus.mbox")); + + QCOMPARE(msg->subject()->as7BitString().data(), "Subject: XXXXXXXXXXXXXXXXXXXXX"); + QEXPECT_FAIL("", "Problem with searching attachment", Continue); + QCOMPARE(msg->attachments().count(), 1); + QCOMPARE(msg->contents().count(), 2); + + KMime::Content *attachment = msg->contents()[1]; + QCOMPARE(attachment->contentType(false)->mediaType().data(), "image"); + QCOMPARE(attachment->contentType(false)->subType().data(), "gif"); + QCOMPARE(attachment->contentType(false)->subType().data(), "gif"); + QCOMPARE(attachment->contentDisposition(false)->filename(), QStringLiteral("new.gif")); + QCOMPARE(attachment->contentDisposition(false)->disposition(), Headers::CDattachment); +} + +void MessageTest::testCrashReplyInvalidEmail() +{ + KMime::Message::Ptr msg = readAndParseMail(QStringLiteral("crash-invalid-email-reply.mbox")); + + QCOMPARE(msg->subject()->as7BitString().data(), "Subject: Re: Authorization required to post to gmane.network.wireguard (b96565298414a43aabcf9fbedf5e7e27)"); + QEXPECT_FAIL("", "Problem with content type", Continue); + QCOMPARE(msg->contents().size(), 2); +} + diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/autotests/messagetest.h new/kmime-20.08.0/autotests/messagetest.h --- old/kmime-20.04.3/autotests/messagetest.h 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/autotests/messagetest.h 2020-08-02 10:19:20.000000000 +0200 @@ -51,6 +51,8 @@ void testBug392239(); void testCRtoLF(); + void testBugAttachment387423(); + void testCrashReplyInvalidEmail(); private: KMime::Message::Ptr readAndParseMail(const QString &mailFile) const; }; diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/po/eu/libkmime5.po new/kmime-20.08.0/po/eu/libkmime5.po --- old/kmime-20.04.3/po/eu/libkmime5.po 2020-07-07 03:07:06.000000000 +0200 +++ new/kmime-20.08.0/po/eu/libkmime5.po 2020-08-07 09:07:56.000000000 +0200 @@ -1,26 +1,29 @@ -# translation of libkmime.po to Euskara -# translation of libkmime.po to Basque +# Translation for libkmime5.po to Euskara/Basque (eu). +# Copyright (C) 2005-2020, This file is copyright: +# This file is distributed under the same license as the kmime package. +# KDE euskaratzeko proiektuko arduraduna <[email protected]>. +# +# Translators: # Marcos <[email protected]>, 2005. # Ion Gaztañaga <[email protected]>, 2005. -# +# Iñigo Salvador Azurmendi <[email protected]>, 2020. msgid "" msgstr "" -"Project-Id-Version: libkmime\n" +"Project-Id-Version: kmime\n" "Report-Msgid-Bugs-To: https://bugs.kde.org\n"; "POT-Creation-Date: 2019-12-31 03:21+0100\n" -"PO-Revision-Date: 2005-02-12 07:12+0100\n" -"Last-Translator: Ion Gaztañaga <[email protected]>\n" -"Language-Team: Euskara <[email protected]>\n" +"PO-Revision-Date: 2020-07-31 20:17+0200\n" +"Last-Translator: Iñigo Salvador Azurmendi <[email protected]>\n" +"Language-Team: Basque <[email protected]>\n" "Language: eu\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"X-Generator: KBabel 1.9\n" +"X-Generator: Lokalize 20.04.3\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #: kmime_dateformatter.cpp:268 -#, fuzzy, kde-format -#| msgid "unknown" +#, kde-format msgctxt "invalid time specified" msgid "unknown" msgstr "ezezaguna" diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/po/nn/libkmime5.po new/kmime-20.08.0/po/nn/libkmime5.po --- old/kmime-20.04.3/po/nn/libkmime5.po 2020-07-07 03:07:07.000000000 +0200 +++ new/kmime-20.08.0/po/nn/libkmime5.po 2020-08-07 09:07:57.000000000 +0200 @@ -1,20 +1,20 @@ # Translation of libkmime5 to Norwegian Nynorsk # -# Karl Ove Hufthammer <[email protected]>, 2008. +# Karl Ove Hufthammer <[email protected]>, 2008, 2020. # Eirik U. Birkeland <[email protected]>, 2008. msgid "" msgstr "" "Project-Id-Version: libkmime\n" "Report-Msgid-Bugs-To: https://bugs.kde.org\n"; "POT-Creation-Date: 2019-12-31 03:21+0100\n" -"PO-Revision-Date: 2008-08-07 22:23+0200\n" -"Last-Translator: Eirik U. Birkeland <[email protected]>\n" +"PO-Revision-Date: 2020-07-07 21:50+0200\n" +"Last-Translator: Karl Ove Hufthammer <[email protected]>\n" "Language-Team: Norwegian Nynorsk <[email protected]>\n" "Language: nn\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" -"X-Generator: KBabel 1.11.4\n" +"X-Generator: Lokalize 20.07.70\n" "Plural-Forms: nplurals=2; plural=n != 1;\n" "X-Environment: kde\n" "X-Accelerator-Marker: &\n" @@ -29,18 +29,18 @@ #: kmime_dateformatter.cpp:284 #, kde-format msgid "Today %1" -msgstr "I dag, kl. %1" +msgstr "I dag, kl. %1" #: kmime_dateformatter.cpp:288 #, kde-format msgid "Yesterday %1" -msgstr "I går, kl. %1" +msgstr "I går, kl. %1" #: kmime_dateformatter.cpp:293 #, kde-format msgctxt "1. weekday, 2. time" msgid "%1 %2" -msgstr "%1, kl. %2" +msgstr "%1, kl. %2" #: kmime_mdn.cpp:63 #, kde-format diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/po/uk/libkmime5.po new/kmime-20.08.0/po/uk/libkmime5.po --- old/kmime-20.04.3/po/uk/libkmime5.po 2020-07-07 03:07:08.000000000 +0200 +++ new/kmime-20.08.0/po/uk/libkmime5.po 2020-08-07 09:07:57.000000000 +0200 @@ -1,5 +1,5 @@ # Translation of libkmime5.po to Ukrainian -# Copyright (C) 2018 This_file_is_part_of_KDE +# Copyright (C) 2014 This_file_is_part_of_KDE # This file is distributed under the license LGPL version 2.1 or # version 3 or later versions approved by the membership of KDE e.V. # diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/po/zh_CN/libkmime5.po new/kmime-20.08.0/po/zh_CN/libkmime5.po --- old/kmime-20.04.3/po/zh_CN/libkmime5.po 2020-07-07 03:07:08.000000000 +0200 +++ new/kmime-20.08.0/po/zh_CN/libkmime5.po 2020-08-07 09:07:57.000000000 +0200 @@ -7,7 +7,7 @@ "Project-Id-Version: kdeorg\n" "Report-Msgid-Bugs-To: https://bugs.kde.org\n"; "POT-Creation-Date: 2019-12-31 03:21+0100\n" -"PO-Revision-Date: 2020-06-24 08:01\n" +"PO-Revision-Date: 2020-07-31 15:02\n" "Last-Translator: \n" "Language-Team: Chinese Simplified\n" "Language: zh_CN\n" diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/src/kmime_content.cpp new/kmime-20.08.0/src/kmime_content.cpp --- old/kmime-20.04.3/src/kmime_content.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/src/kmime_content.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -208,7 +208,7 @@ { Q_D(Content); QByteArray newHead; - foreach (const Headers::Base *h, d->headers) { + for (const Headers::Base *h : qAsConst(d->headers)) { if (!h->isEmpty()) { newHead += h->as7BitString() + '\n'; } @@ -307,7 +307,7 @@ } //add all (encoded) contents separated by boundaries - foreach (Content *c, d->multipartContents) { + for (Content *c : qAsConst(d->multipartContents)) { e += boundary + '\n'; e += c->encodedContent(false); // don't convert LFs here, we do that later!!!!! } @@ -453,7 +453,7 @@ if (ct && ct->isMultipart() && !ct->isSubtype("related") && !ct->isSubtype("alternative")) { const QVector<Content*> contentsList = contents(); result.reserve(contentsList.count()); - Q_FOREACH (Content *child, contentsList) { + for (Content *child : contentsList) { if (isAttachment(child)) result.push_back(child); else @@ -621,7 +621,7 @@ { Q_ASSERT(type && *type); - foreach (Headers::Base *h, d_ptr->headers) { + for (Headers::Base *h : qAsConst(d_ptr->headers)) { if (h->is(type)) { return h; // Found. } @@ -636,7 +636,7 @@ QVector<Headers::Base*> result; - foreach (Headers::Base *h, d_ptr->headers) { + for (Headers::Base *h : qAsConst(d_ptr->headers)) { if (h->is(type)) { result << h; } @@ -1036,7 +1036,7 @@ Q_ASSERT(multipartContents.isEmpty()); body.clear(); const auto parts = mpp.parts(); - foreach (const QByteArray &part, parts) { + for (const QByteArray &part : parts) { Content *c = new Content(q); c->setContent(part); c->setFrozen(frozen); diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/src/kmime_contentindex.cpp new/kmime-20.08.0/src/kmime_contentindex.cpp --- old/kmime-20.04.3/src/kmime_contentindex.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/src/kmime_contentindex.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -98,7 +98,7 @@ { QStringList l; l.reserve(d->index.count()); - foreach (unsigned int i, d->index) { + for (unsigned int i : qAsConst(d->index)) { l.append(QString::number(i)); } return l.join(QLatin1Char('.')); diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/src/kmime_headers.cpp new/kmime-20.08.0/src/kmime_headers.cpp --- old/kmime-20.04.3/src/kmime_headers.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/src/kmime_headers.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -328,7 +328,7 @@ if (withHeaderType) { rv = typeIntro(); } - foreach (const Types::Mailbox &mbox, d->mailboxList) { + for (const Types::Mailbox &mbox : qAsConst(d->mailboxList)) { rv += mbox.as7BitString(d->encCS); rv += ", "; } @@ -391,7 +391,7 @@ Q_D(const MailboxList); QStringList rv; rv.reserve(d->mailboxList.count()); - foreach (const Types::Mailbox &mbox, d->mailboxList) { + for (const Types::Mailbox &mbox : qAsConst(d->mailboxList)) { if (mbox.hasName()) rv.append(mbox.name()); else @@ -436,7 +436,7 @@ d->mailboxList.reserve(maybeAddressList.count()); // extract the mailboxes and complain if there are groups: - foreach (const auto &it, maybeAddressList) { + for (const auto &it : qAsConst(maybeAddressList)) { if (!(it).displayName.isEmpty()) { KMIME_WARN << "mailbox groups in header disallowing them! Name: \"" << (it).displayName << "\"" @@ -500,8 +500,9 @@ if (withHeaderType) { rv = typeIntro(); } - foreach (const Types::Address &addr, d->addressList) { - foreach (const Types::Mailbox &mbox, addr.mailboxList) { + for (const Types::Address &addr : qAsConst(d->addressList)) { + const auto mailBoxList = addr.mailboxList; + for (const Types::Mailbox &mbox : mailBoxList) { rv += mbox.as7BitString(d->encCS); rv += ", "; } @@ -521,7 +522,7 @@ { Q_D(const AddressList); QStringList rv; - foreach (const Types::Address &addr, d->addressList) { + for (const Types::Address &addr : qAsConst(d->addressList)) { rv.reserve(rv.size() + addr.mailboxList.size()); foreach (const Types::Mailbox &mbox, addr.mailboxList) { rv.append(mbox.prettyAddress()); @@ -576,8 +577,9 @@ { Q_D(const AddressList); QStringList rv; - foreach (const Types::Address &addr, d->addressList) { - foreach (const Types::Mailbox &mbox, addr.mailboxList) { + for (const Types::Address &addr : qAsConst(d->addressList)) { + const auto mailboxList = addr.mailboxList; + for (const Types::Mailbox &mbox : mailboxList) { if (mbox.hasName()) rv.append(mbox.name()); else @@ -952,7 +954,7 @@ if (withHeaderType) { rv = typeIntro(); } - foreach (const Types::AddrSpec &addr, d->msgIdList) { + for (const Types::AddrSpec &addr : qAsConst(d->msgIdList)) { if (!addr.isEmpty()) { const QString asString = addr.asString(); rv += '<'; diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/src/kmime_message.cpp new/kmime-20.08.0/src/kmime_message.cpp --- old/kmime-20.04.3/src/kmime_message.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/src/kmime_message.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -74,7 +74,8 @@ if (type.isEmpty()) { return c->contents().at(0); } - foreach (Content *c1, c->contents()) { + const auto contents = c->contents(); + for (Content *c1 : contents) { if (c1->contentType()->mimeType() == type) { return c1; } diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/src/kmime_types.cpp new/kmime-20.08.0/src/kmime_types.cpp --- old/kmime-20.04.3/src/kmime_types.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/src/kmime_types.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -191,7 +191,7 @@ HeaderParsing::parseMailbox(cursor, cursor + s.length(), *this); } -QByteArray KMime::Types::Mailbox::as7BitString(const QByteArray &encCharset) const +QByteArray Mailbox::as7BitString(const QByteArray &encCharset) const { if (!hasName()) { return address(); @@ -210,12 +210,12 @@ return rv; } -QVector<KMime::Types::Mailbox> KMime::Types::Mailbox::listFromUnicodeString(const QString &s) +QVector<KMime::Types::Mailbox> Mailbox::listFromUnicodeString(const QString &s) { return listFrom7BitString(encodeRFC2047Sentence(s, "utf-8")); } -QVector<KMime::Types::Mailbox> KMime::Types::Mailbox::listFrom7BitString(const QByteArray& s) +QVector<KMime::Types::Mailbox> Mailbox::listFrom7BitString(const QByteArray& s) { QVector<KMime::Types::Mailbox> res; QVector<KMime::Types::Address> maybeAddressList; @@ -225,7 +225,7 @@ } res.reserve(maybeAddressList.size()); - foreach (const auto &it, maybeAddressList) { + for (const auto &it : qAsConst(maybeAddressList)) { res += (it).mailboxList; } return res; @@ -238,7 +238,7 @@ QStringList rv; rv.reserve(mailboxes.count()); - foreach (const Types::Mailbox &mbox, mailboxes) { + for (const Types::Mailbox &mbox : mailboxes) { rv.append(mbox.prettyAddress()); } return rv.join(QLatin1String(", ")); diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/src/kmime_util.cpp new/kmime-20.08.0/src/kmime_util.cpp --- old/kmime-20.04.3/src/kmime_util.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/src/kmime_util.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -55,7 +55,7 @@ QByteArray cachedCharset(const QByteArray &name) { - foreach (const QByteArray &charset, c_harsetCache) { + for (const QByteArray &charset : qAsConst(c_harsetCache)) { if (qstricmp(name.data(), charset.data()) == 0) { return charset; } @@ -638,7 +638,8 @@ // Ok, content itself is not an attachment. now we deal with multiparts auto ct = content->contentType(false); if (ct && ct->isMultipart() && !ct->isSubtype("related")) {// && !ct->isSubtype("alternative")) { - Q_FOREACH (Content *child, content->contents()) { + const auto contents = content->contents(); + for (Content *child : contents) { if (hasAttachment(child)) { return true; } @@ -659,7 +660,8 @@ // Ok, content itself is not an invitation. now we deal with multiparts if (content->contentType()->isMultipart()) { - Q_FOREACH (Content *child, content->contents()) { + const auto contents = content->contents(); + for (Content *child : contents) { if (hasInvitation(child)) { return true; } diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/kmime-20.04.3/tests/test_kmime_header_parsing.cpp new/kmime-20.08.0/tests/test_kmime_header_parsing.cpp --- old/kmime-20.04.3/tests/test_kmime_header_parsing.cpp 2020-06-12 08:07:33.000000000 +0200 +++ new/kmime-20.08.0/tests/test_kmime_header_parsing.cpp 2020-08-02 10:19:20.000000000 +0200 @@ -326,7 +326,7 @@ << "result.displayName:\n" << result.displayName << endl; int i = 0; - foreach (const auto &it, result.mailboxList) { + for (const auto &it : qAsConst(result.mailboxList)) { cout << "result.mailboxList[" << i << "].displayName:\n" << (it).name() << endl << "result.mailboxList[" << i << "].addrSpec.localPart:\n" @@ -365,12 +365,13 @@ cout << (ok ? "OK" : "BAD") << endl; int j = 0; - foreach (auto jt, result) { + for (const auto &jt : qAsConst(result)) { cout << "result[" << j << "].displayName:\n" << (jt).displayName << endl; int i = 0; - foreach (const auto &it, (jt).mailboxList) { + const auto mailboxList = (jt).mailboxList; + for (const auto &it : mailboxList) { cout << "result[" << j << "].mailboxList[" << i << "].displayName:\n" << (it).name() << endl << "result[" << j << "].mailboxList[" << i << "].addrSpec.localPart:\n"
