Spam Mail

[Cheetah]

If we receive spam mail and in the from address it says:
denis@mail.ourdomain.com (sent from our domain)

when there is not a customer with this e-mail address is this somebody using our mail server for spam?

[edigest]

If we receive spam mail and in the from address it says:
denis@mail.ourdomain.com (sent from our domain)

when there is not a customer with this e-mail address is this somebody using our mail server for spam?

Hi, Cheetah,

Not necessarily. Just about anything in the email header can be forged except the IP address from which the mail was sent. Locating the IP(s) in the email header is much more reliable than the From: address or the domains in the header.

Cheers,

Ray

[dynamicnet]

Greetings:

Log onto your mail server, change to root user, and then run

telnet relay-test.mail-abuse.org

That will run a number of tests, which, in the end, should show your system is closed to spam senders.

You may also want to check for vulnerable formmail scripts; we recently helped a managed service customer who was almost black listed by AOL due to a formmail script that was being abused by spam senders.

Thank you.

[Cheetah]

I tried your sugested command and it just timed out and would not connect.

also we use mforms but formail is turned on for customers, do you recomend turning this off or is there a way to protect it system wide from spammers?

The ip of origination is our CP box?
X-Originating-IP: [65.110.50.140]
Return-Path: <knjeymjy@codechina.com.cn>


any ideas?


Thanks

[dynamicnet]

Greetings Cheetah:

You may wan to try the command over time or from another server so you can see what the output looks like.

You can replace the formmail.cgi H-Sphere uses by updating the script in /hsphere/install/skel/scripts/cgi-bin/formmail

We use http://nms-cgi.sourceforge.net/

In terms of checking, if you have the complete email including all headers, you can get a free http://www.spamcop.net/ account and then post the email in their web-based reporting form.

Without going through the entire reporting process, you can find the IP's of the actual spam sender.

If the IP's belong to you, then you know it came from your server.

Thank you.

[Cheetah]

Do i just remove the formail script folder and install the nms?
and we have tenet dissabled so i don't think the command will work.

[edigest]

Do i just remove the formail script folder and install the nms?
and we have tenet dissabled so i don't think the command will work.

Heya, Cheetah,

You can replace the formmail.pl script with anything. Put what you want to replace formmail.pl in the ../skel directory. We put a note in there to contact support if they need a form mailer which gives us some control over what they're installing and/or running.

As far as telnet, you should still be able to telnet from your box even if the telnet service is disabled from the network side. Just give it a try and see if it works for you.

Cheers,

Ray

[Cheetah]

I have this file: formmail.cgi.in
in this dir: /hsphere/shared/skel/scripts/cgi-bin/formmail
do i replace this with the new .pl file?

also for some reson i cant run the telnet command from any server.
it might be set in our firewall or something.
also is it a good idea to block port 25 from anything but our mail server?

Thanks for the help.

[mangohost]

Yes, that's the script you want to replace. I also modified these two lines:
@referers = qw(!domain!);
@allow_mail_to = qw(!domain!);

The !domain! is hsphere's way of signifying that, when the script is copied to the user's directory, their domain should be put in there.

Yeah, most likely, your firewall is dropping your telnet packets (a good idea!). Just poke a temporary hole in the firewall for your mail server, then run the command from your mail server. When it's done, remove the hole.

[Cheetah]

Thank you for the !domain! tip
i was just strugling with that. :D

update:
i am still getting this error after making the changes you sugested.
here is what i have the qw before the @recipients was not there before and they sugest not to use it, what should be in the @referers function?
the same (!domain!)

BEGIN
{
$DEBUGGING = 1;
$emulate_matts_code= 0;
$secure = 1;
$allow_empty_ref = 1;
$max_recipients = 5;
$mailprog = '/usr/lib/sendmail -oi -t';
$postmaster = '';
@referers = qw(cheetahsolutions.com 127.0.0.1 localhost);
#@allow_mail_to = qw(!domain!);
@recipients = qw(!domain!);
%recipient_alias = ();
@valid_ENV = qw(REMOTE_HOST REMOTE_ADDR REMOTE_USER HTTP_USER_AGENT);
$locale = '';
$charset = 'iso-8859-1';
$date_fmt = '%A, %B %d, %Y at %H:%M:%S';
$style = '/css/nms.css';
$no_content = 0;
$double_spacing = 1;
$wrap_text = 0;
$wrap_style = 1;
$send_confirmation_mail = 0;
$confirmation_text = <<'END_OF_CONFIRMATION';
From: you@your.com
Subject: form submission

Thank you for your form submission.

END_OF_CONFIRMATION

[mangohost]

Actually, thank Jim about the !domain! tip, I had the same question last week!

I think you're confusing recipients and referer. I leave @recipients empty:
$DEBUGGING = 0;
$emulate_matts_code= 0;
$secure = 1;
$allow_empty_ref = 1;
$max_recipients = 2;
$mailprog = '/usr/lib/sendmail -oi -t';
$postmaster = 'postmaster@mangohost.com';
@referers = qw(!domain!);
@allow_mail_to = qw(!domain!);
@recipients = ();
%recipient_alias = ();
@valid_ENV = qw(REMOTE_HOST REMOTE_ADDR REMOTE_USER HTTP_USER_AGENT);

[Cheetah]

Thanks, but it is as yours?
and we are still getting this error
----------------------------------------------------------------
Bad Referrer - Access Denied
The form attempting to use this script resides at http://cheetahsolutions.com/testing.htm, which is not allowed to access this program.

If you are attempting to configure FormMail to run with this form, you need to add the following to @referers, explained in detail in the README file.

Add 'cheetahsolutions.com' to your @referers array.
----------------------------------------------------------------
but we can't add our site name as the referer
it doesn't seem to be working with (!domain!)
would it have anything to do with safe_mode being on?
just a thought :confused:

[mangohost]

I think I know where the misunderstanding is.

Okay, the !domain! thingy only goes into the skeleton version of formmail, the one that is at /hsphere/shared/skel/scripts/cgi-bin/formmail/formmail.cgi.in

When you click the formmail button in your user CP, that skel formmail gets copied to your user webroot, and !domain! gets replaced with your user domain.

If it's already been copied, then you could just manually edit the file (not the one in the skel directory, but your own). My guess is that you are putting the !domain! marker into the formmail that's already in your user webroot, correct? It's not gonna work there. So if it's already in your webroot's cgi-bin directory, you should just go ahead and manually replace the !domain! markers with your actual domain.

Alternately, if you want to test that the !domain! replacement works correctly, do this:

* go to your user cp, and in the formmail section, click On button so that it turns Off
* now delete the formmail directory in ~user/domainname/cgi-bin
* go back to user cp, click Off button in formmail section so that is On again

Now it should work.

[Cheetah]

Okay, the !domain! thingy only goes into the skeleton version of formmail, the one that is at /hsphere/shared/skel/scripts/cgi-bin/formmail/formmail.cgi.in

I thought you said i needed to replace this file with the new secure formmail?
I replaced it and no longer have it.

I have done this with turning it off then back on and it does create a formmail folder in the correct directory.

If it's already been copied, then you could just manually edit the file (not the one in the skel directory, but your own).
The old formmail you did not have to manually edit the file in the user web root for it to work, you only needed to and stuff while creating your form.

My guess is that you are putting the !domain! marker into the formmail that's already in your user webroot, correct?
No this is in the skel dir i was editing formmail.

you should just go ahead and manually replace the !domain! markers with your actual domain.

Again you have to edit the file in the user web root to get it to work?
why but the !domain! in if you have to manually edit it to get it to work?

I am sorry for all the confusion but this is not a difficult task i am sure.
the problem is when i set all variables stated above, turn off then back on formmail the dir is created in our web root we maid a test form tried to send and we still get the error above.

i looked at formail.cgi in our cgi-bin and the !domain! marker is still there i thought it was supposed to set it to the domain name :confused:

So will each user who want's to use formmail have to set there domain in the script?
the whole reason for changing from the original was for security from smap.

[dynamicnet]

Greetings:

Please the attached file in the skel directory replacing the existing formmail.cgi.in

When a customer sets up a NEW formmail, it will use that script. It must be present on every Web server; I also have it present on the CP server.

For existing clients who want to switch, they have to turn off and then turn on formmail.

The system should automatically handle the substitutes on the form variables; you should rarely have to edit the file for a given site.

Thank you.

[Cheetah]

Thank you very much.
so do i even need the new form mail that you posted above?

if not, that was the problem, i removed this file and replaced it with the new script posted above:http://nms-cgi.sourceforge.net/ :p

[mangohost]

Cheetah: No you don't "have to" edit the file in the webroot. I was giving you two different options -- you only "have to" manually edit if you've already turned on formmail. The other option was to turn off & back on so it re-copies and does the replacement automatically. But I think you get this point now.

Anyway, if it is not replacing the !domain! marker, try leaving the name of your new nms-formmail script as "formmail.cgi.in" (you don't need the old one) in the skel directory -- I have a feeling it is looking for this particular filename to replace the !domain! markers. When it copies over, it will copy over as "formmail.cgi", which should be fine. No need for it to actually be called "formmail.pl".

johnn

[Cheetah]

Got it all working, thanks to both of you. :D