Route service mail through its exchanger

The exchanger must recognize the service domain as local even if it does not run that service.

• If a host provides a service with a defined role name but does not accept mail directly, RFC2142§1 requires an MX record set and acceptance of mail for that host’s domain by its exchangers.
• For the example FTP host files.picnic.example, the chosen record is MX10 inbox.picnic.example. The priority and hostnames are illustrative; no MX failover algorithm is taught here.
• The exchanger accepts mail addressed to ftp@files.picnic.example and delivers it to an appropriate FTP contact. The exchanger itself need not offer FTP.
• The exact addressed domain matters: serving picnic.example alone is not sufficient for files.picnic.example. A configuration missing the service domain stops at acceptance, not after a fictional successful delivery.
• The RFC also gives an NNTP example with different host and advertised Path domains. Both corresponding USENET addresses must be deliverable, potentially to different final destinations. The drawings use FTP to keep the MX example separate from the NNTP citation erratum.

Mail routes and mailbox targets here are schematic, not literal SMTP transcripts or a new rejection status code. The helper tests local-domain membership and alias presence; it does not perform DNS queries or send mail.