One document matched: draft-ietf-eai-rfc5335bis-13.xml
<?xml version="1.0" encoding="macintosh"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY EAISMTPkeyword "UTF8SMTPbis">
<!ENTITY % rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY % rfc2045 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
<!ENTITY % rfc2046 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml'>
<!ENTITY % rfc2047 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2047.xml'>
<!ENTITY % rfc2231 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2231.xml'>
<!ENTITY % rfc3629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY % rfc5321 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml'>
<!ENTITY % rfc5322 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
<!ENTITY % rfc3629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY % rfc4952 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4952.xml'>
<!ENTITY % rfc5198 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5198.xml'>
<!ENTITY % rfc5234 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!-- PKIX -->
<!ENTITY % rfc5280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!-- openPGP -->
<!ENTITY % rfc3156 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3156.xml'>
<!ENTITY % rfc5863 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5863.xml'>
<!ENTITY % rfc5335 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5335.xml'>
<!ENTITY % rfc6152 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6152.xml'>
<!ENTITY % I-D.ietf-eai-rfc5336bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai-rfc5336bis-07.xml'>
<!ENTITY % I-D.ietf-eai-frmwrk-4952bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-eai-frmwrk-4952bis-10.xml'>
]>
<?rfc rfcedstyle='yes' subcompact='no' toc='yes' symrefs="yes" sortrefs="yes" ?>
<rfc ipr='trust200902' category="std" updates="2045"
obsoletes="5335" docName="draft-ietf-eai-rfc5335bis-13">
<front>
<title abbrev="I18N Email Headers">
Internationalized Email Headers
</title>
<author initials="A." surname="Yang" fullname="Abel Yang">
<organization>TWNIC</organization>
<address>
<postal>
<street>4F-2, No. 9, Sec 2, Roosevelt Rd.</street>
<city>Taipei</city>
<region/>
<code>100</code>
<country>Taiwan</country>
</postal>
<phone>+886 2 23411313 ext 505</phone>
<email>abelyang@twnic.net.tw</email>
</address>
</author>
<author initials="S." surname="Steele" fullname="Shawn Steele">
<organization>Microsoft</organization>
<address>
<email>Shawn.Steele@microsoft.com</email>
</address>
</author>
<author initials="N." surname="Freed" fullname="Ned Freed">
<organization>Oracle</organization>
<address>
<postal>
<street>800 Royal Oaks</street>
<city>Monrovia</city> <region>CA</region> <code>91016-6347</code>
<country>USA</country>
</postal>
<email>ned+ietf@mrochek.com</email>
</address>
</author>
<date year="2011" />
<area>Applications</area>
<workgroup>Email Address Internationalization (EAI)</workgroup>
<keyword>I18N Email Header</keyword>
<keyword>UTF-8 Email Header</keyword>
<keyword>internationalization Email Header</keyword>
<abstract>
<t>
Internet mail was originally limited to 7-bit ASCII. MIME added
support for the use of 8-bit character sets in body parts, and
also defined an encoded-word construct so other character sets could
be used in certain header field values. But full internationalization of
electronic mail requires additional enhancements to allow the use of Unicode,
including characters outside the ASCII repertoire, in mail addresses as well
as direct use of Unicode in header fields like From:, To:, and Subject:,
without requiring the use of complex encoded-word constructs.
This document specifies an enhancement to the Internet Message Format and to
MIME that allows use of Unicode in mail addresses and most header field content.
</t>
<t>
This specification replaces RFC 5335.
This specification also updates Section 6.4 of RFC 2045 to eliminate the
restriction prohibiting the use of non-identity content-transfer-encodings
on subtypes of "message/".
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="INT">
<t>
Internet mail distinguishes a message from its transport and further
divides a message between a header and a body <xref target="RFC5322"/>.
Internet mail header field values contain a variety of strings that are
intended to be user-visible. The range of supported characters for these
strings was originally limited to 7-bit <xref target="ASCII"/>. MIME
<xref target="RFC2045"/> <xref target="RFC2046"/> <xref target="RFC2047"/>
provides the ability to use additional character sets, but this support is
limited to body part data and to special encoded-word constructs that were
only allowed in a limited number of places in header field values.
</t>
<t>
Globalization of the Internet requires support of the much larger set of
characters provided by Unicode <xref target="RFC5198"/> in both mail
addresses and most header field values. Additionally, complex encoding
schemes like encoded-words introduce inefficiencies as well as
significant opportunities for processing errors. And finally,
native support for the UTF-8 charset is now available on most systems.
Hence it is strongly desirable for Internet mail to support UTF-8
<xref target="RFC3629"/> directly.
</t>
<t>
This document specifies an enhancement to the Internet Message Format
<xref target="RFC5322"/> and to MIME that permits the direct use of UTF-8,
rather than only ASCII, in header field values, including mail addresses.
A new media type, message/global, is defined for messages that use this
extended format. This specification also lifts the MIME restriction on having
non-identity content-transfer-encodings on any subtype of the
message top-level type so that message/global parts can be safely
transmitted across existing mail infrastructure.
</t>
<t>
This specification is based on a model of native, end-to-end support
for UTF-8, which depends on having an "8-bit clean" environment assured by
the transport system. Support for carriage across legacy, 7-bit infrastructure
and for processing by 7-bit receivers requires additional mechanisms that are
not provided by these specifications.
</t>
<t>
This specification is a revision of and replacement for <xref target="RFC5335" />.
Section 6 of <xref target="I-D.ietf-eai-frmwrk-4952bis" /> describes the change
in approach between this specification and the previous version.
</t>
</section>
<section title="Terminology Used In This Specification">
<t>
A plain ASCII string is fully compatible with <xref target="RFC5321" /> and
<xref target="RFC5322" />. In this document, non-ASCII strings are UTF-8
strings if they are in header field values which contain at least
one <UTF8-non-ascii> (see <xref target="Normalization"/>).
</t>
<t>
Unless otherwise noted, all terms used here are defined in
<xref target="RFC5321"/>, <xref target="RFC5322"/>,
<xref target="I-D.ietf-eai-frmwrk-4952bis" />, or
<xref target="I-D.ietf-eai-rfc5336bis"/>.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119" />.
</t>
<t>
The term "8-bit" means octets are present in the data with values above 0x7F.
</t>
</section>
<section title="Changes to Message Header Fields">
<t>
To permit Unicode characters in field values, the header definition in
<xref target="RFC5322"/> is extended to support the new format.
The following sections specify the necessary changes to RFC 5322's ABNF.
</t>
<t>
The syntax rules not mentioned below remain defined as in
<xref target="RFC5322"/>.
</t>
<t>
Note that this protocol does not change RFC 5322 rules for defining
header field names. The bodies of header fields are allowed to contain Unicode
characters, but the header field names themselves must contain only ASCII
characters.
</t>
<t>
Also note that messages in this format require the use of the &EAISMTPkeyword;
extension <xref target="I-D.ietf-eai-rfc5336bis"/> to be transferred via SMTP.
</t>
<section title="UTF-8 Syntax and Normalization" anchor="Normalization">
<t>
UTF-8 characters can be defined in terms of octets using the following
ABNF <xref target="RFC5234"/>, taken from <xref target="RFC3629"/>:
<figure><artwork type="abnf">
<![CDATA[
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC3629>
UTF8-3 = <Defined in Section 4 of RFC3629>
UTF8-4 = <Defined in Section 4 of RFC3629>
]]>
</artwork></figure>
</t>
<t>
See <xref target="RFC5198"/> for a discussion of Unicode normalization;
<xref target="UNF">normalization form NFC</xref> SHOULD be used. Actually, if
one is going to do internationalization properly, one of the most often-cited
goals is to permit people to spell their names correctly. Since many mailbox
local parts reflect personal names, that principle applies to mailboxes as
well. The <xref target="UNF">NFKC normalization form</xref> SHOULD NOT be
used because it may lose information that is needed to correctly spell some
names in some unusual circumstances.
</t>
</section>
<section title="Syntax Extensions to RFC 5322" anchor="syntax_change">
<t>
The following rules extend the ABNF syntax defined in
<xref target="RFC5322"/> and <xref target="RFC5234"/> in order to allow UTF-8
content.
</t>
<figure><artwork type="abnf"><![CDATA[
VCHAR =/ UTF8-non-ascii
ctext =/ UTF8-non-ascii
atext =/ UTF8-non-ascii
qtext =/ UTF8-non-ascii
text =/ UTF8-non-ascii
; note that this upgrades the body to UTF-8
dtext =/ UTF8-non-ascii
]]>
</artwork></figure>
<t>
The preceding changes mean that the following constructs now allow UTF-8:
</t>
<t>
<list style="numbers">
<t>
Unstructured text, used in header fields like Subject: or Content-description:.
</t>
<t>
Any construct that uses atoms, including but not limited to the local parts of
addresses and message-ids. This includes addresses in the "for" clauses of
Received: header fields.
</t>
<t>
Quoted strings.
</t>
<t>
Domains.
</t>
</list>
</t>
<t>
Note that header field names are not on this list; these are still restricted to
ASCII.
</t>
</section>
<section title="Use of 8-bit UTF-8 in Message-Ids">
<t>
Implementers of message-id generation algorithms MAY prefer to restrain
their output to ASCII since that has some advantages, such as
when constructing In-reply-to: and References: header fields in mailing-list
threads where some senders use EAI and others not.
</t>
</section>
<section title="Effects on Line Length Limits">
<t>
Section 2.1.1 of <xref target="RFC5322"/> limits lines to 998 characters
and recommends that the lines be restricted to only 78 characters. This
specification changes the former limit to 998 octets. (Note that in ASCII
octets and characters are effectively the same but this is not true in UTF-8.)
The 78 character limit remains defined in terms of characters, not octets, since
it is intended to address display width issues, not line length issues.
</t>
</section>
<section title="Changes to MIME Message Type Encoding Restrictions"
anchor="change_to_message_encoding">
<t>
This specification updates Section 6.4 of <xref target="RFC2045"/>.
<xref target="RFC2045"/> prohibits applying a content-transfer-encoding
to any subtypes of "message/". This specification relaxes that rule -- it allows
newly defined MIME types to permit content-transfer-encoding, and it allows
content-transfer-encoding for message/global (see <xref target="utf8smtp"/>).
</t>
<t>
Background: Normally, transfer of message/global will be done in
8-bit-clean channels, and body parts will have "identity" encodings,
that is, no decoding is necessary.
</t>
<t>
But in the case where a message containing a message/global is downgraded
from 8-bit to 7-bit as described in <xref target="RFC6152"/>, an encoding
might have to be applied to the message; if the message travels multiple times
between a 7-bit environment and an environment implementing these extensions,
multiple levels of encoding may occur. This is expected to be rarely
seen in practice, and the potential complexity of other ways of dealing
with the issue is thought to be larger than the complexity of allowing
nested encodings where necessary.
</t>
</section>
<section title="Use of MIME Encoded-Words">
<t>
The MIME encoded-words facility <xref target="RFC2047"/> provides the ability
to place non-ASCII text, but only in a subset of the places allowed by this extension.
Additionally, encoded-words are substantially more complex since they allow the
use of arbitrary charsets. Accordingly, encoded-words SHOULD NOT be used when
generating header fields for messages employing this extension. Agents MAY, when
incorporating material from another message, convert encoded-word use to
direct use of UTF-8.
</t>
<t>
Note that care must be taken when decoding encoded-words because the results
after replacing an encoded-word with its decoded equivalent in UTF-8 may be
syntactically invalid. Processors that elect to decode encoded-words MUST NOT
generate syntactically invalid fields.
</t>
</section>
<section title="The Message/global Media Type" anchor="utf8smtp">
<t>
Internationalized messages in this format MUST only be transmitted as
authorized by <xref target="I-D.ietf-eai-rfc5336bis" />
or within a non-SMTP environment that supports these messages.
A message is a "message/global message" if:
</t>
<t>
<list style="symbols">
<t>it contains 8-bit UTF-8 header values as specified in this document, or</t>
<t>it contains 8-bit UTF-8 values in the header fields of body parts.</t>
</list>
</t>
<t>
The content of a message/global part is otherwise identical to that
of a message/rfc822 part.
</t>
<t>
If an object of this type is sent to a 7-bit-only system, it MUST
have an appropriate content-transfer-encoding applied.
(Note that a system compliant with MIME that doesn't recognize
message/global is supposed to treat it as "application/octet-stream" as
described in Section 5.2.4 of <xref target="RFC2046" />.)
</t>
<t><list style="hanging">
<t hangText="Type name:">message</t>
<t hangText="Subtype name:">global</t>
<t hangText="Required parameters:">none</t>
<t hangText="Optional parameters:">none</t>
<t hangText="Encoding considerations:">Any content-transfer-encoding is permitted.
The 8-bit or binary content-transfer-encodings are recommended where permitted.</t>
<t hangText="Security considerations:">See <xref target="security" />.</t>
<t hangText="Interoperability considerations:">This media type provides
functionality similar to the message/rfc822 content type for email
messages with internationalized email headers. When there is a need to
embed or return such content in another message, there is generally an
option to use this media type and leave the content unchanged or
down-convert the content to message/rfc822. Both of these choices will
interoperate with the installed base, but with different properties.
Systems unaware of internationalized headers will typically treat a
message/global body part as an unknown attachment, while they will
understand the structure of a message/rfc822. However, systems that
understand message/global will provide functionality superior to the
result of a down-conversion to message/rfc822. The most interoperable
choice depends on the deployed software.</t>
<t hangText="Published specification:">RFC &rfc.number;</t>
<t hangText="Applications that use this media type:">SMTP servers and
email clients that support multipart/report generation or parsing.
Email clients that forward messages with internationalized headers as
attachments.</t>
<t hangText="Additional information:"></t>
<t hangText="Magic number(s):">none</t>
<t hangText="File extension(s):">The extension ".u8msg" is suggested.</t>
<t hangText="Macintosh file type code(s):">A uniform type identifier
(UTI) of "public.utf8-email-message" is suggested. This conforms to
"public.message" and "public.composite-content", but does not necessarily
conform to "public.utf8-plain-text".</t>
<t hangText="Person & email address to contact for further
information:">See the Author's Address section of this document.</t>
<t hangText="Intended usage:">COMMON</t>
<t hangText="Restrictions on usage:">This is a structured media type
that embeds other MIME media types. An 8-bit or binary
content-transfer-encoding SHOULD be used unless this media type is sent
over a 7-bit-only transport.</t>
<t hangText="Author:">See the Author's Address section of this document.</t>
<t hangText="Change controller:">IETF Standards Process</t>
</list></t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>
Because UTF-8 often requires several octets to encode a single character,
internationalization may cause header field values in general and mail addresses
in particular to become longer. As specified in <xref target="RFC5322"/>, each
line of characters MUST be no more than 998 octets, excluding the CRLF. On the
other hand, MDA (Mail Delivery Agent) processes that parse, store, or handle
email addresses or local parts must take extra care not to overflow buffers,
truncate addresses, or exceed storage allotments. Also, they must take care,
when comparing, to use the entire lengths of the addresses.
</t>
<t>
There are lots of ways to use UTF-8 to represent something equivalent
or similar to a particular displayed character or group of characters;
see the security considerations in <xref target="RFC3629"/> for details
on the problems this can cause. The normalization process described in
<xref target="Normalization" /> is recommended to minimize these issues.
</t>
<t>
The security impact of UTF-8 headers on email signature systems such as
Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is discussed in
<xref target="I-D.ietf-eai-frmwrk-4952bis"/>, Section 14.
</t>
<t>
If a user has a non-ASCII mailbox address and an ASCII mailbox
address, a digital certificate that identifies that user might have
both addresses in the identity. Having multiple email addresses as
identities in a single certificate is already supported in
PKIX (Public Key Infrastructure for X.509 Certificates) <xref target="RFC5280" />
and OpenPGP <xref target="RFC3156" />, but there may be user interface issues
associated with the introduction of UTF-8 into addresses in this context.
</t>
</section>
<section title="IANA Considerations" anchor="IANA">
<t>
IANA is requested to update the registration of the message/global MIME type
using the registration form contained in <xref target="utf8smtp" />.
</t>
</section>
<section title="Acknowledgements">
<t>
This document incorporates many ideas first described in
Internet-Draft form by Paul Hoffman, although many details have
changed from that earlier work.
</t>
<t>
The author especially thanks Jeff Yeh for his efforts and contributions
on editing previous versions.
</t>
<t>
Most of the content of this document was provided by John C Klensin and Dave
Crocker. Significant comments and suggestions were received from
Martin Duerst, Julien Elie, Arnt Gulbrandsen, Kristin Hubner, Kari Hurtta, Yangwoo Ko,
Charles H. Lindsey, Alexey Melnikov, Chris Newman, Pete Resnick,
Yoshiro Yoneya, and additional members of the JET team (Joint Engineering Team)
and were incorporated into the document. The editors wish to sincerely thank
them all for their contributions.
</t>
</section>
<section title="Edit history">
<t>
[[RFC Editor: Please remove this section before publishing.]]
</t>
<section title="draft-ietf-eai-rfc5335bis-00">
<t>
<list style="numbers">
<t>Applied Errata suggested by Alfred Hoenes.</t>
<t>Adjust [RFC2821] and [RFC2822] to <xref target="RFC5321"/> and <xref target="RFC5322"/>.</t>
<t>Abrogate <alt-address> in ABNF of <angle-addr>.</t>
<t>Revoke [RFC5504] from this document.</t>
<t>Upgrade some references from I-Ds to RFC.</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-01">
<t>
<list style="numbers">
<t>Author name revised.</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-02">
<t>
<list style="numbers">
<t>ABNF revised.</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-03">
<t>
<list style="numbers">
<t>Fix typos </t>
<t>ABNF revised </t>
<t>Improve sentence</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-04">
<t>
<list style="numbers">
<t>improve sentences and ABNF revised based on AD and Co-chairs </t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-05">
<t>
<list style="numbers">
<t>ABNF revised based on AD comments </t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-06">
<t>
<list style="numbers">
<t>ABNF revised </t>
<t>improve <xref target="IANA" /> </t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-07">
<t>
<list style="numbers">
<t>Minor ABNF revised in <xref target="syntax_change" /></t>
<t>improve <xref target="IANA" /> </t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-09">
<t>Version -08 was posted in error and withdrawn. Version 09 is
is identical to version 07 except for a date change, addition of
this note, and some vertical spacing compression on this page.
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-10">
<t>
<list style="numbers">
<t>Add appendix and overview of changes</t>
<t>Replace polls result in Abstract and <xref target="INT"/></t>
<t>Minor Sentence modification</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-11">
<t>
<list style="numbers">
<t>Major rewrite of entire document to incorporate Dave Crocker's simplified ABNF.</t>
<t>The document has intentionally been refocused on implementors wishing to adapt
their software to support EAI, so much of the explanatory and historical text has
been removed. (Some of it may be reintroduced later as an appendix.</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-12">
<t>
<list style="numbers">
<t>Added a section on the handling of MIME encoded-words.</t>
<t>Updated the security considerations to refer to the more complete
discussion in RFC 3629.</t>
<t>Added a section on the effects on line length limits.</t>
<t>Removed the syntax restriction on the use of 8-bit UTF-8 in message-ids.</t>
<t>Added text recommending that 8-bit UTF-8 be avoided in message-ids.</t>
</list>
</t>
</section>
<section title="draft-ietf-eai-rfc5335bis-13">
<t>
<list style="numbers">
<t>Updated and alphabetized the contributor list.</t>
<t>Corrected various typos, reworded some sections to make them clearer.</t>
<t>Replaced the reference to RFC 5598 with a reference to RFC 5322.</t>
<t>Removed the Updates: RFC 5322. RFC 5322 is extended by this document,
not updated.</t>
<t>Added some text to the Introduction referring to the framework document
for information about changes between this specification and RFC 5335.</t>
<t>Added text to the Abstract to say that this document replaces RFC 5335
and that RFC 2045 is updated.</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<!-- SMTP Service Extension for 8bit-MIMEtransport -->
<!-- ietf-eai-smtpext became RFC 5336 -->
<reference anchor="ASCII">
<front>
<title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
<author fullname="American National Standards Institute"/>
<date year="1986"/>
</front>
<seriesInfo name="ANSI" value="X3.4"/>
</reference>
&rfc2119;
&rfc5321;
&rfc5322;
<!-- UTF-8 -->
&rfc3629;
&I-D.ietf-eai-frmwrk-4952bis;
&I-D.ietf-eai-rfc5336bis;
&rfc5198;
&rfc5234;
<reference anchor="UNF" target="http://www.unicode.org/reports/tr15/">
<front>
<title>Unicode Standard Annex #15: Unicode Normalization Forms</title>
<author initials="M." surname="Davis" fullname="Mark Davis" />
<author initials="K." surname="Whistler" fullname="Ken Whistler" />
<date day='17' month='September' year='2010' />
</front>
</reference>
</references>
<references title="Informative References">
<!-- 8bitmime -->
<!-- MIME (parts 1, 2, 3) -->
&rfc2045;
&rfc2046;
&rfc2047;
<!-- openPGP -->
&rfc3156;
<!-- PKIX -->
&rfc5280;
&rfc5335;
&rfc6152;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:01 |