No TLS is not implemented. It only effects her Outlook at her station. It's her IP that's being rejected. "Logs are clean" doesn't imply no logging, rather that there was nothing "dirty" or suspect there. I don't know what OS she is running as I am no onsite. The rejection is an SBL rejection. I've just never seen that for local clients as I understood that to be an incoming filter against a blacklist. I believe the problem is server-side as there are 200 or so users and most are in this office and she is the only one with this issue. I think there are bigger problem here and I'm continuing to research the situation. The big problem isn't her rejection, that is a symptom. There are also 3 days info missing from /var/log/messages. This server functioned find until Sunday. Nothing has changed with the box, absolutely nothing. I'm approaching this as a compromise. <<JAV>> ---------- Original Message ----------- From: "Steve Phillips" <steve@xxxxxxxxxx> To: redhat-list@xxxxxxxxxx Sent: Wed, 3 Dec 2003 15:07:51 +1300 (NZDT) Subject: Re: Weird sendmail behavior > > The box is RH7.3 up2date is run frequently though sendmail is behind a > > step > > due to rhn being clogged. I will update sendmail though manually. > > The version of sendmail was not the issue - the configuration was. This > lets us know if things have been altered outside the norm (TLS added > ? strange behaviours that we should be aware of that may have impact > ?) > > If the sendmail packages have been updated and the config was > changed then generally - the new config will be saved under a > different name and you will still be using your older and altered > config. - hence the question refering to the confguration NOT the > sendmail binary itself. > > > All other clients work with Outlook. > > Yes, but does the probably related to her workstation also appear > when using different clients ? what happens when you telnet to the > mail port and try to send mail manually ? > > > Logs are clean. > > So you dont log at all ? or is it that you dont see anything out of the > ordinary when her PC tries to send mail ? what does a log entry for her > mail transcript look like ? does it have the reject in the log or > does it come later ? if the reject is in the log what is the reason > given ? or does the log say the message was delivered sucessfully ? > > > No SMTP-AUTH > > OK. TLS ? WindowsXP (non service pack 1) had problems with most TLS > implementations that produced errors such as you are experiencing. (hence > the question) > > > She doesn't appear to resolve to a name which is odd. But even so, her > > subnet > > is in hosts.allow. > > what about the sendmail access file ? have you configured sendmail to > reject mail from non-resolving domains ? > > > The fact that all was well 2 days ago makes me think trojan. I can't seem > > to > > find it though. > > So what changed between now and two days ago - obviously something did. > While it is easy to point the finger and cry "virus", in many cases this > is not the case and can end up with unresolved problems. > > These are still outstanding. > > > what services pack/OS is on the machine ? > > does it work with different clients (OE, Eudora, pegasus mail ?) > > what happens when spam filtering is not enabled ? > > What do the reject messages say ? > > does [domain resolving] ? do other peoples ? > > Servicepack and OS of the machine (and last time she ran windows updates > and what it updated) may be entirely relevant (see the TLS issues > above) The different clients are also relevant as this tells us if > the problem appears to be related to things othe than the mail > seerver itself (the symptoms may not always point directly to the > problem) Is the problem with the spam filtering ? remove the > complexity and see if this fixes the problem and you can narrow down > the things you need to check. Reject messages are vitally imortant > as these actualyl give us something real to work with when trying to > fix the problem and domain resolving may also point to possible > broken things that are easily overlooked. > > We dont mind helping, but please help us to help you otherwise all > we can offer are opinions based on something other than fact. > > -- > Steve. > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list ------- End of Original Message ------- -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
