jeff@fluke.UUCP (Jeff Stearns) (12/14/83)
Index: usr.lib/sendmail 4.2BSD Description: Under certain conditions, sendmail will discard mail which is to be forwarded to another machine. Repeat-By: Let there be two machines A and B, connected by ethernet. Let there be a user U with accounts on both machines. On machine A, let this user have a ~/.forward file which redirects mail to "U@B" Now have U log in on machine B and send mail to "U@A". The mail will be discarded upon receipt at machine A. ------------------------------------------------------------------------------- I have some additional clues. Here's an (electronically enhanced) syslog transcript produced by the daemon sendmail which received the letter at machine A. (I added the syslog() calls beginning with `--' in order to produce additional debugging information.) Note that the letter is never passed to any outgoing mailer for forwarding or delivery. /* * Sendmail hears an incoming ethernet letter. * It forks to read and process the letter. */ 7588 sendmail: connected, pid=7588 7588 sendmail: : openx 7588 sendmail: AA07588: assigned id 7589 sendmail: : openx /* * The incoming letter is received via SMTP at machine A, and is * assigned a queue id. */ 7589 sendmail: AA07589: assigned id 7589 sendmail: AA07589: from=<jeff@tc-jeff>, size=172, class=0 7589 sendmail: --sendall: e=83080 mode=b /* * The received message is deposited in the mail queue. */ 7589 sendmail: AA07589: queueup, qf=qfAA07589, df=dfAA07589 /* * A child is forked to deliver the message in the background. */ 7593 sendmail: in background, pid=7593 7593 sendmail: --sendall: Run through list and send everything... 7593 sendmail: ----sendall: mode=b 7593 sendmail: ----sendall: calling deliver(83080, 163716) /* * The child discovers that QDONTSEND is asserted for the * recipient, so it makes no attempt to deliver the letter. * (I don't know *why* QDONTSEND is set on this envelope.) */ 7593 sendmail: --deliver, first user=`jeff' (QDONTSEND) 7593 sendmail: ----sendall: mode=b 7593 sendmail: ----sendall: calling deliver(83080, 163844) 7593 sendmail: --deliver, first user=`jeff@tc-jeff' (QDONTSEND) /* * The child now REMOVES THE LETTER FROM THE MAIL QUEUE! */ 7593 sendmail: dropenvelope, id=AA07589, flags=0, pid=7593 7593 sendmail: AA07589: unlink dfAA07589 7593 sendmail: AA07589: unlink qfAA07589 7589 sendmail: finis, pid=7589 /* * The parent removes the lock file, and everything's gone. */ 7588 sendmail: AA07588: unlock 7588 sendmail: AA07588: unlink lfAA07588 Fix: I know of none. Clearing the `e' (expensive mailer) flag for the ether and local mailers does not help. -- Jeff Stearns John Fluke Mfg. Co. (206) 356-5064 P.O. Box C9090 Everett WA 98043 ...!decvax!microsoft!fluke!jeff
rpw3@fortune.UUCP (12/16/83)
#R:vax4:-125600:fortune:2000006:000:751
fortune!rpw3 Dec 15 14:22:00 1983
**Flame on**
Please, please don't assume that "metoo" is just a test feature. I, for
one, have it set since it is more useful to filter my own messages back
when I receive them (to print, to file, etc.), rather than to passively
collect them in a "file copy" (record=) with no filtering.
Also, my state of mind while sending an isolated message is not the
same as when I sit down to read/reply/print/file a batch of mail/news.
It is helpful to have have ALL of the discussion (including your own)
in one stream. (Yes, we use 'notes', but this is a multimedia shop.)
**Flame off**
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065essick@uiuccsb.UUCP (12/16/83)
#R:vax4:-125600:uiuccsb:6300005:000:752 uiuccsb!essick Dec 15 15:49:00 1983 This sounds like the effects of a "don't get into an infinite forwarding loop" clause in sendmail. Since I haven't looked any farther than the 4.1C documentation for sendmail, I can't offer any prepackaged solutions. This behavior solves the "I'm gone; call me in two weeks" auto-mail-answering problem. This problem might be corrected by changing the way infinite loops are detected from the outgoing edge where we can say "is this going somewhere it has been" to the incoming edge where we can say "have we seen this before and does it have the same destination as the last time we saw it". Note that this solution breaks down in the "I'm gone; call me" case since the bouncing letters are new messages. -- Ray Essick, University of Illinois
rpw3@fortune.UUCP (12/19/83)
#R:vax4:-125600:fortune:2000007:000:1249
fortune!rpw3 Dec 19 00:00:00 1983
Hmmmm... the infinite loop problem. I have two suggestions, neither of
which may be ultimately useful becasue implementing them might break
too much old software, but...
1. Yell, scream, demand, insist that systems supply guaranteed universally
unique I.D.'s on messages. Then you can at least detect loops at the
cost of caching "recently" seen I.D.'s). [One of the main reasons
Ethernet has 48 bit addresses, BTW]
2. Having done #1, look at the so-called "hot potato" routing algorithms
(and friends) that were popular a few years back (especially in
military work). In particular, there was a PhD thesis by a guy named
Tajibnakis (sp?) at Univ. Michigan which analyzed an algorithm which
guaranteed that every site would see every message and no link would
see it more than twice. Yea, I know that's better suited to USENET
ans BB's than to mail, but the real point is: Go back and dig up
some of the old store-and-fwd routing literature. An awful lot was
done on that before ARPAnet-style (fully connected all the time)
became popular.
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065mark@cbosgd.UUCP (Mark Horton) (12/22/83)
Sounds like the "metoo" business may be getting involved. If you send to a mailing list and you're on it, it won't send you a copy. A .forward is just a mailing list with only one person on it. If I'm right, it only matters for cases involving sending yourself mail in useless ways, but won't affect real mail. Of course, people tend to send themselves test messages, and that can cause alarm.