sendmail.log

[AlaskanWolf]

I really need to know if DarkOrb can turn this back on, or give us instructions on how to do it

We had 68k emails sitting the in queue, likely from a spammer, and i have no way of finding out, thanks to the disabling of sendmail.log

 

[rpmws]

WOW I just looked at mine and it stopped as well. Now what?

 

[feanor]

It was helpful, to be sure-
For the interim, doesn\'t the exim_mainlog / and exim_rejectlog provide the same detail, to a point?

Don\'t forget you can cat /var/spool/exim/input/* and grep for the address headers to find common themes (from senders... spammers, etc)

I am not sure how to go about re-enabling this as sendmail is a link to exim on cpanel systems....

 

[shaun]

Alaskinwolf.... My mqmonitor not working? or did you decide not to use it?

 

[AlaskanWolf]

Hi Shawn

thats how i found out there was 68k messages in the queue.

It would be great if Nick and crew could give us a choice in these matters, after all you certainly suprung it on us about sendmail.log being disabled and no way of telling us how to reeable it

Sendmail log really was more helpful then the exim logs, those really dont tell you anything about any user using sendmail. Thats why i want the sendmail.log back in operation.

 

[AlaskanWolf]

Nick, and you give us some honesty on this question or are you just going to ignore it???

Please, give us a some help here.

 

[bdraco]

sendmail.log was disabled because it had a problem with php

 

[AlaskanWolf]

any way to provide us instructions on turning it back on?

None of our systems had any issues with sendmail and php

Or a eta of when you think this will be turned back on:

 

[bdraco]

[quote:632c48115e][i:632c48115e]Originally posted by AlaskanWolf[/i:632c48115e]
any way to provide us instructions on turning it back on?

None of our systems had any issues with sendmail and php

Or a eta of when you think this will be turned back on: [/quote:632c48115e]

When everyone is running 4.0.6+ it should be safe to turn back on...however its kinda pointless with suexec since you should be able to track things down with mail headers or suexec_log

 

[AlaskanWolf]

we do not have suexec running, its more troublesome and it doesnt work

users are not able to use their cgi scripts (even pre-installed)

and frontpage users are not able to publish, all this has been discussed before

I would just like to see sendmail.log reenabled or instructions on how to turn it back on, no way am i installed suexec, its got way to much problems, even on freshly installed cpanel machines

 

[Daniel]

I had a spammer hit me last night. The first thing I went to was sendmail.log. He was still sending mail and I happened to see the formmail he was using and deleted the account. He had 12 formmail scripts. If he would have finished before I caught it I'm not sure how I would have found him.

We need sendmail.log or something that will show what scripts are sending mail with sendmail/exim. The email headers do not help. [email protected] is not very useful.

 

[feanor]

Normally the procedure here is to do a massive grep in domlogs, wherever you have them. (/usr/local/apache/domlogs usually)... for patterns that match the domain(s) being offensive of the sites they are representing. Or just searching for a particular HIGH frequency of &formmail.cgi& and all variations will point you to a formmail abuser.

Agreed, a separate log that can reveal this for the SMTP server alone would be very helpful- and definitely, not everything can be expected to go to suexec *yet*

just keep in mind domlogs can give you clues if not a final culprit in most cases- just be sure to calm the server in question before you do it.

(i.e. , kill cppop , kill apache for a couple moments)