mccrave@kodak.UUCP (Donna McCrave) (02/28/89)
Greetings. I am trying to get our internet mailer all set up. I have an Ultrix 3.0 machine on which I have installed BIND4.8 and Sendmail5.61/IDA 1.2.8 with the libresolv.a created by BIND4.8. It all dropped in pretty well, surprisingly. The problem I have is that all mail coming in from the Internet gets the line "Apparently-To: <userid@kodak.com>" inserted in the header as well as the normal "To: userid@kodak.com" later on in the header. The mail gets delivered all fine, but I just wonder why this redundant information gets tacked on. According to the sendmail source (in collect.c), it is added when the to, cc, and bcc fields are null, so I'd like to correct this problem. Has anyone else seen this strange behavior? If you have any clues you'd like to share with me, please email to mccrave@kodak.com or ...!rochester!kodak!mccrave. Thanks. Donna McCrave Eastman Kodak mccrave@kodak.com
chet@amrap.CWRU.EDU (The Luscious One In The Middle) (03/04/89)
>Greetings. I am trying to get our internet mailer all set up. >I have an Ultrix 3.0 machine on which I have installed BIND4.8 >and Sendmail5.61/IDA 1.2.8 with the libresolv.a created by BIND4.8. >It all dropped in pretty well, surprisingly. Yeah, 4.3 networking at last... >The problem I have is that all mail coming in from the Internet >gets the line "Apparently-To: <userid@kodak.com>" inserted in >the header as well as the normal "To: userid@kodak.com" later >on in the header. >The mail gets delivered all fine, but I just wonder why this >redundant information gets tacked on. According to the sendmail >source (in collect.c), it is added when the to, cc, and bcc >fields are null, so I'd like to correct this problem. Has anyone >else seen this strange behavior? You're looking in the wrong place. One of the more dubious IDA enhancements tries to fix a `bug' with shared access to the SMTP input channel between sendmail and its children. The idea is that each message coming in on the SMTP channel is handled by a different child forked by the main sendmail after the MAIL FROM: command, while the parent continues to listen for SMTP connections. The parent and child both read from stdin and share the same file descriptor, but not the same FILE *. Therefore, when the parent starts reading the same input after the child has terminated, it reads the same input the child has just finished processing. The fix is to have all sendmails read from stdin unbuffered. The idea seems logical, but it just doesn't work, at least on Ultrix machines running 2.2 and 3.0 and Suns running 3.5. It causes exactly the bahavior you describe. The fix is to back out of the change. Comment out the line in main.c (about line 700 or 710) that says: setbuf(InChannel, (char *) NULL); and your problem will go away. Chet Ramey chet@{cwjcc,pirate}.CWRU.EDU Network Services Group Case Western Reserve University Weird, man. Too weird.