1.nr DR 1 \" this is a draft copy 2.nr si 3n 3.he 'SENDMAIL''%' 4.if \n(DR .fo '\*-DRAFT\*-'\*(td'\*-DRAFT\*-' 5.ls 2 6.+c 7.(l C 8.sz 14 9SENDMAIL \*- An Internet Mail Router 10.sz 11.sp 12Eric Allman\(dg 13.sp 0.5 14.i 15Project INGRES 16Electronics Research Lab 17University of California 18Berkeley, California 94720 19.)l 20.sp 2 21.(f 22This is 23.if \n(DR draft 24version 3.17, 25last modified on 02/27/82. 26.if \n(DR Please do not distribute this version without permission 27.if \n(DR of the author. 28.)f 29.(f 30\(dgAuthor's current address: 31Britton-Lee, Inc. 321919 Addison Street, Suite 105. 33Berkeley, California 94704. 34.)f 35.pp 36.i Sendmail 37implements a general internetwork mail routing facility, 38featuring aliasing and forwarding, 39automatic routing to network gateways, 40and flexible configuration. 41.pp 42In the early days of computer networking, 43the problems of identification and communication 44were quite simple by today's standards. 45Each node on the network 46would have an address, 47and resources could be identified 48with a host-resource pair; 49in particular, 50the mail system could refer to users 51using a host-username pair. 52Host names and numbers had to be administered by a central authority, 53but usernames could be assigned locally to each host. 54One early example is the ARPANET. 55However, access to the ARPANET is limited, 56and the connection cost is high. 57Many alternative networks appeared, 58such as the Berkeley Network, 59the UUCP network, 60and the CHAOS network. 61Each network defined its own standards 62for resource identification. 63.pp 64As networks grew, 65they eventually touched. 66Certain special cases could be handled trivially 67by ad hoc techniques, 68as when one computer hung off another by a link, 69or by providing network names that appeared local to hosts 70on other networks, 71as with the Ethernet at Xerox PARC. 72The internet was born. 73.pp 74Internet topology became more complex with time. 75Two networks might touch 76in more than one place, 77and the rapid expansion of networks 78created a serious database update problem. 79Since all the address syntaxes were created arbitrarily, 80considerable confusion reigned. 81Some networks required point-to-point routing, 82which simplifies the database update problem 83since only adjacent hosts must be entered 84into the system tables, 85while others used end-to-end routing. 86Some networks used a left-associative syntax 87and others used a right-associative syntax: 88ambiguity raised its ugly head. 89.pp 90Internet proposals came to the rescue. 91Basically, these proposed expanding the address pairs 92to address triples, 93comprised of network-host-resource. 94Network numbers would be universally agreed upon, 95and hosts could be assigned in the old way 96on each network. 97But these proposals all tended to be far-reaching 98and fundamentally incompatible with the old networks. 99Protocols and proposals met to do battle. 100And there was the issue of assigning network numbers: 101there had to be a central clearing house, 102and any networks that might ever touch 103had to be given their very own number. 104Naturally, not everyone who thought they deserved a number 105got one. 106.pp 107Which brings us to today. 108Although it will be nice when everyone everywhere 109has a unique network number, 110it cannot be expected very soon. 111The old, stupid networks take time to die, 112and bureaucratic inertia is still the rule. 113.pp 114.i Sendmail 115is intended to help bridge the gap 116between the totally ad hoc world 117of networks that know nothing of each other 118and the clean, tightly-coupled world 119of unique network numbers. 120It uses old arbitrary address syntaxes 121and resolves ambiguities using heuristics 122specified by the system administrator 123who creates the configuration file. 124It helps guide the conversion of message formats 125between disparate networks. 126In short, 127.i sendmail 128is glue that holds the world together 129until the new world is ready to be inhabited. 130However, it is not unreasonable to expect 131escrow to take several years to close on this 132new world. 133.sp 134.pp 135Section 1 discusses the design goals for 136.i sendmail . 137Section 2 gives an overview of the basic functions of the system. 138In section 3, 139details of usage are discussed. 140A detailed description of the configuration file 141is given in section 4, 142including a walkthrough of a specific configuration file. 143Section 5 compares 144.i sendmail 145to other internet mail routers, 146and an evaluation of 147.i sendmail 148is given in section 6, 149including future plans. 150.sh 1 "DESIGN GOALS" 151.pp 152.i Sendmail 153is an outgrowth of 154.i delivermail, 155a previous incarnation of a UNIX internetwork mail router. 156.i Delivermail 157was written relatively quickly. 158The first version could only parse addresses based on single 159characters embedded in the address, 160required explicit 161description of gateways, 162and had only limited aliasing; 163automatic forwarding of messages to another gateway and other features 164came later. 165.pp 166Design goals for 167.i delivermail 168included: 169.np 170Compatibility with the existing mail system, 171including Bell version 6 mail, 172Bell version 7 mail 173[UNIX80], 174Berkeley 175.i Mail 176[Shoens79], 177BerkNet mail 178[Schmidt79], 179and hopefully UUCP mail 180[Nowitz78a, Nowitz78b]. 181ARPANET mail 182[Crocker77a, Postel77] 183was also required. 184.np 185Reliability, in the sense of guaranteeing 186that every message is correctly delivered 187or at least brought to the attention of a human 188for correct disposal; 189no message should ever be completely lost. 190This was considered essential 191because of the emphasis on mail in our environment. 192This turned out to be one of the hardest goals to satisfy, 193especially in the face of the many anomalous message formats 194produced by various ARPANET sites. 195For example, 196certain sites generate incorrect from addresses 197which caused error message loops. 198Some hosts use blanks in names, 199which created problems with 200UNIX mail programs that assume that an address 201is one word. 202And at least one person lists his address as 203.q "From: the TTY of ..." , 204giving a 205.q Sender: 206field with his real address. 207In summary, 208the obscure aspects of the ARPANET mail protocol 209really 210.i are 211used and 212are difficult to support, 213but must be supported. 214But even obeying the standard is insufficient. 215For example, 216WHARTON changes our host name from 217.q BERKELEY 218to 219.q BERKEL- , 220which confused error processing. 221Degenerate cases such as this 222must be handled gracefully. 223.pp 224There were certain other non-goals in 225.i delivermail . 226These resulted from the expectation that 227it would only be used at Berkeley, 228and probably only at a few sites at Berkeley. 229.np 230It was fair game to compile configuration information 231into the code, 232even to assume that every host was running BerkNet. 233.np 234The problem of multiple gateways to a single network 235was not foreseen. 236For example, 237all UUCP mail was sent to a single gateway host. 238In fact, 239Berkeley has at least three UUCP gateway hosts. 240.np 241No attempt was made to reduce the volume of mail across a network link 242by sending only one copy of a message 243to multiple recipients on the same host. 244Besides the difficulty of doing this, 245we failed to appreciate how much volume there would be. 246For example, 247one of our gateways processed a message approximately 248every twenty seconds 249during peak hours, many of which were duplicates. 250.np 251Existing software to do actual delivery 252should be used whenever possible. 253This resulted as much from political and practical considerations 254as technical. 255.pp 256This resulted in an architecture illustrated in figure 1. 257.(z 258.hl 259.ie t \ 260. sp 18 261.el \{\ 262.(c 263+---------+ +---------+ +---------+ 264| sender1 | | sender2 | | sender3 | 265+---------+ +---------+ +---------+ 266 | | | 267 +----------+ + +----------+ 268 | | | 269 v v v 270 +-------------+ 271 | delivermail | 272 +-------------+ 273 | | | 274 +----------+ + +----------+ 275 | | | 276 v v v 277+---------+ +---------+ +---------+ 278| mailer1 | | mailer2 | | mailer3 | 279+---------+ +---------+ +---------+ 280.)c 281.\} 282 283.ce 284Figure 1 \*- Delivermail System Structure. 285.hl 286.)z 287The user interacts with a mail generating and sending program. 288When the mail is created, 289the generator calls 290.i delivermail , 291which routes the message to the correct mailer(s). 292Since some of the senders may be network servers 293and some of the mailers may be network users, 294.i delivermail 295may be used as an internet mail gateway. 296.pp 297.i Sendmail 298maintained the goals of 299.i delivermail. 300Time was less of a constraint, 301but not reimplementing basic mailers 302has proven to be a wise move in many ways. 303For example, 304many internet mailers deliver local mail directly. 305This is more efficient, 306but builds in the design decisions 307of the local mailer, 308and makes it difficult to concentrate 309on the 310.q "real problems" 311(such as locking). 312Other design goals were: 313.np 314.i Sendmail 315should operate in more complex environments, 316including multiple 317connections to a single network type 318(such as with multiple UUCP or Ether nets 319[Metcalfe76]), 320requiring that the contents of an address 321be considered 322as well as the syntax, 323in order to determine the gateway to use. 324For example, 325the ARPANET is bringing up a new protocol 326called TCP to replace the old NCP protocol. 327No host at Berkeley runs both TCP and NCP, 328so it is necessary to look at the ARPANET host name 329to determine whether to route mail to an NCP gateway 330or a TCP gateway. 331.np 332Configuration should not be compiled into the code. 333A single binary should be able to run as is at any site 334(modulo such basic changes as the CPU type or the operating system). 335We have found this seemingly unimportant goal 336to be critical in real life. 337Besides the simple problems that occur when any program gets recompiled 338in a different environment, 339many sites like to 340.q fiddle 341with anything that they will be recompiling anyway. 342.np 343.i Delivermail 344only knows about one alias file 345and per-user forwarding is unsupported. 346Berkeley is a sufficiently relaxed environment 347that the system alias file can be writable by everyone, 348but other environments are not so lax. 349Thus, 350.i sendmail 351must be able to let various groups maintain their own mailing lists, 352and let individuals specify their own forwarding, 353without writing the system alias file. 354.np 355Each user should be able to specify the mailer to execute 356to process mail being delivered for them. 357This allows users who are using specialized mailers 358that want to use a different format to build their environment 359without changing the system, 360and allows specialized functions 361(such as returning an 362.q "I am on vacation" 363message). 364.np 365Network traffic should be minimized 366by batching addresses to a single host where possible, 367without assistance by the user. 368.sh 1 "OVERVIEW" 369.sh 2 "System Organization" 370.pp 371.i Sendmail 372neither interfaces with the user 373nor does actual mail delivery. 374Rather, 375it collects a message 376generated by a user interface program (UIP) 377such as Berkeley 378.i Mail , 379MS 380[Crocker77b], 381or MH 382[Borden79], 383edits the message as required by the destination network, 384and calls appropriate mailers 385to do mail delivery or queueing for network transmission\**. 386.(f 387\**except when mailing to a file, 388when 389.i sendmail 390does the delivery directly. 391.)f 392This discipline allows the insertion of new mailers 393at minimum cost. 394In this sense 395.i sendmail 396resembles the Message Processing Module (MPM) 397of [Postel79b]. 398.sh 2 "Operational Description" 399.pp 400When an agent wants to send a message, 401it does a normal program call to 402.i sendmail . 403The arguments it passes include flags giving options 404and a list of addresses of intended recipients. 405It then writes the message to be sent to the standard input 406of 407.i sendmail . 408.i Sendmail 409delivers the message if possible, 410saving a copy of it if there were errors, 411and returns an exit status code 412telling what (if anything) went wrong. 413.pp 414The message should have a header at the beginning. 415The header is formatted as a series of lines 416of the form 417.(b 418field-name: field-value 419.)b 420Field-value can be split across lines by starting the following 421lines with a space or a tab. 422The header is separated from the body of the message 423by a blank line. 424No formatting requirements are imposed on the message 425except that they must be lines of text 426(i.e., binary data is not allowed). 427.sh 3 "Argument processing and address parsing" 428.pp 429The arguments to 430.i sendmail 431are first scanned, 432and flag arguments processed. 433The remaining arguments are 434parsed in turn as addresses, 435and a list of recipients is created. 436Aliases are expanded at this step. 437As much validation as possible of the addresses 438is done at this step: 439syntax is checked, and local addresses are verified, 440but detailed checking of host names and addresses 441is deferred until delivery. 442Forwarding is also performed 443as the local addresses are verified. 444.pp 445.i Sendmail 446appends each address 447to the recipient list after parsing. 448When a name is aliased or forwarded, 449the old name is retained in the list, 450and a flag is set in the address header 451that tells the delivery phase 452to ignore this recipient. 453This list is kept without duplicates, 454preventing alias loops 455and eliminating people receiving two copies of a message, 456as might occur if a person were in two groups. 457.sh 3 "Message collection" 458.pp 459.i Sendmail 460then collects the message from the standard input. 461The message header is parsed at this point. 462The header is stored in memory, 463and the body of the message is saved 464in a temporary file. 465.pp 466The message is still collected even if no addresses were valid 467to simplify program interface. 468The message will be returned with an error. 469.sh 3 "Message delivery" 470.pp 471For each unique mailer and host in the send list, 472.i sendmail 473calls the appropriate mailer. 474Each mailer invocation sends to all users receiving the message on one host. 475Mailers that only accept one user at a time 476are handled properly. 477.pp 478The message is sent to the mailer 479(which must read its standard input) 480prepended by a customized header. 481The mailer exit status code is caught and checked, 482and a suitable error message given as appropriate. 483The exit code must conform to a system standard 484or a meaningless message 485(\c 486.q "Service unavailable" ) 487is given. 488.sh 3 "Queueing for retransmission" 489.pp 490If the mailer returned an error status that 491indicated that it might be able to handle the mail later, 492.i sendmail 493will queue the mail and try again later. 494.sh 3 "Return to sender" 495.pp 496If errors occurred during processing, 497.i sendmail 498returns the message to the sender for retransmission. 499The letter can be mailed back 500or written in the file 501.q dead.letter 502in the sender's home directory\**. 503.(f 504\**Obviously, if the site giving the error is not the originating 505site, the only reasonable option is to mail back to the sender. 506Also, there are many more error disposition options, 507but they only effect the error message \*- the 508.q "return to sender" 509function is always handled in one of these two ways. 510.)f 511.sh 2 "Configuration File" 512.pp 513Almost all configuration information is read at runtime 514from an ASCII file, 515encoding 516macro definitions 517(defining the value of macros used internally), 518header declarations 519(telling sendmail the format of header lines that it will process specially, 520i.e., lines that it will add or reformat), 521mailer definitions 522(giving information such as the location and characteristics 523of each mailer), 524and address rewriting rules 525(a limited production system to rewrite addresses 526which is used to effectively parse the addresses). 527.sh 3 Macros 528.pp 529Macros can be used in three ways. 530Certain macros transmit 531unstructured textual information 532into the mail system, 533such as the name 534.i sendmail 535will use to identify itself in error messages. 536Other macros transmit information from 537.i sendmail 538to the configuration file 539for use in creating other fields 540(such as argument vectors to mailers); 541e.g., the name of the sender, 542and the host and user 543of the recipient. 544Other macros are unused internally, 545and can be used as shorthand in the configuration file. 546.sh 3 "Header declarations" 547.pp 548Header declarations inform 549.i sendmail 550of the format of known header lines. 551Knowledge of a few header lines 552is built into 553.i sendmail , 554such as the 555.q From: 556and 557.q Date: 558lines. 559.pp 560Most configured headers 561will be automatically inserted 562in the outgoing message 563if they don't exist in the incoming message. 564Certain headers are suppressed by some mailers. 565.sh 3 "Mailer declarations" 566.pp 567Mailer declarations tell 568.i sendmail 569of the various mailers available to it. 570The definition specifies the internal name of the mailer, 571the pathname of the program to call, 572some flags associated with the mailer, 573and an argument vector to be used on the call; 574this vector is macro expanded before use. 575.sh 3 "Address rewriting rules" 576.pp 577The heart of address parsing in 578.i sendmail 579is a set of rewriting rules. 580These are an ordered list of pattern-replacement rules, 581(somewhat like a production system, 582except that order is critical), 583which are applied to each address. 584The address is rewritten textually until it is either rewritten 585into a special canonical form 586(i.e., 587a (mailer, host, user) 5883-tuple, 589such as (arpanet, usc-isif, postel) 590representing the address 591.q "postel@usc-isif" ), 592or it falls off the end. 593When a pattern matches, 594the rule is reapplied until it fails. 595.sh 2 "Message Header Editing" 596.pp 597Certain editing of the message header 598occurs automatically. 599Header lines can be inserted 600under control of the configuration file. 601Some lines can be merged; 602for example, 603a 604.q From: 605line and a 606.q Full-name: 607line can be merged under certain circumstances. 608.sh 1 "USAGE AND IMPLEMENTATION" 609.sh 2 "Arguments" 610.pp 611Arguments may be flags and addresses. 612The flag arguments are described in Appendix A. 613Following flag arguments, 614address arguments may be given, 615unless we are running in SMTP mode. 616These follow the syntax in RFC733 617[Crocker77a] 618for ARPANET 619address formats. 620In brief, the format is: 621.np 622Anything in parentheses is thrown away 623(as a comment). 624.np 625Anything in angle brackets (\c 626.q "<>" ) 627is preferred 628over anything else. 629This implements the ARPANET standard that addresses of the form 630.(b 631username <machine-address> 632.)b 633will send to the electronic 634.q machine-address 635rather than the human 636.q username. 637.np 638Double quotes 639(\ "\ ) 640quote phrases; 641backslashes quote characters. 642Backslashes are more powerful 643in that they will cause otherwise equivalent phrases 644to compare differently \*- for example, 645.i user 646and 647.i 648"user" 649.r 650are equivalent, 651but 652.i \euser 653is different from either of them. 654.pp 655The rewriting rules control remaining parsing. 656(Disclaimer: some special processing is done 657after rewriting local names; see below.) 658Parentheses, angle brackets, and double quotes 659must be properly balanced and nested. 660.sh 2 "Simple Mail Transfer Protocol" 661.pp 662The Simple Mail Transfer Protocol 663(SMTP) 664[Postel81] 665can be used on input by specifying the 666.b \-as 667flag. 668This will cause 669.i sendmail 670to use a verbose protocol on its standard input and output 671which is useful over certain types of networks. 672If SMTP is used, 673no addresses are passed on the command line; 674these are sent over the standard input instead. 675.sh 2 "Mail to Files and Programs" 676.pp 677Files and programs are legitimate message recipients. 678Files provide archival storage of messages, 679useful for project administration and history. 680Programs are useful as recipients in a variety of situations, 681for example, 682as a public repository of systems messages 683(such as the Berkeley 684.i msgs 685program, 686or the MARS system 687[Sattley78]). 688.pp 689Any address passing through the initial parsing algorithm 690as a local address 691(i.e, not appearing to be a valid address for another mailer) 692is scanned for two special cases. 693If prefixed by a vertical bar (\c 694.q \^|\^ ) 695the rest of the address is processed as a shell command. 696If the user name begins with a slash mark (\c 697.q /\^ ) 698the name is used as a file name, 699instead of a login name. 700.pp 701Files that have setuid or setgid bits set 702but no execute bits set 703have those bits honored if 704.i sendmail 705is running as root. 706.sh 2 "Aliasing, Forwarding, Inclusion" 707.pp 708.i Sendmail 709reroutes mail three ways. 710Aliasing applies system wide. 711Forwarding allows each user to reroute incoming mail 712destined for that account. 713Inclusion directs 714.i sendmail 715to read a file for a list of addresses, 716and is normally used 717in conjunction with aliasing. 718.sh 3 "Aliasing" 719.pp 720Aliasing maps names to address lists using a system-wide file. 721This file is inverted to speed access. 722Only names that parse as local 723are allowed as aliases; 724this guarantees a unique key. 725.sh 3 "Forwarding" 726.pp 727After aliasing, 728users that are local and valid 729are checked for the existence of a 730.q .forward 731file in their home directory. 732If it exists, 733the message is 734.i not 735sent to that user, 736but rather to the list of users in that file. 737The expectation is that this will normally 738be one user only, 739and the use will be for network mail forwarding. 740.pp 741Forwarding also permits a user to specify a private incoming mailer. 742For example, 743forwarding to: 744.(b 745"\^|\|/usr/local/newmail myname" 746.)b 747will use a different incoming mailer. 748.sh 3 "Inclusion" 749.pp 750Inclusion is specified in ARPANET syntax: 751.(b 752:Include: pathname 753.)b 754An address of this form reads the file specified by 755.i pathname 756and sends to all users listed in that file. 757.pp 758The intent is 759.i not 760to support direct use of this feature, 761but rather to use this as a subset of aliasing. 762For example, 763an alias of the form: 764.(b 765project: :include:/usr/project/userlist 766.)b 767is a method of letting a project maintain a mailing list 768without interaction with the system administration, 769even if the alias file is protected. 770.pp 771It is not necessary to rebuild the alias database 772when a :include: list is changed. 773.sh 2 "Message Delivery" 774.pp 775Internally, 776the recipient list is stored as one list per mailer. 777Each mailer list can be scanned trivially 778and mail to each host picked out to implement message batching. 779Each address is marked as it is sent, 780so rescanning the list is safe; 781this makes sending to mailers that can only accept one user easy. 782An argument list is built as the scan proceeds. 783Mail to files is detected during the scan of the send list. 784.pp 785When an argument vector is built, 786.i sendmail 787creates a pipe and subprocess for the mailer. 788The parent calls an 789.q "editing function" 790which makes the per-mailer changes to the header 791and sends the result to the mailer; 792a different editing function is used for sending error messages 793which prepends the error information. 794.pp 795The exit status from the mailer is collected 796after the message is sent, 797and a diagnostic is printed if appropriate. 798If any mail is rejected by the mailer, 799a flag is set to invoke the return-to-sender function 800after all delivery completes. 801.sh 2 "Exit Status" 802.pp 803.i Sendmail 804defines a set of standard exit status codes 805that should be returned by mailers. 806These are in turn returned by 807.i sendmail . 808.sh 2 "Queued Messages" 809.pp 810If the mailer gave a 811.q "temporary failure" 812exit status, 813the message is queued. 814A control file is used to describe the recipients to be sent to 815and various other parameters. 816.sh 2 "Interaction With Other Mailers" 817.pp 818Two examples of how network-specific work is passed to other programs 819are the incoming UUCP mailer 820(\c 821.i rmail ) 822and the outgoing ARPANET mailer. 823.sh 3 "Incoming UUCP mail" 824.pp 825Mail coming in from the UUCP network 826is not guaranteed to have a normal header line, 827nor will an argument be passed telling who it is from\**. 828.(f 829\**As a result of this, 830it is impossible to verify UUCP sender addresses. 831.)f 832Fortuitously, 833UUCP mail calls the program 834.i rmail 835rather than 836.i mail 837or 838.i sendmail . 839The 840.i rmail 841program has been modified here to do the special-purpose parsing 842necessary to decode UUCP headers 843and turn them into a normal UUCP address; 844this address is then passed to 845.i sendmail . 846.sh 3 "Outgoing ARPANET mail" 847.pp 848The ARPANET imposes many standards that 849.i sendmail 850does not care to enforce. 851For example, 852an arpanet sitename must be on 853.i every 854address, 855not just the 856.q "From:" 857address. 858Certain UNIX sites like to use 859.q % 860as an alternative to 861.q @ , 862which must be translated. 863The outgoing ARPANET mailer makes these transformations 864before passing the message to the network. 865.sh 1 CONFIGURATION 866.pp 867Configuration is controlled primarily by the file 868.i /usr/lib/sendmail.cf . 869.i Sendmail 870should not need to be recomplied except 871.np 872To change operating systems 873(V6, V7/32V, 4BSD). 874.np 875To remove or insert the DBM 876(UNIX database) 877library. 878.np 879To change ARPANET reply codes. 880.np 881To add headers requiring special processing. 882.lp 883Adding mailers or changing parsing 884(i.e., rewriting) 885or routing information 886does not require recompilation. 887.pp 888If the mail is being sent by a local user, 889and the file 890.q .mailcf 891exists in the sender's home directory, 892that file is read as a configuration file 893after the system configuration file. 894The primary use of this is to add header lines. 895This could also be used to adjust the full name by 896defining the 897.b x 898macro; e.g., 899.(b 900DxEric Allman in Outer Space 901.)b 902.sh 2 "Configuration File Description" 903.pp 904The configuration file is formatted 905as a series of text lines, 906each beginning with a character describing its semantics. 907Blank lines and lines beginning with a sharp sign 908(#) 909are ignored. 910Other lines are: 911.(b 912.ta 3n 913D define macro 914H define header 915M define mailer 916S use rewriting set 917C define word class 918F define word class from file 919R specify rewriting rule 920.)b 921.pp 922See figure 2 for an example configuration file. 923Please note that this is intended as an example only. 924.(z 925.hl 926.sz -2 927.re 928##### sendmail configuration file 929.sp \n(psu 930### local hosts on various nets 931DABerkeley 932DBIngVAX 933DUucbvax 934.sp \n(psu 935### special macros 936# my name 937D\&n\&MAILER-DAEMON 938# UNIX header format 939D\&l\&From $g $d 940# delimiter (operator) characters 941D\&o\&.:@!^ 942# address writing style 943D\&q\&$g$?x ($x)$. 944.sp \n(psu 945### format of headers: 946H\&Date: $a 947H\&From: $g$?x ($x)$. 948H\&Full-Name: $x 949H\&Message-Id: <$t.$p.$B@$A> 950H\&Posted-Date: $a 951.sp \n(psu 952### name classifications 953# arpanet hostnames 954C\&A\&ucb berkeley 955# list of local host names 956C\&B\&j IngVax 957# berknet hosts on the arpanet 958C\&C\&i ingres ing70 959# uucp hostnames 960C\&U\&ucbvax ernie 961.sp \n(psu 962.ta \w'M\&local 'u +\w'/usr/net/bin/sendberkmail 'u +\w'rlsAmn 'u +\w'$f@$A 'u 963### mailers 964M\&local /bin/mail rlsAmn $f ...local\&mail -d $u 965M\&prog /bin/csh lA $f ...prog\&mail -fc $u 966M\&berk /usr/net/bin/sendberkmail fxs $B:$f ...berk\&mail -m $h -h $c -t $u 967M\&arpa /usr/lib/mailers/arpa sAu $f@$A ...arpa\&mail $f $h $u 968M\&uucp /usr/bin/uux rsDxmU $U!$f ...uucp\&mail - $h!rmail ($u) 969M\&xlate / A $f / 970.sp \n(psu 971### rewriting rules 972.ta \w'R\&CSVAX:$-h!$+u 'u +\w'$#berk$@ing70$:$+u@$+h 'u 973R\&$-.$+ $1:$2 change "." to ":" 974R\&$=C:$+@$- $2@$3 delete ing70: on arpanet addresses 975R\&$+@$=A ing70:$1 delete local arpa hosts 976R\&$+@$- $#berk$@ing70$:$1@$2 send arpa mail to ing70 977R\&$+^$+ $1!$2 change "^" to "!" 978R\&$-!$=U!$+ csvax:$3 delete uucp loops through csvax 979R\&$-!$+ csvax:$1!$2 send uucp mail to csvax 980R\&$-:$-:$+ $2:$3 delete multiple berk hosts 981R\&$=B:$+ $2 delete local berk hosts 982R\&$-:$+ $#berk$@$1$:$2 resolve berk mail 983R\&$+ $#local$:$1 resolve local mail 984.sp \n(psu 985### rewriting rules for from host 986S\&1 987R\&ing70:$+@$- $1@$2 arpanet mail is automatic 988R\&CSVAX:$-!$+ $1!$2 uucp mail is automatic 989.sp \n(psu 990### rewriting rules for translated sender 991S\&2 992R\&$-x:$-:$+ $2:$3 delete multiple berknet hosts 993.sz 994.sp 995.ce 996Figure 2. Sample configuration file. 997.hl 998.)z 999.sh 3 "D \*- define macro" 1000.(b 1001.b D \c 1002.i x\|val 1003.)b 1004.pp 1005This line defines a macro 1006with the single character name 1007.i x 1008and value 1009.i val . 1010Macros can be interpolated using the escape 1011.b $ \c 1012.i x , 1013where 1014.i x 1015is the macro name. 1016By convention, 1017all upper-case letters are unused by 1018.i sendmail 1019and may be used freely by the user; 1020all other names are reserved for use by sendmail. 1021Certain macros 1022.i must 1023be defined, 1024and are used internally. 1025These are: 1026.(b 1027.ta 4n 1028$l UNIX-style \*(lqFrom\*(rq line. 1029$n My address in error messages. 1030$o \*(lqOperators\*(rq in addresses. 1031$q How to write addresses in headers. 1032.)b 1033The 1034.b $l 1035macro is expanded when 1036.i sendmail 1037wants to insert a UNIX-style 1038.q From 1039line on messages. 1040This typically expands to something like: 1041.(b 1042From sally Wed Aug 12 09:15:13 1981 1043.)b 1044The 1045.b $n 1046macro is used as the name of this process 1047when error messages are being mailed back. 1048Typically, 1049it is wise to include an alias 1050so that mail to this address will be sent to root. 1051The 1052.b $o 1053macro defines the characters 1054that will separate words when addresses are being broken up. 1055Each of these becomes a word by itself when scanned. 1056Blanks and tabs are built-in separators 1057but are ignored, 1058i.e., are not turned into words. 1059For example, the input: 1060.(b 1061Ing70: ZRM @ MIT-MC SRI-KL 1062.)b 1063Is broken up into the six words: 1064.(b 1065Ing70, :, ZRM, @, MIT-MC, SRI-KL 1066.)b 1067assuming that colon and at-sign are operators 1068(but hyphen is not). 1069The 1070.b $q 1071macro gives the format for addresses 1072as they should appear in headers. 1073This will normally be something like: 1074.(b 1075$g$?x ($x)$. 1076.)b 1077Which will give the translated from address 1078followed by the full name if known. 1079.pp 1080A number of macros are defined by 1081.i sendmail 1082for use as primitives. 1083These are: 1084.(l 1085.ta 5n 1086$a The \*(lqDate:\*(rq line date in ARPANET format. 1087$b The current date in ARPANET format. 1088$c The hop count. 1089$d The date in UNIX (ctime) format. 1090$f The sender's (from) address. 1091$g The sender's address translated by the mailer. 1092$h The host of the recipient. 1093$p The process id of sendmail in decimal. 1094$t The time in seconds in decimal. 1095$u The user part of the recipient. 1096$v The version number of sendmail. 1097$x The full name of the sender. 1098$y The id of the sender's terminal. 1099$z The home directory of the recipient. 1100.)l 1101.pp 1102There are three types of dates that can be used. 1103The 1104.b $a 1105and 1106.b $b 1107macros are in ARPANET format; 1108.b $a 1109is a copy of the time extracted from the 1110.q Date: 1111field of the incoming message 1112(if there was one), 1113and 1114.b $b 1115is the current date and time \*- used for postmarks. 1116If no 1117.q Date: 1118is found in the message, 1119they are the same. 1120The 1121.b $d 1122macro has the date in UNIX 1123.i ctime 1124format; 1125this is extracted from the message if possible 1126and is otherwise the current date. 1127.pp 1128The 1129.b $f 1130macro is the id of the sender 1131as originally determined; 1132when mailing to a specific person, 1133the 1134.b $g 1135macro is the address of the sender 1136with respect to the receiver. 1137For example, 1138if I send to 1139.q csvax:samwise 1140the 1141.b $f 1142and 1143.b $g 1144macros are: 1145.(b 1146.ta 4n 1147$f eric 1148$g IngVAX:eric 1149.)b 1150This only applies to the first step in the link. 1151For example, 1152sending to Ing70:drb@bbn-unix, 1153we have 1154.b $f 1155and 1156.b $g 1157as above for the transfer to Ing70, but: 1158.(b 1159$f IngVAX:eric 1160$g IngVAX:eric@Berkeley 1161.)b 1162for transfer to the ARPANET\**. 1163.(f 1164\**When this is actually sent to the ARPANET, 1165this will appear as 1166IngVAX.eric@Berkeley. 1167The translation of the colon to a period is performed 1168by the mailer that queues ARPANET mail. 1169.)f 1170.pp 1171The 1172.b $x 1173macro is set to the full name of the sender. 1174This can be determined in several ways. 1175It can be passed as a flag to 1176.i sendmail . 1177The 1178.q Full-Name: 1179line in the header is the second option, 1180and the comment portion of the 1181.q From: 1182line is the third. 1183If all of these fail, 1184and if the message is being originated locally, 1185the full name is looked up in the 1186.i passwd 1187file. 1188.pp 1189When sending, the 1190.b $u , 1191.b $h , 1192and 1193.b $z 1194macros get set to the user, host, and home directory 1195(respectively) 1196of the receiver. 1197The host is only set if the user is not local, 1198and the home directory is only set if the user is local. 1199.pp 1200The 1201.b $p 1202and 1203.b $t 1204macros are used to create unique strings. 1205The 1206.b $y 1207macro is set to the id of the terminal of the sender 1208(if known); 1209some systems like to put this in the 1210.q From 1211line. 1212The 1213.b $v 1214macro is set to the version number of 1215.i sendmail , 1216and can be used in postmarks 1217to help debugging. 1218.pp 1219A primitive conditional is available during macro expansion. 1220The construct: 1221.(b 1222$?x text1 $: text2 $. 1223.)b 1224tests if macro 1225.b $ \c 1226.i x 1227is defined. 1228If it is, 1229text1 is interpolated; 1230otherwise, 1231text2 is interpolated. 1232.sh 3 "H \*- define header" 1233.(b 1234.b H \c 1235.i "Field-Name" \c 1236.b ":" " \c 1237.i "field value" 1238.)b 1239.pp 1240The 1241.b H 1242line looks like a regular header line, 1243except that the field value is macro expanded 1244before use. 1245All headers mentioned in this way 1246are automatically inserted 1247into every message 1248except for headers mentioned in the compile-time 1249configuration file 1250.i conf.c . 1251These headers are 1252Date, 1253From, 1254Full-Name, 1255Message-Id, 1256and 1257Received-Date. 1258To get these fields the appropriate flag 1259must be specified 1260for the receiving mailer. 1261.pp 1262Since the file 1263.q ".mailcf" 1264in the sender's home directory is read and processed, 1265it is possible to add customized header lines. 1266For example, 1267the .mailcf consisting of: 1268.(b 1269H\&Phone: (415) 888-7770 1270.)b 1271will add that line to every outgoing message. 1272.sh 3 "M \*- define mailer" 1273.(b F 1274.b M \c 1275.i mailer-name 1276.i pathname 1277.i flags 1278.i from-macro 1279.i "argument list" 1280.)b 1281.pp 1282This line is structured into fields 1283separated by white space (spaces or tabs). 1284The fields are: 1285.np 1286The internal name of the mailer, 1287referred to in the rewriting rules. 1288.np 1289The pathname of the program to execute for this mailer. 1290.np 1291The flags for this mailer, 1292described below. 1293.np 1294The macro string to become the 1295.b $g 1296macro (translated sender) 1297for this mailer. 1298.np 1299The argument vector passed to the mailer 1300(macro expanded). 1301.pp 1302The flags are a series of characters: 1303.ls 1 1304.ip f 1305The mailer wants a 1306.b \-f 1307.i from 1308flag, 1309but only if this is a network forward operation 1310(i.e., 1311the mailer will give an error 1312if the executing user does not have special permissions). 1313.ip r 1314Same as 1315.b f , 1316but sends a 1317.b \-r 1318flag. 1319.ip q 1320Don't print errors \*- the mailer will do it for us. 1321.ip S 1322Don't reset your userid before calling the mailer. 1323This would be used in a secure environment where 1324.i sendmail 1325ran as a special user. 1326This could be used to prevent 1327(or at least complicate) 1328forged addresses. 1329This option is suppressed in 1330.q unsafe 1331configuration files 1332(i.e., user-supplied, either on a 1333command line 1334option, or in the 1335.i \&.mailcf 1336file in the home directory). 1337.ip n 1338This mailer does not want a UNIX-style 1339.q From 1340line on the message. 1341.ip l 1342This mailer is local, 1343so no host will be specified. 1344Also, 1345the mailer wants special local processing 1346(such as a 1347.q Received-Date: 1348field). 1349.ip s 1350Strip quote characters off of addresses 1351before calling the mailer. 1352.ip m 1353This mailer can send to multiple users 1354(on the same host) 1355in one call. 1356.ip F 1357This mailer wants a 1358.q From: 1359header line. 1360.ip D 1361This mailer wants a 1362.q Date: 1363header line. 1364.ip M 1365This mailer wants a 1366.q Message-Id: 1367header line. 1368.ip x 1369This mailer wants a 1370.q Full-Name: 1371header line. 1372.ip u 1373Upper case should be preserved in user names. 1374.ip h 1375Upper case should be preserved in host names. 1376.ip e 1377This mailer is expensive, 1378and it may be desirable to limit usage. 1379.ip A 1380This mailer wants an ARPANET standard header 1381(equivalent to the 1382.b F 1383and 1384.b D 1385flags). 1386.ip U 1387This mailer is a UUCP mailer that wants leading from lines 1388of the form: 1389.(b 1390From sender <date> remote from sysname 1391.)b 1392instead of the more reasonable: 1393.(b 1394From sysname!sender <date> 1395.)b 1396A compilation flag must be on to include this code. 1397.ls 1398.lp 1399There should always be at least one flag, 1400since every message should include either a 1401.b x 1402or a 1403.b F 1404flag. 1405.sh 3 "S \*- use rewriting set" 1406.(b 1407.b S \c 1408.i N 1409.)b 1410.pp 1411There are three sets of rewriting rules. 1412Set zero is used to rewrite recipient addresses. 1413Set one is used to rewrite sender addresses. 1414Set two is applied after evaluating the 1415.q $g 1416macro, 1417i.e., after determining the from address for a particular mailer. 1418.pp 1419Set one can be used to eliminate implicit links. 1420For example, 1421if there exists a site on on the BerkNet called 1422.q Ing70 1423which is an ARPANET gateway, 1424and we are on a site called 1425.q IngVAX , 1426ARPANET mail coming into 1427.q Ing70 1428for someone on 1429.q IngVAX 1430will read: 1431.(b 1432From: Ing70:auser@ahost 1433.)b 1434Rewriting set one can rewrite this as: 1435.(b 1436From: auser@ahost 1437.)b 1438since 1439.q Ing70 1440will be implied. 1441.pp 1442Set two is used to eliminate anomalies resulting from 1443forwarding. 1444For example, 1445a message received at Ing70 from mckusick on the CSVAX will 1446appear as: 1447.(b 1448From CSVAX:mckusick 1449.)b 1450If this is then forwarded to IngVAX, 1451sendmail on Ing70 will rewrite the from address as: 1452.(b 1453From Ing70:CSVAX:mckusick 1454.)b 1455The extra host reference can be eliminated by ruleset two on Ing70. 1456.pp 1457When you change to a new set, 1458the previous content of that set is cleared. 1459.sh 3 "R \*- rewriting rule" 1460.(b F 1461.b R \c 1462.i pattern 1463.i replacement 1464.i comments 1465.)b 1466.pp 1467The rewriting rules drive the address parser. 1468The rewriting process is essentially textual. 1469First, 1470the address to be rewritten is broken up into words. 1471Words are defined as strings of non-special characters 1472separated by white space or single special characters 1473as defined by the 1474.b $o 1475macro. 1476Then, 1477the words are rewritten using simple pattern matching. 1478Words in the pattern match themselves 1479unless they begin with dollar sign. 1480The dollar escapes have the following meanings\**: 1481.(f 1482\**These dollar escapes have nothing to do with macro expansion. 1483.)f 1484.(b 1485.ta 6n 1486$- Match a single word. 1487$+ Match one or more words. 1488$=c Match any word in class c (see below). 1489.)b 1490The case of letters is ignored in pattern matching 1491(including class comparisons). 1492.pp 1493When a pattern (also called a left hand side or LHS) 1494matches, 1495the input is rewritten as defined by the right hand side (RHS). 1496Acceptable escapes in the RHS are: 1497.(b 1498.ta \w'$#mailer 'u 1499$n Replace from corresponding match in LHS. 1500$#mailer Canonical mailer name. 1501$@host Canonical host name. 1502$:user Canonical user name. 1503.)b 1504The substitution from LHS to RHS is done by the index 1505of indefinite matches on the LHS. 1506Each pattern reexecutes until it fails. 1507As soon as the input resolves to a canonical name 1508(i.e., 1509.q "$#mailer$@host$:user" ), 1510rewriting ends; 1511otherwise, 1512the next pattern is tried. 1513The 1514.q "$@host" 1515part is not needed 1516if the mailer does not require a host. 1517The special mailer 1518.q error 1519causes the user part to be printed as an error. 1520.sh 3 "C \*- define word class" 1521.(b F 1522.b C \c 1523.i c\|word\&1 1524.i word\&2 ... 1525.)b 1526.pp 1527There are twenty six word classes, 1528represented as 1529.q A 1530through 1531.q Z . 1532For example: 1533.(b 1534CVcsvax ingvax esvax 1535.)b 1536defines the words 1537.q csvax , 1538.q ingvax , 1539and 1540.q esvax 1541to all be in class 1542.q V , 1543so that 1544.q $=V 1545on the LHS of a rewriting rule 1546will match any of these words. 1547.sh 3 "F \*- define word class from file" 1548.(b 1549.b F \c 1550.i c\&filename 1551.i format 1552.)b 1553.pp 1554This works analogously 1555to the 1556.b C 1557line except that it reads the contents of the class 1558from the given 1559.i filename . 1560If given, 1561the specified 1562.i format 1563is used as a 1564scanf(3) 1565string which should produce a single string. 1566.sh 2 "A Detailed Example" 1567.pp 1568We will now follow the configuration file 1569in figure 2 1570through in detail. 1571This example is from a version of the configuration file 1572for the IngVAX machine at Berkeley. 1573IngVAX had no interesting network connections. 1574Ing70 had an ARPANET connection, 1575and CSVAX had a UUCP connection. 1576All of these machines were tied together via BerkNet. 1577.sh 3 "Macro definitions" 1578.(b 1579DABerkeley 1580DBIngVAX 1581DUucbvax 1582DnMAILER-DAEMON 1583DlFrom $g $d 1584Do.:@!^ 1585Dq$g$?x ($x)$. 1586.)b 1587The first three macros are for convenience only, 1588and are used to define the local host names 1589on the ARPANET, BerkNet, and the UUCP net 1590respectively. 1591.pp 1592Macro 1593.b n 1594defines the name of 1595.i sendmail 1596when error messages are sent. 1597Macro 1598.b l 1599defines what the first line 1600of a message in UNIX format looks like, 1601in this case the version 7 standard of: 1602.(b 1603From sender-name time-of-submission 1604.)b 1605The 1606.b o 1607macro 1608tells what characters will be distinct from names 1609when scanning addresses. 1610In this case, 1611dot and colon will be used 1612to distinguish BerkNet addresses, 1613at sign for ARPANET addresses, 1614and exclamation point and caret for UUCP addresses. 1615.sh 3 "Header definitions" 1616.(b 1617H\&Date: $a 1618H\&From: $g$?x ($x)$. 1619H\&Full-Name: $x 1620H\&Message-Id: <$t.$p.$B@$A> 1621H\&Posted-Date: $a 1622.)b 1623These define the headers 1624that may be added to a message. 1625The 1626.q Date: 1627is just the ARPANET idea of the date. 1628The 1629.q From: 1630line is the translated version of the sender, 1631followed by the sender's full name if known. 1632The 1633.q Full-Name: 1634field is used to transmit the sender's full name 1635when a 1636.q From: 1637line is not being sent; 1638these will normally be mutually exclusive. 1639The 1640.q Message-Id: 1641field has the time and process id's concatenated 1642with the BerkNet and ARPANET addresses 1643to make a unique string. 1644Finally, the 1645.q Posted-Date: 1646is the date in ARPANET format; 1647it differs from 1648.q Date: 1649in that it is always output as soon as the message enters 1650.i sendmail 's 1651domain, 1652and hence indicates the time that the message first enters 1653the mail delivery system 1654[Postel79b, NBS80]. 1655.sh 3 "Name classifications" 1656.(b 1657C\&A\&ucb berkeley 1658C\&B\&j IngVax 1659C\&C\&i ingres ing70 1660C\&U\&ucbvax ernie 1661.)b 1662These commands put the words 1663.q ucb 1664and 1665.q berkeley 1666into class 1667.q A , 1668the valid names of this site on the ARPANET. 1669Words 1670.q j 1671and 1672.q ingvax 1673are in class 1674.q B , 1675the local names on BerkNet. 1676Class 1677.q C , 1678the names of the site which has the ARPANET link, 1679has the words 1680.q i , 1681.q ingres , 1682and 1683.q ing70 . 1684Finally, 1685.q ucbvax 1686and 1687.q ernie 1688are the UUCP names of our UUCP gateway, 1689and are in class 1690.q U . 1691.pp 1692The classes will be used in the patterns of the rewriting rules 1693as described below. 1694.sh 3 "Mailer definitions" 1695.(b 1696.if n .in 0 1697.if t .sz -2 1698.ta \w'M\&local 'u +\w'/usr/net/bin/sendberkmail 'u +\w'rlsAmn 'u +\w'$f@$A 'u 1699M\&local /bin/mail rlsAmn $f ...localmail -d $u 1700M\&prog /bin/csh lA $f ...progmail -fc $u 1701M\&berk /usr/net/bin/sendberkmail fxs $B:$f ...berkmail -m $h -h $c -t $u 1702M\&arpa /usr/lib/mailers/arpa sAu $f@$A ...arpamail $f $h $u 1703M\&uucp /usr/bin/uux rsDxmU $U!$f ...uucpmail - $h!rmail ($u) 1704M\&xlate / A $f / 1705.if n .in 1706.if t .sz 1707.)b 1708Six mailers are known in the configuration file. 1709There 1710.i must 1711be entries for local and program mail. 1712.pp 1713Local mail is sent using 1714/bin/mail. 1715It takes a 1716.b \-r 1717flag, 1718is local, 1719quote characters are stripped before sending, 1720takes ARPANET standard headers, 1721can deliver to multiple recipients at once, 1722and does not want a UNIX-style 1723.q From 1724line since it will add one itself. 1725The translated 1726.q from 1727address is the same as the raw 1728.q from 1729address, 1730since no network hops are made. 1731The argument vector has a program name, 1732a 1733.b \-d 1734flag (\c 1735.q "really deliver" , 1736which must be added to /bin/mail), 1737and the list of recipients \*- one recipient per argument. 1738.pp 1739Mail piped through programs 1740is interpreted by /bin/csh. 1741Unlike local mail, 1742it does not take a 1743.b \-r 1744flag, 1745quotes should be left, 1746it can only deal with one user, 1747and it does want a UNIX-style 1748.q From 1749line, 1750but is still local and still wants an ARPANET style header. 1751.pp 1752BerkNet mail is processed by 1753/usr/net/bin/sendberkmail. 1754It takes a 1755.b \-f 1756flag, 1757wants a 1758.q Full-Name: 1759header line, 1760and wants quotes stripped. 1761The 1762.q Full-Name: 1763is used here because if it were given as a comment 1764in a 1765.q From: 1766line the machine address of the sender 1767would not be modified by later instantiations of 1768.i delivermail \**. 1769.(f 1770\**\c 1771.i Delivermail 1772did no header editing, 1773so 1774.q From: 1775lines were always passed untouched. 1776When the gateways are converted to 1777.i sendmail 1778this can be changed. 1779.)f 1780The from address as seen by the receiver is 1781.q IngVAX:sender , 1782and it takes a flag-oriented 1783rather than a positional 1784command list. 1785.pp 1786The ARPANET wants quotes stripped, 1787ARPANET standard headers, 1788and wants the user name left with case intact. 1789It takes a positional command list. 1790.pp 1791UUCP mail calls 1792.i uux 1793with a 1794.b \-r 1795flag, 1796quotes stripped, 1797a 1798.q Date: 1799line, 1800a 1801.q Full-Name: 1802line, 1803and with multiple users listed. 1804Since UUCP is a relic of the (not so) distant past, 1805it requires ugly header lines. 1806.pp 1807The final entry is a dummy entry to declare the pseudo-mailer 1808.i xlate . 1809When this mailer is found 1810it causes a table lookup to be done in the alias file 1811using the host name as a key. 1812A 1813.q %s 1814in the value part is replaced by the user name. 1815The entire parsing mechanism is restarted when this is encountered. 1816.pp 1817If 1818.q $u 1819were to be missing from the argument vector for a mailer, 1820that mailer would be accessed using the SMTP [Postel81] 1821protocol. 1822.sh 3 "Rewriting rules for recipient addresses" 1823.(b 1824.sz -2 1825.ta \w'[88] 'u +\w'R\&CSVAX:$-h!$+u 'u +\w'$#berk$@ing70$:$+u@$+h 'u 1826[1] R\&$-.$+ $1:$2 change "." to ":" 1827[2] R\&$=C:$+@$- $2@$3 delete ing70: on arpanet addresses 1828[3] R\&$+@$=A ing70:$1 delete local arpa hosts 1829[4] R\&$+@$- $#berk$@ing70$:$1@$2 send arpa mail to ing70 1830[5] R\&$+^$+ $1!$2 change "^" to "!" 1831[6] R\&$-!$=U!$+ csvax:$3 delete uucp loops through csvax 1832[7] R\&$-!$+ csvax:$1!$2 send uucp mail to csvax 1833[8] R\&$-:$-:$+ $2:$3 delete multiple berk hosts 1834[9] R\&$=B:$+ $2 delete local berk hosts 1835[10] R\&$-:$+ $#berk$@$1$:$2 resolve berk mail 1836[11] R\&$+ $#local$:$1 resolve local mail 1837.sz 1838.)b 1839The first rule translates dots to colons. 1840Redundant explicit routing to the ARPANET is deleted 1841in the second rule. 1842Hops out over the ARPANET 1843back to us are deleted in the third rule \*- 1844note that the BerkNet host that we would have come in on 1845is inserted. 1846Real ARPANET mail is resolved immediately with no further ado \*- 1847it is sent out over the BerkNet to the ing70, 1848and further rewriting stops immediately. 1849.pp 1850Carets are changed to exclamation points 1851for UUCP addresses in the fifth rule. 1852The sixth rule deletes loops out into UUCP land 1853and back to us \*- noting that we will be left on CSVAX. 1854The seventh rule does forwarding of UUCP mail to the CSVAX. 1855Multiple BerkNet hosts are deleted in rule eight \*- 1856this can occur internally quite easily 1857as a side effect of a rewriting rule. 1858Rule nine deletes local BerkNet hosts. 1859The last two rules resolve BerkNet and local mail 1860by turning them into the canonical form: 1861.(b 1862$#\fInet\fP$@\fIhost\fP$:\fIuser\fP 1863.)b 1864.pp 1865Consider the following examples. 1866The numbers to the left are the rule that is being applied 1867to make the transformation. 1868.(b 1869.re 1870 esvax.asa 1871[1] esvax:asa 1872[10] $#berk$@esvax$:asa 1873.)b 1874.(b 1875 research^vax135^dmr 1876[5] research!vax135^dmr 1877[5] research!vax135!dmr 1878[7] $#berk$@csvax$:research!vax135!dmr 1879.)b 1880.(b 1881 research!ucbvax!j:eric 1882[6] csvax:j:eric 1883[8] j:eric 1884[9] eric 1885[11] $#local$:eric 1886.)b 1887.(b 1888 ing70:wnj@Berkeley 1889[2] wnj@Berkeley 1890[3] ing70:wnj 1891[10] $#berk$@ing70$:wnj 1892.)b 1893.sh 3 "Rewriting rules for sender addresses" 1894.(b 1895.sz -2 1896.ta \w'R\&CSVAX:$-h!$+u 'u +\w'$+u@$+h 'u 1897S\&1 1898R\&ing70:$+@$- $1@$2 arpanet mail is automatic 1899R\&CSVAX:$-!$+ $1!$2 uucp mail is automatic 1900.sz 1901.)b 1902The 1903.b S 1904line starts putting the rules into set one. 1905These rules strip off the 1906.q ing70: 1907from incoming ARPANET mail 1908and the 1909.q CSVAX: 1910off of incoming UUCP mail. 1911.pp 1912The name classes could be used here, 1913but using literal strings is safe 1914because they will always be program-generated. 1915.sh 1 "COMPARISON WITH OTHER MAILERS" 1916.sh 2 "Delivermail" 1917.pp 1918.i Sendmail 1919is an outgrowth of 1920.i delivermail . 1921The primary differences are: 1922.np 1923Configuration information is not compiled in. 1924This simplifies many of the problems 1925of moving to other machines. 1926It also allows easy debugging of new mailers. 1927.np 1928Address parsing is more flexible. 1929For example, 1930.i delivermail 1931only supported one gateway to any network, 1932whereas 1933.i sendmail 1934can be sensitive to host names 1935and reroute to different gateways. 1936.np 1937Forwarding and 1938:include: 1939features eliminate the requirement that the system alias file 1940be writable by any user 1941(or that an update program be written, 1942or that the system administration make all changes). 1943.np 1944.i Sendmail 1945supports message batching across networks 1946when a message is being sent to multiple recipients. 1947.sh 2 "MMDF" 1948.pp 1949MMDF 1950[Crocker79] 1951spans a wider problem set than 1952.i sendmail . 1953For example, 1954the domain of 1955MMDF includes a 1956.q "phone network" 1957mailer, whereas 1958.i sendmail 1959calls on preexisting mailers in most cases. 1960.pp 1961MMDF and 1962.i sendmail 1963both support aliasing, 1964customized mailers, 1965message batching, 1966automatic forwarding to gateways, 1967queueing, 1968and retransmission. 1969MMDF supports two-stage timeout, 1970which 1971.i sendmail 1972does not currently support. 1973.sh 2 "Message Processing Module" 1974.pp 1975The Message Processing Module (MPM) 1976discussed by Postel [Postel79b] 1977matches 1978.i sendmail 1979closely in terms of its basic architecture. 1980However, 1981like MMDF, 1982the MPM includes the network interface software 1983as part of its domain. 1984.pp 1985MPM also postulates a duplex channel to the receiver, 1986as does MMDF. 1987This allows simpler handling of errors 1988by the mailer 1989than possible in 1990.i sendmail ; 1991when a message queued by 1992.i sendmail 1993is sent, 1994any errors must be returned to the sender 1995by the mailer itself. 1996Both MPM and MMDF mailers 1997can return an immediate error response, 1998and a single error processor can create an appropriate response. 1999.pp 2000MPM prefers passing the message as a structured message, 2001with type-length-value tuples. 2002This implies a much higher degree of cooperation 2003between mailers than required by 2004.i sendmail . 2005MPM also assumes a universally agreed upon internet name space 2006(with each address a net-host-user tuple), 2007which 2008.i sendmail 2009does not. 2010.sh 1 "EVALUATIONS AND FUTURE PLANS" 2011.pp 2012.i Sendmail 2013is designed to work in a nonhomogeneous environment. 2014Every attempt is made to avoid imposing any constraints 2015on the underlying mailers. 2016This goal has driven much of the design. 2017One of the major problems 2018has been the lack of a uniform address space, 2019as postulated in [Postel79a] 2020and [Postel79b]. 2021.pp 2022A nonuniform address space implies that path will be specified 2023in all addresses, 2024either explicitly (as part of the address) 2025or implicitly 2026(as with implied forwarding to gateways). 2027This has the unpleasant effect of making replying to messages 2028exceedingly difficult, 2029since there is no one 2030.q address 2031for any person, 2032but only a way to get there from wherever you are. 2033.pp 2034Interfacing to mail programs 2035that were not initially intended to be applied 2036in an internet environment 2037has been amazingly successful, 2038and has reduced the job to a manageable task. 2039.pp 2040.i Sendmail 2041has knowledge of a few difficult environments 2042built in. 2043It generates ARPANET FTP compatible error messages 2044(prepended with three-digit numbers 2045[Neigus73, Postel74]) 2046as necessary, 2047optionally generates UNIX-style 2048.q From 2049lines on the front of messages for some mailers, 2050and knows how to parse the same lines on input. 2051This can be inconvenient to sites which have abandoned UNIX mail, 2052although 2053.i sendmail 2054still adds and understands ARPANET-style 2055.q From: 2056lines. 2057Also, 2058error handling has an option customized for BerkNet. 2059.pp 2060One surprisingly major annoyance in most internet mailers 2061(such as MMDF) 2062is that the location and format of local mail is built in\**. 2063.(f 2064\**For example, 2065MMDF puts local mail in the file 2066.q .mail 2067\*- useful if you are running version 6. 2068.)f 2069.i Sendmail 2070eliminates all knowledge of location 2071and can function successfully with different formats. 2072.pp 2073The ability to automatically generate a response to incoming mail 2074(by forwarding mail to a program) 2075seems useful 2076(\c 2077.q "I am on vacation until late August...." ) 2078but can create problems 2079such as forwarding loops 2080(two people on vacation whose programs send notes back and forth, 2081for instance) 2082if these programs are not well written. 2083A program should be written to do standard tasks correctly, 2084but this does not solve the general case. 2085It might be desirable to implement some form of load limiting. 2086I am unaware of any mail system that addresses this problem, 2087nor am I aware of any reasonable solution at this time. 2088.pp 2089.i Sendmail 2090should be modified to run as a daemon, 2091reading an MPX file 2092(or other IPC scheme) 2093to receive mail and process it. 2094This would reduce the cost of sending mail to writing the message 2095into a known file. 2096.i Sendmail 2097would be modified to have a very different argument structure. 2098It already has an option to read the recipients 2099from the message header. 2100A more palatable technique for giving error messages 2101would also have to be devised. 2102.pp 2103The configuration file is currently practically inscrutable; 2104considerable convenience could be realized 2105with a higher-level format. 2106For example, a description might read: 2107.(b 2108.re 2109(MACRO name value) 2110(HEADER name value 2111 (OPTION option) ... 2112 (NEEDS option) ... ) 2113(MAILER name path xlatstring 2114 (OPTION option) ... 2115 (ARGV arg ... )) 2116(CLASS name word ...) 2117(REWRITE setname 2118 (RULE lhs rhs) ... ) 2119.)b 2120.pp 2121It seems clear that common protocols will be changing soon 2122to accommodate changing requirements and environments. 2123These changes will include modifications to the message header 2124[NBS80] 2125or to the body of the message itself 2126(such as for multimedia messages 2127[Postel80]). 2128Other changes will include changes to communication protocols 2129which may effect 2130.i sendmail ; 2131for example, the changes implied by the new Mail Transfer Protocol 2132[Sluizer81]. 2133These changes should be relatively trivial to integrate 2134into the existing system. 2135.pp 2136Many other nice features could be implemented. 2137For example, 2138if we were sure that the alias file were writable by the effective user 2139(i.e., if 2140.i sendmail 2141were to run setuid) 2142then the inverted form could be rebuilt automatically when the 2143text copy was changed. 2144However, this appears to be little more than frosting. 2145.pp 2146Some proposals call for a single address syntax, 2147such that the host name uniquely determines the network. 2148There are a number of evident problems with this. 2149In a large internet, 2150the database update problem becomes considerable, 2151especially under multiple managements; 2152this can be solved by a daemon that updates the tables 2153dynamically, 2154but it is not clear what the problems are here. 2155More to the point, 2156this requires a unique namespace among all networks. 2157In our current configuration 2158we have been unable to even find out the names of all the hosts 2159on the UUCP network; 2160to hope that on an internet with fifty or more networks 2161would have no name conflicts is beyond the scope of 2162.i sendmail . 2163Despite the difficulties, however, 2164this is probably a better long-term solution to the problem 2165of internet addressing. 2166The ambiguities implied by addresses combining 2167left-associative and right-associative addresses 2168are impossible to solve without parentheses; 2169acceptable for mathematical equations, 2170but absurd for network addresses. 2171.pp 2172A related problem occurs with the user namespace. 2173In tightly coupled environments, 2174it would be nice to have automatic forwarding between machines 2175on the basis of the user name alone, 2176without cumbersome aliases. 2177This would require an automatically updated database 2178and some method of resolving conflicts. 2179Ideally this would be effective even with multiple managements. 2180A student at Berkeley, 2181Alan Biocca, 2182is working on a facility which may provide the necessary functionality. 2183.pp 2184In the long run, 2185a system that understands canonical internet addresses 2186(net, host, user) 2187implemented in a world that understands these addresses 2188would be an incredible win. 2189.i Sendmail 2190seems to be a useful tool to pull together 2191the haphazard environment that exists today, 2192until the better tools permeate the internetwork world. 2193.sh 0 "ACKNOWLEDGEMENTS" 2194.pp 2195Thanks are due to Kurt Shoens for his continual cheerful 2196assistance and good advice, 2197Bill Joy for pointing me in the correct direction 2198(over and over), 2199and Mark Horton for more advice, 2200prodding, 2201and many of the good ideas. 2202Kurt and Eric Schmidt are to be credited 2203for using 2204.i delivermail 2205as a server for their programs 2206(\c 2207.i Mail 2208and BerkNet respectively) 2209before any sane person should have, 2210and making the necessary modifications 2211promptly and happily. 2212Eric gave me considerable advice about the perils 2213of network software which saved me an unknown 2214amount of work and grief. 2215Mark did the original implementation of the DBM version 2216of aliasing, installed the VFORK code, 2217wrote the current version of 2218.i rmail , 2219and was the person who really convinced me 2220to put the work into 2221.i delivermail 2222to turn it into 2223.i sendmail . 2224Kurt deserves accolades for using 2225.i sendmail 2226when I was myself afraid to take the risk; 2227how a person can continue to be so enthusiastic 2228in the face of so much bitter reality is beyond me. 2229.pp 2230Kurt and Kirk McKusick 2231read early copies of this paper, 2232giving considerable useful advice. 2233.pp 2234Special thanks are reserved for Mike Stonebraker, 2235who knowingly allowed me to put so much work into this 2236when there were so many other things I really should 2237have been working on. 2238.+c 2239.ce 2240REFERENCES 2241.nr ii 1.5i 2242.ip [Borden79] 2243Borden, S., 2244Gaines, R. S., 2245and 2246Shapiro, N. Z., 2247.ul 2248The MH Message Handling System: Users' Manual. 2249R-2367-PAF. 2250Rand Corporation. 2251October 1979. 2252.ip [Crocker77a] 2253Crocker, D. H., 2254Vittal, J. J., 2255Pogran, K. T., 2256and 2257Henderson, D. A. Jr., 2258.ul 2259Standard for the Format of ARPA Network Text Messages. 2260RFC 733, 2261NIC 41952. 2262In [Feinler78]. 2263November 1977. 2264.ip [Crocker77b] 2265Crocker, D. H., 2266.ul 2267Framework and Functions of the MS Personal Message System. 2268R-2134-ARPA, 2269Rand Corporation, 2270Santa Monica, California. 22711977. 2272.ip [Crocker79] 2273Crocker, D. H., 2274Szurkowski, E. S., 2275and 2276Farber, D. J., 2277.ul 2278An Internetwork Memo Distribution Facility \*- MMDF. 22796th Data Communication Symposium, 2280Asilomar. 2281November 1979. 2282.ip [Metcalfe76] 2283Metcalfe, R., 2284and 2285Boggs, D., 2286.q "Ethernet: Distributed Packet Switching for Local Computer Networks" , 2287.ul 2288Communications of the ACM 19, 22897. 2290July 1976. 2291.ip [Feinler78] 2292Feinler, E., 2293and 2294Postel, J. 2295(eds.), 2296.ul 2297ARPANET Protocol Handbook. 2298NIC 7104, 2299Network Information Center, 2300SRI International, 2301Menlo Park, California. 23021978. 2303.ip [NBS80] 2304National Bureau of Standards, 2305.ul 2306Specification of a Draft Message Format Standard. 2307Report No. ICST/CBOS 80-2. 2308October 1980. 2309.ip [Neigus73] 2310Neigus, N., 2311.ul 2312File Transfer Protocol for the ARPA Network. 2313RFC 542, NIC 17759. 2314In [Feinler78]. 2315August, 1973. 2316.ip [Nowitz78a] 2317Nowitz, D. A., 2318and 2319Lesk, M. E., 2320.ul 2321A Dial-Up Network of UNIX Systems. 2322Bell Laboratories. 2323In 2324UNIX Programmer's Manual, Seventh Edition, 2325Volume 2. 2326August, 1978. 2327.ip [Nowitz78b] 2328Nowitz, D. A., 2329.ul 2330Uucp Implementation Description. 2331Bell Laboratories. 2332In 2333UNIX Programmer's Manual, Seventh Edition, 2334Volume 2. 2335October, 1978. 2336.ip [Postel74] 2337Postel, J., 2338and 2339Neigus, N., 2340Revised FTP Reply Codes. 2341RFC 640, NIC 30843. 2342In [Feinler78]. 2343June, 1974. 2344.ip [Postel77] 2345Postel, J., 2346.ul 2347Mail Protocol. 2348NIC 29588. 2349In [Feinler78]. 2350November 1977. 2351.ip [Postel79a] 2352Postel, J., 2353.ul 2354Internet Message Protocol. 2355RFC 753, 2356IEN 85. 2357Network Information Center, 2358SRI International, 2359Menlo Park, California. 2360March 1979. 2361.ip [Postel79b] 2362Postel, J. B., 2363.ul 2364An Internetwork Message Structure. 2365In 2366.ul 2367Proceedings of the Sixth Data Communications Symposium, 2368IEEE. 2369New York. 2370November 1979. 2371.ip [Postel80] 2372Postel, J. B., 2373.ul 2374A Structured Format for Transmission of Multi-Media Documents. 2375RFC 767. 2376Network Information Center, 2377SRI International, 2378Menlo Park, California. 2379August 1980. 2380.ip [Postel81] 2381Postel, J. B., 2382.ul 2383Simple Mail Transfer Protocol. 2384RFC788. 2385Network Information Center, 2386SRI International, 2387Menlo Park, California. 2388November 1981. 2389.ip [Schmidt79] 2390Schmidt, E., 2391.ul 2392An Introduction to the Berkeley Network. 2393University of California, Berkeley California. 23941979. 2395.ip [Shoens79] 2396Shoens, K., 2397.ul 2398Mail Reference Manual. 2399University of California, Berkeley. 2400In UNIX Programmer's Manual, 2401Seventh Edition, 2402Volume 2C. 2403December 1979. 2404.ip [Sluizer81] 2405Sluizer, S., 2406and 2407Postel, J. B., 2408.ul 2409Mail Transfer Protocol. 2410RFC 780. 2411Network Information Center, 2412SRI International, 2413Menlo Park, California. 2414May 1981. 2415.ip [UNIX80] 2416.ul 2417The UNIX Programmer's Manual, Seventh Edition, 2418Virtual VAX-11 Version, 2419Volume 1. 2420Bell Laboratories, 2421modified by the University of California, 2422Berkeley California. 2423November 1980. 2424.++ A 2425.+c "SENDMAIL USAGE" 2426.pp 2427Arguments must be presented with flags before addresses. 2428The flags are: 2429.nr ii 1i 2430.ip "\-f addr" 2431The sender's machine address is 2432.i addr . 2433This flag is ignored unless the real user 2434is root, 2435network, 2436or uucp, 2437or if 2438.i addr 2439contains an exclamation point 2440(because of certain restrictions in UUCP). 2441.ip "\-r addr" 2442An obsolete form of 2443.b \-f . 2444.ip "\-h cnt" 2445Sets the 2446.q "hop count" 2447to 2448.i cnt . 2449This represents the number of times this message has been processed 2450by 2451.i sendmail 2452(to the extent that it is supported by the underlying networks). 2453.i Cnt 2454is incremented during processing, 2455and if it reaches 2456MAXHOP 2457(currently 30) 2458.i sendmail 2459throws away the message with an error. 2460.ip "\-F\&name" 2461Sets the full name of this user to 2462.i name . 2463.ip \-e\&p 2464Print error messages (default). 2465.ip \-e\&q 2466Throw away error messages. 2467The only response is the exit status. 2468.ip \-e\&m 2469Mail back errors. 2470.ip \-e\&w 2471.q Write 2472back errors \*- or mail them if the user is not logged in. 2473.ip \-e\&e 2474Do special error processing for BerkNet. 2475This involves mailing back the errors 2476but always returning a zero exit status. 2477.ip \-n 2478Don't do aliasing or forwarding. 2479.ip \-m 2480Include me in alias expansions. 2481Normally 2482.i sendmail 2483suppresses the sender 2484if in a group being sent to. 2485.ip \-o 2486Assume that the headers are already in new format, 2487i.e., 2488there are commas between names and spaces are to be preserved. 2489If this flag is not given, 2490an adaptive algorithm is used: 2491if any recipient address contains a comma, parenthesis, 2492or angle bracket, 2493it will be assumed that commas already exist. 2494This flag is required in certain rare cases. 2495Headers are always output with commas between the names. 2496.ip \-i 2497Don't take a dot to end a message. 2498.ip \-t 2499Read the header for 2500.q To: , 2501.q Cc: , 2502and 2503.q Bcc: 2504lines, and send to everyone listed in those lists. 2505The 2506.q Bcc: 2507line will be deleted before sending. 2508Any addresses in the argument vector will be deleted 2509from the send list. 2510.ip \-a 2511Do special processing for the 2512ARPANET. 2513This includes reading the 2514.q "From:" 2515line from the header to find the sender, 2516printing 2517ARPANET 2518style messages 2519(preceded by three digit reply codes for compatibility with 2520the FTP protocol 2521[Neigus73, Postel74, Postel77]), 2522and ending lines of error messages with <CRLF>. 2523.ip \-a\&s 2524Take input over an SMTP connection on standard input and output. 2525This does everything the \-a flag does also. 2526.ip \-s 2527Save UNIX-style 2528.q From 2529lines at the beginning of headers. 2530Normally they are assumed redundant 2531and discarded. 2532.ip \-v 2533Give a blow-by-blow description of function. 2534This gives information of interest to the user 2535rather than for the 2536.i sendmail 2537maintainer; 2538for example, 2539aliases are printed as expanded 2540and mailer functions are printed as they run. 2541.ip \-c 2542If this mailer is marked as being expensive, 2543don't connect immediately. 2544This requires that queueing be compiled in, 2545since it will depend on a sender process to 2546actually send the mail. 2547.ip \-q\&time 2548Try to execute the queued up mail. 2549If the time is given, 2550a sendmail will run through the queue at the specified interval 2551to deliver queued mail; 2552otherwise, it only runs once. 2553.ip \-p 2554Verify as much about the addresses and message as possible 2555and then politely run in background. 2556.ip \-D 2557Run as a daemon. 2558This should always be used with the 2559.b \-as 2560flag, 2561as it runs on the SMTP port. 2562.ip \-T\&time 2563Set timeout interval for mail that cannot be sent. 2564.ip \-Q\&dir 2565Select directory in which mail will be queued. 2566Typically for debugging only. 2567.ip \-C\&file 2568Use a different configuration file. 2569.ip \-A\&file 2570Use a different alias file. 2571.ip \-I 2572Initialize the DBM version 2573of the alias file. 2574If 2575.b \-I 2576is given, 2577no delivery is attempted. 2578The DBM version will be rebuilt automatically if the DBM files 2579are mode 666, 2580or if they are owned by the effective userid. 2581.ip \-V 2582Verify the addresses only. 2583Only partial verification is done: 2584syntax is checked, and local names are verified, 2585but no checking normally done by the mailer is attempted. 2586.ip \-d\&level 2587Set debugging level. 2588.ip \-M\&x\&val 2589Define macro 2590.i x 2591to have value 2592.i val . 2593.nr ii 5n 2594.+c "OTHER CONFIGURATION" 2595.pp 2596There are some configuration changes that can be made by 2597recompiling 2598.i sendmail . 2599Some of these are changes to compilation flags: 2600.nr ii 1i 2601.ip V6 2602If set, 2603this will compile a version 6 system, 2604with 8-bit user id's, 2605single character tty id's, 2606etc. 2607If not set, 2608a version 7 system is assumed. 2609.ip DBM 2610If set, 2611the 2612.q DBM 2613package in UNIX is used 2614(see DBM(3X) in [UNIX80]). 2615If not set, 2616a much less efficient algorithm for processing aliases is used. 2617.ip VFORK 2618Set if your system has the experimental 2619.i vfork 2620system call. 2621See vfork(2) in [UNIX80]. 2622If not set, 2623the regular 2624.i fork 2625system call is used. 2626This option improves performance. 2627.ip DEBUG 2628If set, debugging information is compiled in. 2629To actually get the debugging output, 2630the 2631.b \-d 2632flag must be used. 2633.ip LOG 2634If set, 2635the 2636.i syslog 2637routine in use at some sites is used. 2638This makes an informational log record 2639for each message processed, 2640and makes a higher priority log record 2641for internal system errors. 2642.ip QUEUE 2643This flag should be set to compile in the queueing code. 2644If this is not set, 2645mailers must accept the mail immediately 2646or it will be returned to the sender. 2647.ip SMTP 2648If set, 2649the code to handle user and server SMTP will be compiled in. 2650This is only necessary if your machine has some mailer 2651that speaks SMTP. 2652.ip UGLYUUCP 2653If you have a UUCP host adjacent to you which is not running 2654a reasonable version of 2655.i rmail , 2656you will have to set this flag to include the 2657.q "remote from sysname" 2658info on the from line. 2659Otherwise, UUCP gets confused about where the mail came from. 2660.ip PARANOID 2661There are places where 2662.i sendmail 2663may opt for a more secure, 2664but probably less convenient environment. 2665For example, 2666if this flag is set 2667it is not possible to specify a program as an address directly; 2668this can only be done with an alias. 2669.ip NOTUNIX 2670If you are using a non-UNIX mail format, 2671you can set this flag to turn off special processing 2672of UNIX-style 2673.q "From " 2674lines. 2675.nr ii 5n 2676.pp 2677Not all header semantics are defined in the configuration file. 2678Header lines that should only be included by certain mailers 2679(as well as other more obscure semantics) 2680must be specified in the 2681.i HdrInfo 2682table in 2683.i conf.c . 2684This table contains the header name 2685(which should be in all lower case), 2686a set of header control flags (described below), 2687and a set of mailer flags, 2688used by some of the header flags. 2689The header flags are: 2690.nr ii \w'H_ACHECK 'u 2691.ip H_CHECK 2692Check the flags for the receiving mailer 2693against the third field in the 2694.i HdrInfo 2695entry. 2696If the mailer has any of those bits set, 2697send this field; 2698otherwise, do not send this field to that mailer. 2699If the field was in the message originally, however, 2700it will always be sent 2701(i.e., this only applies to headers being added by 2702.i sendmail ). 2703.ip H_ACHECK 2704Same as H_CHECK, 2705except that it even applies to headers that were in the 2706original message. 2707That is, 2708if this bit is set and the mailer does not have flag bits set 2709that intersect with the third field in this 2710.i HdrInfo 2711entry, 2712the header line is 2713.i always 2714deleted. 2715.ip H_EOH 2716If this header field is set, 2717treat it like a blank line, 2718i.e., 2719it will signal the end of the header 2720and the beginning of the message text. 2721.ip H_FORCE 2722Add this header entry 2723even if one existed in the message before. 2724If a header entry does not have this bit set, 2725.i sendmail 2726will not add another header line if a header line 2727of this name already existed. 2728This would normally be used to stamp the message 2729by everyone who handled it. 2730.ip H_RCPT 2731If set, 2732this field contains recipient addresses. 2733This is used by the 2734.b \-t 2735flag to determine who to send to 2736when it is collecting recipients from the message. 2737.ip H_ADDR 2738This flag indicates that this field 2739contains addresses that should be rewritten 2740to include commas, etc. 2741.nr ii 5n 2742.lp 2743Let's look at a sample 2744.i HdrInfo 2745specification: 2746.(b 2747.sz -2 2748.ta 4n +\w'"received-from", 'u +\w'H_ADDR|H_ACHECK, 'u 2749struct hdrinfo HdrInfo[] = 2750{ 2751 "date", H_CHECK, M_NEEDDATE, 2752 "from", H_CHECK, M_NEEDFROM, 2753 "original-from", H_ACHECK, 0, 2754 "sender", 0, 0, 2755 "full-name", H_ACHECK, M_FULLNAME, 2756 "to", H_ADDR, 0, 2757 "cc", H_ADDR, 0, 2758 "bcc", H_ADDR|H_ACHECK, 0, 2759 "message-id", H_CHECK, M_MSGID, 2760 "message", H_EOH, 0, 2761 "text", H_EOH, 0, 2762 "received-date", H_CHECK, M_LOCAL, 2763 "received-from", H_CHECK, M_LOCAL, 2764 "via", H_FORCE, 0, 2765 NULL, 0, 0, 2766}; 2767.sz 2768.)b 2769This specification says that the 2770.q Date: , 2771.q From: , 2772.q Message-Id: , 2773.q Received-Date: , 2774and 2775.q Received-From: 2776must be requested by the mailer to be inserted. 2777However, 2778if they were in the message as received by 2779.i sendmail 2780they will be propagated. 2781The 2782.q Full-Name: 2783field, on the other hand, 2784will be deleted even if it was specified before, 2785unless the mailer wants it. 2786The 2787.q Original-From: 2788and 2789.q Bcc: 2790fields will be deleted unconditionally 2791(since it is never possible for a mailer's flags 2792to intersect with zero). 2793The 2794.q Original-From: 2795is in fact used internally, 2796and will be reinserted by ad hoc code, 2797but only if it differs from the 2798.q From: 2799line that would otherwise be inserted. 2800.q To: , 2801.q Cc: , 2802and 2803.q Bcc: 2804all specify recipient addresses. 2805The 2806.q Message: 2807and 2808.q Text: 2809fields will terminate the header; 2810these are specified in new protocols 2811[NBS80] 2812or used by random dissenters around the network world. 2813The 2814.q Via: 2815field will always be added, 2816and can be used to trace messages. 2817The 2818.q Sender: 2819field is used internally, 2820although no cliched special processing occurs. 2821.pp 2822There are a number of important points here. 2823First, 2824header fields are not added automatically just because they are in the 2825.i HdrInfo 2826structure; 2827they must be specified in the configuration file 2828in order to be added to the message. 2829Any header fields mentioned in the configuration file but not 2830mentioned in the 2831.i HdrInfo 2832structure have default processing performed; 2833that is, 2834they are added unless they were in the message already. 2835Second, 2836the 2837.i HdrInfo 2838structure only specifies cliched processing; 2839certain headers are processed specially by ad hoc code 2840regardless of the status specified in 2841.i HdrInfo . 2842For example, 2843the 2844.q Sender: 2845and 2846.q From: 2847fields are always scanned on ARPANET mail 2848to determine the sender; 2849this is used to perform the 2850.q "return to sender" 2851function. 2852The 2853.q "From:" 2854and 2855.q "Full-Name:" 2856fields are used to determine the full name of the sender 2857if possible; 2858this is stored in the macro 2859.b $x 2860and used in a number of ways. 2861Although the 2862.q "Original-From:" 2863field is specified to be deleted in 2864.i HdrInfo , 2865it is added automatically if the 2866.q From: 2867field that would be generated internally 2868differs from the 2869.q From: 2870field that was specified in the message; 2871in this case, 2872the original 2873.q From: 2874field is renamed 2875.q Original-From: . 2876.pp 2877The file 2878.i conf.c 2879also contains the specification of ARPANET reply codes. 2880There are six classifications these fall into: 2881.(b 2882.sz -2 2883.ta \w'char 'u +\w'Arpa_Usrerr[] = 'u +\w'"888"; 'u 2884char Arpa_Info[] = "050"; /* arbitrary info */ 2885char Arpa_Enter[] = "350"; /* start mail input */ 2886char Arpa_Mmsg[] = "256"; /* mail successful (MAIL cmd) */ 2887char Arpa_Fmsg[] = "250"; /* mail successful (MLFL cmd) */ 2888char Arpa_Syserr[] = "455"; /* some (transient) system error */ 2889char Arpa_Usrerr[] = "450"; /* some (fatal) user error */ 2890.sz 2891.)b 2892The class 2893.i Arpa_Info 2894is for any information that is not required by the protocol, 2895such as forwarding information. 2896.i Arpa_Enter 2897is output when 2898.i sendmail 2899wants to start receiving the mail. 2900.i Arpa_Mmsg 2901and 2902.i Arpa_Fmsg 2903are given if the mail is successfully delivered; 2904the selection of message number depends on the FTP command given 2905(which is communicated via the 2906.b \-a 2907flag). 2908.i Arpa_Syserr 2909is printed by the 2910.i syserr 2911routine; 2912typically, this occurs when something has gone wrong at the 2913receiving site, 2914with the assumption that it is a transient condition. 2915Finally, 2916.i Arpa_Usrerr 2917is the result of a user error 2918and is generated by the 2919.i usrerr 2920routine; 2921these are generated when the user has specified something wrong, 2922and hence the error is permanent, 2923i.e., 2924it will not work simply by resubmitting the request. 2925.pp 2926If it is necessary to restrict mail through a gateway, 2927the 2928.i checkcompat 2929routine can be modified. 2930This routine is called for every recipient address. 2931It can return 2932.b TRUE 2933to indicate that the address is acceptable 2934and mail processing will continue, 2935or it can return 2936.b FALSE 2937to reject the recipient. 2938If it returns false, 2939it is up to 2940.i checkcompat 2941to print an error message 2942(using 2943.i usrerr ) 2944saying why the message is rejected. 2945For example, 2946.i checkcompat 2947could read: 2948.(b 2949.re 2950.sz -2 2951bool 2952checkcompat(to) 2953 register ADDRESS *to; 2954{ 2955 if (MsgSize > 50000 && to->q_mailer != MN_LOCAL) 2956 { 2957 usrerr("Message too large for non-local delivery"); 2958 return (FALSE); 2959 } 2960 return (TRUE); 2961} 2962.sz 2963.)b 2964This would reject messages greater than 50000 bytes 2965unless they were local. 2966The actual use of this routine is highly dependent on the 2967implementation, 2968and use should be limited. 2969