tom@taux01.UUCP (Tom Gorodecki) (09/21/87)
Hello world ! sendmail (smtp) wizards ,please help. Look at the following script : Why does the Sender address is copied into the Recipient address? Script started on Mon Sep 21 15:59:14 1987 taux02-2# /usr/lib/sendmail -v -ftom@tavm01 tom@taux01 < /etc/printcap tom@taux01... Connecting to taux01.ether... 220 taux01.taux01.UUCP Sendmail 5.51/IL-1.2 ready at Mon, 21 Sep 87 15:59:45 +0200 >>> HELO taux02.taux01 250 taux01.UUCP Hello taux02.taux01, pleased to meet you >>> VERB 200 Verbose mode >>> ONEX 200 Only one transaction >>> MAIL From:<tom@tavm01> 250 <tom@tavm01>... Sender ok >>> RCPT To:<tom@tavm01> <---------- WHY ? 250 <tom@tavm01>... Recipient ok >>> DATA ok 354 Enter mail, end with "." on a line by itself >>> . 050 <tom@tavm01>... Connecting to .toibm... 050 <tom@tavm01>... Sent 250 Ok >>> QUIT 221 taux01.UUCP closing connection tom@taux01... Sent taux02-2# script done on Mon Sep 21 16:00:06 1987 -- Gorodecki Tom. National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia B, 46 104, Israel UUCP: {hplabs,pyramid,sun,decwrl}!nsc!taux01!tom domain: tom%taux01@nsc.com
randy@ncifcrf.UUCP (The Computer Grue) (09/22/87)
In article <339@taux01.UUCP> tom%taux01@nsc.com (Tom Gorodecki) writes: > > Look at the following script : > Why does the Sender address is copied into the Recipient > address? > > Script started on Mon Sep 21 15:59:14 1987 > taux02-2# /usr/lib/sendmail -v -ftom@tavm01 tom@taux01 < /etc/printcap [Non-essential (I hope :-}) part deleted] > >>> MAIL From:<tom@tavm01> > 250 <tom@tavm01>... Sender ok > >>> RCPT To:<tom@tavm01> <---------- WHY ? > 250 <tom@tavm01>... Recipient ok > >>> DATA [Same comment] I believe what is happening is the following: In your sendmail.cf file, the address 'tom@taux01' is getting rewritten to '$#tcp $@taux01 $:tom' (ie. Mailer: tcp, host: taux01, User: tom). Now the tcp/ip mailer is setup by default (via the C flag in the spec in the sendmail.cf file) to append the hostname of the *sender* to the username if the username does not include a host name (I will admit (*blush*) as to not being completely sure why this is done, but I'm assuming there's a good reason and I've left it in in my sendmail.cf file). You can check to see if I'm right by sending mail to some user other than 'tom' at host taux01. The mail should end up being sent to 'user@tavm01' in the above config. The fix I'd suggest (If I've got the right break) is to explicitly force the tcp mailer selection rewrite rule in ruleset 0 to specify both $@host and $:user@host (same host). This is the solution I use here for a similar problem. I'm not sure it's possible to diagnose this problem further without seeing you sendmail.cf file, but that's my best guess (it'd also help to know what computer you are running on, so as to possibly be able to refer you to manual pages). You might also want to try throwing a copy of sendmail into address test mode (/usr/lib/sendmail -bt) and playing around with testing out addresses through ruleset 0. Check out your local copy of the sendmail Installation and Operation manual. -- Randy Smith -- Randy Smith @ NCI Supercomputer Facility c/o PRI, Inc. Phone: (301) 698-5660 PO Box B, Bldng. 430 Uucp: ...!uunet!mimsy!elsie!ncifcrf!randy Frederick, MD 21701 (Use ...seismo!elsie... until Sept. 1st)
tsmith@usna.mil (Mechanical) (05/18/88)
This is a long message. If your aren't interested in sendmail and large networks then you might as well skip this message. You may have seen this message elsewhere as it is being cross posted to big-lan, sun-spots, nfs, tcp-ip, and unix-wizards. If there is a more appropriate list to discuss this in let me know and I will take this matter there. We here at the US Naval Academy (USNA) in Annapolis, MD are building a network. We have been operating an ethernet LAN connecting several minis and workstations for quite some time. We use thin, thick, and fiber based ethernet. We are reasonably well versed in TCP/IP and have experience with mpr's and gateways. Our hosts run the gamut from Zenith PC AT clones using SUNs PCNFS package to SUN workstations to VAX and Gould minis. We have about 20 hosts on our network that are capable of exchanging mail via sendmail. We are in a growth process and expect our number of workstations to increase dramatically as our new network is installed and more folks buy workstations. It is quite possible that we will eventually have 4-7k workstations and their servers attached to our network in the future. We currently use MMDF as our mail handler but are in the process of switching to sendmail as sendmail seems to be emerging as the "standard" mail handler. I have been selected to work on installing sendmail and planning our mail routing system. I have spent a reasonable amount of time working with sendmail and thought I would ask around to see if what everyone else is doing. Here is what I am planning/doing.... Some background... First, USNA will switch from 2 level domains to 3 level. Currently hostnames are of the form "machine.USNA.MIL", in the near future hostnames will change to the form "machine.division.USNA.MIL" (if necessary we might even switch to 4 level domains- "machine.department.division.USNA.MIL"). There will be an authoritative host named USNA.MIL. There will also be a host (or possibly an alias pointing to a host) for each sub-domain, ie there will be a sub-domain named "math.USNA.MIL" with a primary server named "math.USNA.MIL". Second, every user's home directory will be made available to him on every workstation in the yard. The goal is to allow any user to sit down in front of any workstation in the yard and be able to login and have his files available. Yes, I realize that will involve a tremendous amount of NFS cross mounts and may not actually be feasible but that is the plan for the time being. How the password file updates will be made has not yet been determined. Ideally I would like to use SUN's Yellow Pages to handle all of the password mess. I am not sure how may vendors do/will support YP but I will worry about that problem later. I have come up with the following tenets that I think are wise. If you disagree then send me mail and we can discuss it- maybe we all can learn something new about sendmail. I would prefer that all responses come straight to me and I will summarize to the net if there is interest. Maybe there is enough interest to start a sendmail interest group (provided there isn't already one that I don't know about). Sendmail workstation/server configuration philosophy: (aka "the gospel according to tim") ------------------------------------------------------- -All mail should live on a sub-domain host. Individual workstations should never receive incoming mail- there WILL NOT be a mailer daemon running on the workstation to receive incoming mail. Whether mail will live in /usr/spool/mail or the user's home directory is yet to be decided. I am leaning towards hacking sendmail to put mail in the user's home directory. -Workstations punt all mail to their sub-domain server. Workstations exchange mail only with their sub-domain server. Only outgoing mail is handled by workstations. -Workstations should have very minimal configuration files on them. Workstations should have a sendmail.cf that is virtually identical to all others in the yard. Workstation sendmail.cf's should essentially be "maintenance free". -The address data in intra-USNA messages will never contain a workstation hostname- only sub-domain names will be used. (There will be a host or host alias with the sub-domain name.) -Inter-sub-domain mail (ie intra-USNA) can be directly routed from one sub-domain server to another. -Mail bound for destinations outside USNA will be routed from the sub-domain host to the USNA.MIL server. This mail will have USNA.MIL in the address lines. Sub-domain names will never appear in outgoing message address lines. This will allow USNA.MIL to reliably accept mail from the outside world regardless of the status of the internal USNA network. -Mail arriving at USNA.MIL from outside hosts will be forwarded to the proper server using a large central data base of aliases on the USNA.MIL server. Individual users will also be able to forward their mail via the .forward file in their home directory. ---------- End of Philosophy Statement-------------------- Here is a typical scenario that I imagine... User "joe" invokes the sending front end to sendmail on his workstation. He composes and addresses a message to user "mike" and hands it to his mail agent to pass to sendmail. Sendmail on the local workstation starts up and the following takes place: 1) The workstation punts the message to the sub-domain server. 2) The sub-domain server tries to deliver the mail. If the sub-domain-server finds that "mike" is a user who gets his mail on this server then the mail is delivered as per sendmail's local mail delivery procedures. If the sub-domain-server finds that "mike" is a user who gets his mail on another sub-domain-server then the mail is passed to that server. If the local sub-domain-server cannot determine where "mike" gets his mail then the message is punted to USNA.MIL (the next level up the domain ladder). 3) USNA.MIL gets the mail and tries to deliver it. If USNA.MIL knows who the user is the mail will get delivered- if USNA.MIL doesn't know who the user is then that user doesn't exist and an error should be returned to the sender. What needs to be done to make all this happen is not yet known. SUN's Yellow Pages service either complicates or simplifies this whole issue. Do we expect all the machines in the yard to understand YP (it would sure be nice if they did!)? I doubt that I can count on all of the yard understanding YP. I am open to suggestions/opinions, one way or another. ------------------------------------------------------------ Problems I for see: -All sorts of "odd" cases... A user could be logged into a workstation in a division other than his own sending mail to anyone. Not a major problem but something to keep in mind when "Reply-To:" and "From:" lines are being set up. What should the "Reply-To:" and "From:" lines say? Should they list the sub-domain server that the user is sending from? Should they list the user's "home" sub-domain? (I would tend think so.) If the mail is addressed to someone outside of USNA then the problem will go away since (according to the tenets above) all mail leaving USNA should have its "Reply-To:" and "From:" fields rewritten to the form "user@USNA.MIL". A user may prefer to receive his mail on a machine other than his "home" sub-domain server. No big deal, a .forward file should handle this without any problems (I think). Where do aliases get expanded? I have just about ruled out an alias expansion on each workstation. I would think that they could be expanded on either the sub-domain server or on USNA.MIL (or maybe on both). -Conflicts over file locking and simultaneous access to the user's mailbox. Here is a possible scenario of locking problems... User "joe" is reading his mail on workstation "xxx.math.USNA.MIL". joe's workstation is diskless and mounts its files from his sub-domain server. In order for this to happen the directory that joe's mailbox lives in will have to be NFS mounted on his workstation. For joe to be able to delete messages from his mailbox he will need write permissions on his mailbox. Thus the NFS mount of the directory containing joe's mailbox will have to be mode "rw". I see a potential problem here. If joe is has just finished deleting messages from his mailbox and is updating it when a new message comes in (ie math.USNA.MIL tries to deliver it) there could be an ugly scene as the process trying to purge the deleted messages from the mailbox and the delivering agent fight over who gets to write in the mailbox file. So what happens in the above case? -Where do users mailboxes live? If I already have all sorts of home directories NFS cross-mounted all over the place I certainly don't want to add to the mess by cross mounting /usr/spool/mail all over. Not to mention what do I call the directories? I would be NFS mounting several different /usr/spool/mail directories from several different servers. I have already ruled out the idea of a single machine with a massive /usr/spool/mail for several reasons. Ideally I would like to have each user's mailbox live in his home directory. -------------------------------------------------- Sendmail Gripes: -sendmail.cf cannot find out its domain (or subdomain) internally (at least I can't figure out a way to do this). This would be a nice feature to have so we don't have to hard code this info into each sendmail.cf. (Isn't there a system call that returns the domain name of a host? How about adding an internal macro to sendmail to add this feature.) -It should be possible to configure sendmail to have the user's mailbox live anywhere (Like maybe their home directory). Well that is about it. I would like to hear from others- sendmail experiences, solutions to my problems, ideas about what to do next, or just commiseration would all be appreciated. NOTE: I LIKE SENDMAIL! I think it is very flexible and powerful. I am simply pointing out my difficulties (and non-difficulties) and asking whatcha'all think. So please spare me any flames telling me I don't appreciate sendmail and that I should be condemned to an afterlife in a post office in hell doing "manual mail routing". OK? Looking forward to hearing from everybody, Tim Smith US mail:CADIG mailstop: 11G E-mail: US Naval Academy internet:tsmith@USNA.MIL Annapolis, MD 21402 uucp :...!uunet!usna!tsmith MaBell :(301)267-4413
nsb+@andrew.cmu.edu (Nathaniel Borenstein) (05/24/88)
It sounds like you might be interested in the Andrew Message System. AMS was designed for the Andrew File System, but also works on NFS or with no central file system. Most of it is distributed as part of the Andrew release on the X11 R2 tape from MIT. (Some parts of it haven't made it onto the R2 release, but are expected to be on the R3 release this fall.) A good overview paper about it can be found in the February, 1988 USENIX proceedings. Basically, it does just about everything you ask for and a whole lot more, including, IF you're on a high-function workstation running X11, handling multi-media mail with rasters, animations, music, and so on. For more information, especially if you can't get ahold of the USENIX paper and/or MIT release, please send mail to me or to info-andrew@andrew.cmu.edu.
jik@athena.mit.edu (Jonathan I. Kamens) (03/22/91)
Sendmail uses nameserver Mail eXchange (MX) records to deliver mail to sites that are not directly on the Internet (or that are on the Internet but have requested MX service). The nameserver protocol allows clients to ask nameservers for several different types of information. Two of those are address records and MX records. An address record contains an Internet address. When sendmail is delivering mail to a site that has an Internet address, it asks the name service for the host record and then connects to the address it gets back in order to deliver the mail. An MX record contains a preference and a name. The name is the name of a host to which mail should be sent; that host must have an address record registered. The preference is a number; the higher the number, the more the mailer is encouraged to use that MX record. This way, a host can have multiple MX records, some serving as backup, and the ones with the higher preference will get tried first. The way sendmail actually delivers mail is to *first* ask the name service for an MX record. If it gets one or more back, then the mail is delivered as the response indicates. This allows sites that are on the Internet but that do not accept mail to use the name service to get their mail sent somewhere else. Then, if the MX record query fails, it asks for an address record, and if it gets one back, it tries all of the addresses in the record (hosts can have multiple address records just as they can have multiple MX records, although address records do not have preferences) until it can connect to one. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710