Summary

  • RFC 3965 treated fax-offramp dial-out as a separately authorized action, not a side effect that any email recipient should inherit.
  • Its reply-all example is a hypothetical replay warning: permission must be bound to the particular sender and message; the RFC does not report an actual exploit.

The fax machine was not the only thing that could be addressed by an email. In RFC 3965’s model, a message could also reach an Internet fax offramp: software that accepted mail and then placed an authorized telephone call toward a Group 3 fax device. The gateway therefore sat between two very different acts. One was relaying a message through Internet mail. The other could consume telephone capacity and money.

That boundary gave an ordinary email gesture an unexpected consequence. A recipient who chose “reply all” might send a new message to the same fax gateway that appeared among the original recipients. If the gateway treated the earlier sender’s permission as reusable, the reply could trigger another dial-out—even though the person who wrote the reply was not the sender whose authorization had enabled the first one. RFC 3965 describes this as a non-malicious example of replay. It is a threat model, not a report that a fax was actually resent or that a system was compromised.

The distinction starts with what the gateway receives. The RFC says the destination number and offramp host belong in Internet-mail transport fields such as SMTP RCPT TO; the local part is interpreted by the named mail transfer agent. The gateway is not merely a copy of the fax machine’s address book. It is the service that decides whether a message is allowed to cause a call. A deployment serving many fax users might operate as a mail transfer agent; a gateway for one recipient might behave more like a user agent.

Nor does an email address settle who sent the message. RFC 3965 warns that the actual sender can differ from the From or Sender header and the SMTP envelope’s MAIL FROM. SMTP does not inherently authenticate message authors. A gateway could authenticate an originator and consult a private authorization table, or filter by source host or network, but the RFC says Internet protocols had no standard authorization technique for this service. Its requirement is therefore about the boundary the service must preserve, not a standardized token format.

The rule is unusually specific: authorization should attach to both a particular sender and a particular message. That pairing prevents a grant made for one fax from silently becoming authority for a later message. It also makes clear why “the same recipient list” is not enough. A reply may inherit addresses while changing the author, content, purpose and time of the request. Conversation continuity is not authorization continuity.

There was another exposure at the same boundary. Information needed to place a call—such as a calling-card authorization number—could appear in address parameters and be printed on a fax cover page. RFC 3965 says senders should have a way to prevent that disclosure, while noting that standard protection mechanisms were not yet available. It also says a fax recipient needs enough information to trace the originator; From or MAIL FROM alone cannot carry that burden. Authorization, secrecy and accountability overlap, but none substitutes for the others.

Failure notices need the same separation. An SMTP relay failure calls for a failure message, preferably a Delivery Status Notification. A receiving device’s inability to process the TIFF content is a different event, with notice handled locally. Neither a successful mail relay nor a bounce proves whether a fax printed, was seen, or was accepted by a person. The specification describes the mail and gateway stages; it does not make them a single end-to-end receipt.

RFC 3965’s historical importance is in the mismatch it made explicit: an email thread can preserve its recipients while changing the authority of each message. A safe gateway cannot infer permission from the fact that a fax address was copied forward. It must ask whose authorization applies to this message and this dial-out. The standard records that design problem; it does not establish how widely any particular gateway solved it.

Sources: RFC 3965, RFC 2305, RFC 3191, RFC 3192, RFC 3461, RFC 3464, RFC 5321, RFC 5322, RFC 3949, RFC 2306.