FidoNet over Email

Email-only nodes. A node is counted as email-only when its nodelist entry offers no other way to deliver mail: no Internet session flag (IBN, IFC, ITN, IVM, IFT or the generic IP) and no dialable phone number. INA does not count — it is an address, not a transport. Such a node may still pick mail up from its host or hub; the nodelist simply publishes nothing that could deliver to it except email.

What these flags mean. FTS-5001 defines five flags for carrying FidoNet mail over Internet email: IEM, ITX, IUC, IMI and ISE. They are capability advertisements, not a single protocol — a flag may name an encoding without defining a complete message format. EMA and EVY appear in real nodelists but in no FTSC document, and are shown here as non-standard.

Receipts. Only ITX and ISE promise proof of delivery; FTS-5001 requires a node advertising either to send receipts within 24 hours. The other flags carry no acknowledgement, so SMTP acceptance says nothing about whether the FidoNet bundle was ever imported.

Only ISE is fully specified. SEAT (FTS-1025) is the one method in this group with a complete FTSC wire specification. IMI and IUC name an encoding — MIME, UUencode — but leave subject format, part ordering, filenames and duplicate detection undefined, so two implementations need a prior agreement to interoperate.

How the address is found. An address attached to the flag is used first; otherwise IEM supplies the default, per FTS-5001 (“sets the default email address for other flags”); otherwise an address published on another email flag is used, since the standard says to “look for addresses under any flag of the same type”. INA is never used — it is defined as the default for non-email flags only. Where the address came from something other than the flag itself, the row says so.

Some nodes publish the address in the Location or System Name field instead, where the flag list would be too long (FSP-1012 §2.3.4). That recovery is a heuristic and is off by default. Try it.