⟦e8505c8ce⟧

TextFile

Version 1.4.1
	Changes from the 1.4.2 version of Sendmail.mc.

 This lists the most significant changes.  A log of recent changes is
 maintained on mp.cs.niu.edu:/pub/cf

 The documentation in Sendmail.mc has been updated to reflect the
 important changes.

 NEWALIASES:- The way non-local aliases is handled has been changed.  See
	Sendmail.mc for description.  The NEWALIASES keyword is no longer
	valid.  The current rules assume version 5.65, or 5.64 later than
	mid July 1990, of the binary.  If you have an earlier version the
	comments at the beginning of ruleset 0 in Sendmail.mc will indicate
	the needed change.

	The new approach for non-local aliases is different from that of
	version 1.4.2.  If you use non-local aliasing, be sure to check
	this.

MAILERTABLE:- Extended to support the use of %s in generating the
	intended destination host.  In the host portion of mailer,host
	there may be a %s provided that the search key begins with a
	'.' - the effect is that when a match occurs, the component of
	the actual domain name which precedes the '.' in the key will
	replace the %s.

MAILSERVER:- Greatly improved from the (somewhat buggy) 1.4.2 version.  Be
	sure to check the documentation if you use this feature.

HIDDENNET and GENERICFROM:- Changed to eliminate the mutual interference
	between these options.

POSTMASTERBOUNCE:- Now optionally takes an address.

New Keywords: TIMEOUT, MAILNAME, ALWAYSADDDOMAIN - See Sendmail.mc for
	details.

=============
Version 1.4.1

	Changes from the 1.3.5 version of Sendmail.mc.

1.	Changes to support the C mailer flag.  Previously valid addresses
	always had an '@' in them after leaving ruleset 3.  This is no
	longer true.  The final qualification of domains is instead moved
	to rulesets 0, 1, 5, 6.  Thus an address without a domain leaves
	ruleset 3 without domain, and the C-flag now functions.

	As part of the change, every address recognized as unparseable
	in ruleset 3 has <@> appended to it.  This is so the C-flag on
	the mailer will not cause such addresses to gratuitiously have
	an '@domain' appended to them.  The '<@>' is eventually removed
	again either in ruleset 4 for final printing, or in ruleset 0
	just before an ERROR mailer is invoked.

	Note that this also effects group addresses 'mailing list:;'.
	Previously they were likely to have an '@domain' added in ruleset
	so they passed through ruleset 3 a second time to have it stripped
	off.

2.	Change deleted.

3.	Processing is added to handle mail from sites which do not properly
	qualify their addresses.  If mail leaves domain 'foo.bar.com' with
	an address 'user@foo', the address is rewritten as
	'user%foo@foo.bar.com'.  This currently applies only to SMTP mail,
	although similar treatment of UUCP mail will be considered later.
	This rewriting does not apply to envelope recipients, since otherwise
	mailing loops could be generated.  It will not prevent the SYSLOG
	message about unparseable sender addresses, since the sender address
	is first processed as if an envelope recipient to determine the
	sending mailer, and this message is generated at that time.

 4.     The IDACOMPATIBLE option is removed.  This was there to ease
	migration from 1.2.x to 1.3.x.  The migration period is presumed
	to be over.

 5.	The NIS_MAILALIASES is redone (in ruleset 26).  This should remove
	some of the problems.

	Note that as one side effect.  In order to permit local alias
	database rebuilding, some uses of ruleset 0 will not do the
	NIS alias database lookup.  This will be noticed mostly in
	test mode, and in processing the EXPN command from an incoming
	SMTP connection when running as daemon.  You can test the NIS
	processing in test mode if you invoke it with
	sendmail -bt -oMfnobody

 6.	As part of (5) above, there is some change to local mail.  For example
	on my host, both 'mp.cs.niu.edu' and 'cs.niu.edu' are considered local.
	It was previously possible to have different 'aliases' database entries
	so that <person@cs.niu.edu> could be delivered to a different person
	than <person@mp.cs.niu.edu>.  This option, which was probably never
	used, is now removed.  However if it is needed there is an alternate
	way of achieving the same functionality.  I could remove
	'cs.niu.edu' from my definition of PSEUDONYMS, and instead place it
	in ALTERNATENAMES.  Then I would add a MAILERTABLE entry:
	LOCAL!cs.niu.edu	cs.niu.edu
	This would allow the same alternate aliasing to be used if needed.

 7.	Except for the UUCP mailers, the address format
		uunode!user@f.q.d.n
	is now preferred over f.q.d.n!uunode!user.
	Previously the rules attempted to make only minimal format changes
	to addresses, preferring to keep them close to their original format
	where possible.  But some TCP/SMTP hosts will refuse to accept any
	address without an @f.q.d.n, while mail originating at some sources
	(particularly on UUCP nodes) has no way of allowing the user to
	specify the formatting.

	This change only effects ruleset 10, so alters envelope recipient
	addresses for TCP mailers, and header addresses for the local mailer.
	Other mailers are not effected.

 8.	The processing of the envelope sender is changed.  RFC1123 asks
	that superfluous routing be avoided.  Consistent with this in
	some circumstances the routing present in the envelope sender of
	arriving mail may be trimmed.  The trimming does not extend to
	any part of the address delimited by a %-arpa-hack, and is only
	done if it can be verified that the resulting address has a
	valid Internet domain name.

	As an example of the benefits, consider the geology department
	at NIU.  They are not currently connected to the Internet, so
	are serviced by MX forwarding via UUCP.  Their MX address is
	'geol.niu.edu'.  With the 'smartuucp' mailer on their Sun system,
	their mail arrives here with an envelope sender address of
	'earth!geol.niu.edu!user'.  The standard processing would change
	this to 'earth!geol.niu.edu!user@mp.cs.niu.edu' before sending it
	out to an Internet site.  While valid, this address is very
	clumsy and confuses some recipient mailers.  With the modifications,
	the address is now transformed into 'user@geol.niu.edu'.

 9.	A new option MAILSERVER is defined.  In your m4 sources, define
	MAILSERVER to be the fully qualified name of the host which
	should do final delivery of your mail.

	This option is useful if the /usr/spool/mail directory is mounted
	from the server, and you prefer to forward the mail to the server
	with the TCP mailer, rather than using RSH_SERVER as the local
	mailer.

	The option is implemented in such a way that if there is an
	entry for the user in the local aliases file, the LOCAL mailer
	is still selected.  This permits local alias expansions.  However
	when processing the alias value, that is reprocessed by sendmail, so
	may still be forwarded to MAILSERVER.

10.	NOTE.  In order to facilitate some of the above features, you may
	now need to invoke test mode with: sendmail -bt -oMfnobody
	to test some rewrite rules.  Without the -oMf option, the LOCAL
	mailer will be selected for local users, and the NIS aliases
	map will not be consulted during test mode.

	The way of coding the rules was needed to allow proper rebuilding
	of the alias database, and to allow correct evaluation of the
	$x macro for local senders, when the MAILSERVER or NIS_MAILALIASES
	options are used.

 11.	Alias file generation is now changed.  While the old method,
	defining NEWALIASES, is available, it is no longer required.
	Instead, for the non-local alias of- user@some.domain: alias-list
	use - user%some.domain@new.aliases.uucp: alias-list
	This requires that you define the entry
	LOCAL!localhost		new.aliases.uucp
	in your MAILERTABLE.  See the documentation in Sendmail.mc and
	in xalparse.sh.  The latter, xalparse.sh, is a front end to
	xalparse, which generates the correct format aliases file from
	the old format xaliases.
=============
Version 1.3.5

	List of changes to the original IDA Sendmail configuration.

1.	The internal (i.e. canonical) representation is completely changed.
	(Yes, that means you must repeat the learning curve all over - sorry
	about that).

	With the change the replacement rules look superficially more like
	the Berkeley versions than like the original IDA versions.  DON'T
	be deceived.  The resemblance is purely superficial.  There is much
	more in common with the IDA configurations than with the Berkeley
	configurations.

	A major difference is that input addresses are now COMPLETELY resolved
	into internal format, EVEN %-paths.

2.	The TCP and LOCAL mailers (but not the TCP-A or TCP-U mailers) now
	attempt to format output addresses in a format similar to the input
	address format.  An input bang path is likely to result in an output
	bang path.  As a consequence the TCP-U mailer will probably need to
	be used much less often.  The idea is that the form in which an address
	is received is often a useful guide to the correct format of the
	output address.

	This effect can be disabled, and the original IDA philosophy of all
	%-path addresses used, by specifying the keyword IDACOMPATIBLE in
	the m4 source file.

3.	The mailer table functionality has been extended.  In the old format
	the mailer table translated a domain into a mailer:host pair.  We
	have made several extensions.
	  Firstly, the mailertable can be used to select a mailer:host pair
	based on a subdomain, essentially similar to the way a wild card MX
	record in the domain database can represent a subdomain.  This is
	somewhat similar to the code in the pathtable for dealing with
	subdomains.
	  Secondly a null mailer:host may be selected.  This is interpreted
	as meaning that no mailer should be selected.  It can be used to
	force a pathalias lookup for a domain which you could mail to over
	TCP.  (Perhaps the network is having trouble, so you wish to
	temporarily divert mail via a UUCP link).
	  Thirdly, the way a mailer:host is represented has been generalized
	to allow some choice in the manner of formatting addresses.  A domain
	may now be translated to any of - 'mailer:host' -or- 'mailer,host' -or-
	'mailer!host'.  The effect is this.  Suppose the original mail was to
	say '@host1:user@host2'.  With an entry 'mailer:host' the original
	meaning prevails, whereby the mail is sent to 'host' after being
	relativized so that the recipient envelope address is 'user@host2'.
	With a table entry of 'mailer,host' the mail is forwarded to 'host'
	but is not relativized; it is sent with an envelope address still of
	'@host1:user@host2' (rewritten appropriately for the mailer).  The
	third format 'mailer!host' is particularly useful for UUCP mailers.
	It completely relativizes the addresses, even down to the user level.
	Thus '@host1:user@host2' is relativized to 'user@host2', and
	'user@host1' is relativized to just 'user'.

4.	The problem of erroneous domain qualification has been partially
	solved.  Now no attempt is made to fully qualify a domain unless
	that domain is the immediate host.  Thus addresses relative to a
	receiving domain are not qualified.  The extraneous .UUCP
	qualification problem is partially solved.  Previously any
	unqualified domain which could not be otherwise qualified had a
	.UUCP added.  Unfortunately this is not always correct, since
	mail from BITNET hosts sometimes fails to qualify the BITNET
	nodes in the address.  (And sometime unqualified addresses come
	over TCP from hosts that are improperly configured, and "don't
	know their own names").  In this version 'host' is qualified to
	'host.UUCP' only if the mailer is able to send mail to an address
	of the form 'user@host.UUCP'.  While this does not completely
	eliminate the problem (a BITNET node may happen to have the same
	name as a distinct UUCP node, for example), it does greatly
	reduce the problem.
	The extraneous .UUCP qualification can be completely eliminated,
	but at a cost, by defining BANGONLYUUCP.  In this case a domain
	is only qualified with .UUCP if it is delimited by a '!'.  But
	then mail to user@uuhost (as distinct from mail addressed to
	uuhost!user) will not be resolved unless there is a suitable entry
	for uuhost in mailertable, or domaintable.

5.	A number of minor bugs have been cleared up.  For example there
	was a tendency, if BANGIMPLIESUUCP was in effect, for an address
	host2!user@host1 to be qualified as @host1.UUCP:user@host2 .  That
	is, there was a tendency to apply the .UUCP qualification even to
	domains that were not delimited by a bang.

6.	The TCP-A mailer, which is supposed to make all addresses have
	a real Internet route, is changed.  Now only sender addresses are
	forced to always have a real domain address.  Our local host address
	is added if needed.  For recipient addresses, our local address is
	added only for directly connected nodes we are aware of, such as
	our UUCP links.  (It is presumed that the TCP-A mailer will not
	be used to mail to our UUCP neighbors, so that these are only
	header addresses, not envelope addresses).  The purpose of the change
	is to avoid the problem caused by adding our own name as a route on
	the envelope recipient address, possibly causing the mail to be
	sent right back to us in a mail loop.  Our assumption is that a
	header address which is not a real domain, and which is not a
	directly connected neighbor, may possible be better known to the
	receiving host than to us, so we should not add ourselves as a route.

7.	The domaintable lookup is extended so as to allow UUCP domains and
	other pseudo-domains to be qualified.  If the domain has a fully
	qualified domain address which is preferred, the address may thus
	be converted to that fully converted form.  Simply include a
	translation for domain.UUCP in the domaintable.

	Fully qualified domains are also permitted in domaintable.  It is
	intended that they should translate to themselves, although perhaps
	with a preferred capitalization.  A fully qualified domain may actually
	represent only an MX address.  If we are the primary mail forwarder,
	our $[ ... $] nameserver lookup will fail to qualify this address.  If
	there is an entry for the address in domaintable we will consider the
	address (in its translated form) to be fully qualified, so that the
	TCP-A mailer need not provide a route to this address.

8.	The handling of numeric internet addresses such as [1.2.3.4] is now
	changed.  Previously there was an attempt to resolve the name with
	a $[ .. $] lookup.  If that succeeded, mail was sent to the hostname
	indicated.  Only if the resolver lookup failed was mail sent direct
	to the numeric address.

	Strictly speaking, the old logic was wrong.  In theory, numeric
	internet addresses are supposed to be used without interpretation.
	Imagine for example, that foo.bar.edu has address 1.2.3.4.  Under
	the previous approach, mail to 'user@[1,2,3,4]' causes a resolver
	lookup, and is translated to 'user@foo.bar.edu'.  But there may
	be an MX record directing 'foo.bar.edu' mail to 'bar.foo.edu', so
	that the mail to 'user@[1.2.3.4]' finishes up being sent to
	'bar.foo.edu' which can hardly be described as using the address
	without interpretation.

	Here the mail is sent directly to the specified internet address.
	However the address is stripped off the envelope recipient, on the
	assumption that most mailers do not recognize there own address.
	This occasionally turns out to be useful.  A newly installed
	machine may not yet be properly configured for networking, so it
	fails to recognize its own address.  It may be unable to deliver
	mail addressed to 'user@foo.bar.edu' because it does not know that
	'foo.bar.edu' requires local delivery.  By mailing to 'user@[1.2.3.4]'
	we bypass the problem, as the mailer only sees the need to deliver
	mail to 'user'.  (This is obviously not a desirably way of delivering
	mail, but is a useful trick to establish a quick and dirty communication
	link until the configuration problems have been resolved.

	On the other hand, if mail is sent to us by internet address, with
	envelope recipient 'user@[1.1.1.1]' (or whatever the correct address
	is), this is correctly recognized as a local address, so local
	delivery is made.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦e8505c8ce⟧ TextFile

Derivation

TextFile
