rfc-2304

Minimal FAX address format in Internet Mail

C. Allocchio
date1998-03 streamIETF areaapp wgfax statusPROPOSED STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc2304 doi10.17487/RFC2304
This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS-TRACK]

obsoleted by

Extracted elements (16)

design-rationale §4

The optional '/' characters in fax-email addresses are accommodated because they can result from other mail transport service gateways where they are also optional elements, ensuring interoperability with existing gateway infrastructure.

email

design-rationale §2

Written separator characters ('-' and '.') are allowed in the syntax to facilitate user specification of PSTN e-mail addresses by permitting insertion between dial elements. They carry no semantic meaning and must be ignored by implementations.

email

interoperability-note §4.1

When multiple T.33 subaddresses are needed for the same fax-mbox, multiple fax-email elements must be used. The UA may accept multiple subaddress elements but must generate multiple fax-mbox elements when passing to the MTA.

email

normative-requirement §1 MUST

All implementations supporting FAX over e-mail address format MUST support as a minimum the specification described in this document.

email

normative-requirement §2 MUST NOT

Any non 'global-phone' dialling schema MUST NOT use the leading '+' between the '=' sign and the dialling string. The '+' sign is strictly reserved for the standard global-phone syntax.

email

normative-requirement §2 MUST

Any occurrences of written-sep elements ('-' or '.') in a pstn-mbox MUST be ignored by all conformant implementations.

email

normative-requirement §3 MUST

For domain strings used in SMTP transmissions, the string MUST conform to RFC 821 and RFC 1123 domain specifications. For domain strings in message content headers, the string MUST conform to RFC 822 and RFC 1123.

email

normative-requirement §4 MUST

Implementations MUST accept the optional leading and trailing slash characters in fax-email addresses but SHOULD NOT generate them. Gateways are allowed to strip them off when converting to Internet mail addressing.

email

normative-requirement §4 MUST

The fax-address element MUST strictly follow the quoting rules specified in RFC 822 and RFC 1123.

email

normative-requirement §2 SHOULD

User Agents SHOULD remove written-sep elements before submitting messages to the Message Transport System.

email

protocol-element §3

The mta-I-fax is the Right Hand Side (RHS) of the e-mail address (the domain part after '@'), identifying the I-fax device on the global e-mail system.

email

protocol-element §2

The qualif-type1 element for fax is an OPTIONAL element of the fax address but its support when present is REQUIRED, defined as '/T33S=' followed by one or more digits (sub-addr), per ITU T.33 subaddress routing.

email

protocol-element §2

The service-selector for the fax service is the literal string 'FAX'. This is the prefix used in the local-part of fax e-mail addresses.

email

security-consideration §6 SHOULD

Routing of fax e-mail is determined by DNS; a successful attack on DNS (via server compromise, counterfeit responses, or incorrect additional information) could force mail through a compromised gateway. Clients SHOULD ensure routing is based only on authoritative DNS answers and SHOULD employ DNS Security mechanisms (DNSSEC) once widely deployed to verify authenticity and integrity of mail routing records.

security, email, dns

wire-format §2

A fax-address is encoded as 'FAX=' followed by a global-phone and an optional '/T33S=' subaddress. The global-phone is a '+' character followed by one or more digits and optional written separators ('-' or '.').

email

wire-format §4

The complete fax-email address structure is: '[/] fax-address [/] '@' mta-I-fax', where the optional '/' characters may appear from legacy mail transport service gateways.

email