[Mimedefang] OT - Using rDNS sendmail hack - your experiences
Hello all, this is a bit off topic but relevant. We finally decided it was probably time to implement AOL style reverse DNS checks into our MTA. Since AOL has been doing it now for something like 6 months it is a pretty fair bet that most US customers that are legit have corrected their DNS issues... or so we thought! Why reinvent the wheel... we implemented a slightly modified version of this sendmail m4 HACK here: http://www.cs.niu.edu/~rickert/cf/hack/require_rdns.m4 Which basically does this: 1. Check relay for rDNS then check the response (gethostbyaddr check) 2. If there is not PTR record FAIL 3. If you cannot find DNS record for it at all, maybe DNS is down, TEMPFAIL 4. If there is rDNS (PTR) but it appears forged (different than forward or result doesnt resolve), TEMPFAIL Now we have been using the delay_checks feature for some time and you can add some options to this HACK if you do delay_checks, we made our default entry REJECT but frankly... we plan on putting any user level entrys to our access file in with an explicit REJECT or OK as it just makes the file much easier to read and understand. We placed it after the delay checks feature (as Niel suggests) and above the dnsbl entries in the mc file. Now I know the order really should not matter much in the mc file but it does seem to run before dnsbl checks do.. and cuts that load/traffic down considerably. Implementing this actually has cut the load on this server (my test one before I implement everywhere) in half! Not to mention the bandwidth savings which should be apparrent after a few days trending (since it is catching it earlier and avoiding even dnsbl checks in many cases, much less SA and most of MD checks. Anyway, So far I have only identified one domain I have had to whitelist (local mom-and-pop ISP) that was tempfailing due to a bad DNS setup, we have notified them and hopefully they will correct their DNS soon, I asked if they had customers that coudl not send to AOL... hehe, the answer was yes... we have alot of problems with AOL! So, my question is... I have been monitoring for about 6 hours now, will probably let it go another day before pushing this change out to my other servers... in the mean time.. any caveats from the peanut gallery? Any horror/war stories on a similar implementation? Jim -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Problem running virus-scanner
Hi there, I've installed mimedefang-2.51 along with clamav-0.84rc1, and trying initiate a sendmail session by telneting to localhost, I get the 451 4.3.0 Problem running virus-scanner everytime I try wither clamd or clamav-milter is running, any thoughts what's causing this? thanks! Ran. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Problem running virus-scanner
[EMAIL PROTECTED] wrote:
Hi there,
I've installed mimedefang-2.51 along with clamav-0.84rc1, and trying
initiate a sendmail session by telneting to localhost, I get the
451 4.3.0 Problem running virus-scanner
everytime I try wither clamd or clamav-milter is running, any thoughts
what's causing this?
thanks!
Ran.
Did you update your mimedefang-filter to reflect the actual location of the
clamd.sock file? Note that clamav-milter is not used by MIMEDefang.
That having been said, I find I save a lot of memory by running clamav-milter
on all incoming mail first, and MIMEDefang only on mail that passes
clamav-milter.
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
perl -emap{y/a-z/l-za-k/;print}shift Jjhi pcdiwtg Ptga wprztg,
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang stream-by-recipient and Mailman
Rich West wrote:
Quite suddenly, emails FROM the mailman server were not going out.
After a frazzling hour, it was discovered that a section of code in the
mimedefang filter was causing the problem, although the piece of code
was in place for well over a month. Commenting it out and restarting
mimedefang allowed the mailman mail to be sent out.
The code was:
if (stream_by_recipient())
{
return;
}
The mail should be going out, just more slowly. :-) You should see
a lot of queue files in your clientmqueue directory, which will all
be delivered at the next clientmqueue run.
The fix, obviously, is:
if ($RelayAddr ne 127.0.0.1) {
return if stream_by_recipient();
}
Regards,
David.
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] use strict
Anyone care to post a strict version of their filter as an example? :-) -Rich ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Mimedefang stream-by-recipient and Mailman
We have a server that has Mailman running on it for close to 80 lists,
and, on that same server, we have our
sendmail+mimedefang+File::Scan+Anomy mail server. Mailman sends its
mail out locally to the sendmail server (not utilizing VERP as that
caused us a world of other problems in the past), and mimedefang seems
to be analyzing the messages as they go out (not what was originally
intended).
Quite suddenly, emails FROM the mailman server were not going out.
After a frazzling hour, it was discovered that a section of code in the
mimedefang filter was causing the problem, although the piece of code
was in place for well over a month. Commenting it out and restarting
mimedefang allowed the mailman mail to be sent out.
The code was:
if (stream_by_recipient())
{
return;
}
Sendmail was logging the following when a message was sent to our test list:
Apr 26 15:00:27 ourserver sendmail[11884]: j3QJ0FmI011884:
from=[EMAIL PROTECTED], size=1964, class=-30, nrcpts=5,
msgid=[EMAIL PROTECTED], proto=ESMTP,
daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Apr 26 15:00:29 ourserver mimedefang.pl[11378]: j3QJ0FmJ011884: streamed
by domain or recipient and resent.
Apr 26 15:00:29 ourserver mimedefang[11362]: j3QJ0FmJ011884: Discarding
because filter instructed us to
Apr 26 15:00:29 ourserver sendmail[11884]: j3QJ0FmJ011884: Milter: data,
discard
Apr 26 15:00:29 ourserver sendmail[11884]: j3QJ0FmJ011884: discarded
Now, we've disabled stream_by_recipient, but it's global. We would
prefer to keep the stream_by_recipient() call in there (the server can
handle it) for other purposes. What would be the best way, in
filter_begin(), to utilize stream_by_recipient() for messages only
coming from external hosts (in other words, to utilize
stream_by_recipient() on all emails EXCEPT localhost)?
Thanks!
-Rich
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT - Using rDNS sendmail hack - your experiences
Personally, we've looked in to it. We tend to agree that AOL's position is somewhat aggressive since their techs are usually behind the time and don't support their own new technologies well. But, political opinions aside, we were leary about implementing it because, frankly, we were afraid of the possible negative impact. So, we have relied on MimeDefang to do this check for us.. However, as time has worn on (and the amount of SPAM has blossomed), we have started testing this hack on our in-house testing server. Hearing of your experiences does make me feel a bit better regarding the patch, too. Do you have any stats on how many connections this has prevented? I'd personally be interested in seeing your modified version of the hack (your hacked hack :) ) just to see and understand the differences. -Rich Hello all, this is a bit off topic but relevant. We finally decided it was probably time to implement AOL style reverse DNS checks into our MTA. Since AOL has been doing it now for something like 6 months it is a pretty fair bet that most US customers that are legit have corrected their DNS issues... or so we thought! Why reinvent the wheel... we implemented a slightly modified version of this sendmail m4 HACK here: http://www.cs.niu.edu/~rickert/cf/hack/require_rdns.m4 Which basically does this: 1. Check relay for rDNS then check the response (gethostbyaddr check) 2. If there is not PTR record FAIL 3. If you cannot find DNS record for it at all, maybe DNS is down, TEMPFAIL 4. If there is rDNS (PTR) but it appears forged (different than forward or result doesnt resolve), TEMPFAIL ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] use strict
--On Tuesday, April 26, 2005 3:27 PM -0400 Rich West [EMAIL PROTECTED] wrote: Anyone care to post a strict version of their filter as an example? :-) You should be able to add use strict; at the top of the file and then run mimedefang.pl -test. I got a warning for a missing my for $VirusFound in the stock filter, but I haven't updated in awhile so that may be fixed in the latest release. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT - Using rDNS sendmail hack - your experiences
Rich West wrote: Personally, we've looked in to it. We tend to agree that AOL's position is somewhat aggressive since their techs are usually behind the time and don't support their own new technologies well. But, political opinions aside, we were leary about implementing it because, frankly, we were afraid of the possible negative impact. So, we have relied on MimeDefang to do this check for us.. However, as time has worn on (and the amount of SPAM has blossomed), we have started testing this hack on our in-house testing server. Hearing of your experiences does make me feel a bit better regarding the patch, too. Do you have any stats on how many connections this has prevented? I've been using it on and off and I'd like to say I am simply AMAZED at the number of domains with horked up DNS, but considering the temperature of today's hire the cheapest admin we can attitude, I'm not. I just turned it off today after having it on since like December to see what happens (actually to prove to the person who asked me to turn it off that the people he wants email from should just fix their damn DNS)... So it definitely has its blessed-cursedness... It stops a lot of spam. It stops a lot of legit email. Can't say much more than that. I have some stats... they're tabular so... for what it's worth http://www.benjammin.net/www/pages/spam/month-index.html Look at the noDNS and ForgedDomain -Ben ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Limiting the floodgates
Ok, when running a domain one must have certian email addresses that are just unavoidable, perhaps the technical contact email for your DNS provider? Ones which can be scooped up through email harvesting. While I know this technique is old, I think I've thought up an idea on how to combat it. A lot of people have asked how to check if an email comes from a certian person for certian recipients. But my question is can I have some way to do an nslookup for the MX record of an intended recipient. For example, say I have an email address of [EMAIL PROTECTED] that I know is specifically for purchases through amazon. My appologize for the person who uses [EMAIL PROTECTED] since it will likely get scooped from this. The goal is to have an inbound email know that email for that address is specifically allowed only from amazon and to do DNS query for amazon's authorized email servers. If it's not originating from that point, it's denied. I know that this sounds a little like SPF, and it is very similar, it's just more restrictive and would be intended to be used on very specific accounts. Any thoughts on this as a good idea or bad idea? I'm thinking some sort of conf file that contains a mapping of authorized inbound connection and the recipeint address and then a function that can do the look up and compair with what's allowed. Don't figure it'd be too difficult. The only thing I can figure that makes me questionable is that the outbound email server for a company does not nessassarily have to have an MX record in DNS, so detecting if it's legit could be difficult. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Global variables in filter_sender() and filter_recipient() are not kept ?
Martin Blapp wrote: If I try to save the relay-address and a flag in filter_sender() or filter_recipient() I often get wrong entries in filter_begin() from a previous scan. [...] Do you know why this happens ? Yes. Regards, David. PS: Oh, you want the ANSWER? :-) Read the mimedefang-filter man page, especially the MAINTAINING STATE section. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Global variables in filter_sender() and filter_recipient() are not kept ?
Hi, PS: Oh, you want the ANSWER? :-) Read the mimedefang-filter man page, especially the MAINTAINING STATE section. RFTM MAINTAINING STATE section did help :-) Thanks ! Martin ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT - Using rDNS sendmail hack - your experiences
On Tue, Apr 26, 2005 at 04:21:23PM -0400, Rich West wrote: Personally, we've looked in to it. We tend to agree that AOL's position is somewhat aggressive since their techs are usually behind the time and We've found it highly effective when combined with other RFC related checks. No RDNS with a HELO that doesn't match and has no apparent relation to the IP, the IP has no obvious relation to the domain, etc. By itself it's going to get alot of legit mail from poorly configured hosts along with the spam. -- Kelsey Cummings - [EMAIL PROTECTED] sonic.net, inc. System Architect 2260 Apollo Way 707.522.1000 (Voice) Santa Rosa, CA 95407 707.547.2199 (Fax)http://www.sonic.net/ Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Appending a header for an SA test
I've got the following working to modify INPUTMSG prior to calling
SpamAssassin so I can add headers that then trigger SA rules. Just
wondering if anyone has any input on a prettier way to do it.
KAM
sub append_header_immediately {
#IN ORDER TO HAVE A HEADER TEST IN SPAMASSASSIN REACT TO DATA THAT MD
CREATES, WE HAVE TO EDIT THE INPUTMSG FILE PRIOR TO
#CALLING SA. USING action_change_header, ETC WILL NOT WORK. NO CHANGES
TO THIS FILE ARE SAVED (I Think)
my (%params) = @_;
my ($filehandle, $output);
$filehandle = new IO::File('+ ./INPUTMSG');
if (-s ./INPUTMSG 256*1024 $filehandle) {
while ($filehandle) {
if ($_ =~ /^$/) {
$output .= $params{'header'}\n$_;
} else {
$output .= $_;
}
}
}
seek $filehandle, 0, 0;
print $filehandle $output;
close ($filehandle);
#md_syslog('warning', Adding $params{'header'} immediately);
}
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] OT - Using rDNS sendmail hack - your experiences
You can whitelist users or entire domains from the rDNS check in your access file using Niel's hack. I would rather whitelist a single domain than turn it off entirely if you had been using it since december with only a little fallout. Add: rdns:1.2.3.4 OK rdns:@somehost.com OK to whitelist for solely rdns, it will also honor regular whitelist entries with no left hand side token: 1.2.3.4OK 5.6.7 OK 5.6RELAY All of the above exempts those IPs (or domain names) from rdns checks. As long as your users are not completely virtual (i.e. this box does mail routing only) then you can also do this on a per user basis. Jim On Tue, 26 Apr 2005 15:30:43 -0500, Ben Kamen wrote I just turned it off today after having it on since like December to see what happens (actually to prove to the person who asked me to turn it off that the people he wants email from should just fix their damn DNS)... -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Limiting the floodgates
On Tue, 26 Apr 2005 14:56:42 -0500 (CDT), Ian Mitchell wrote The only thing I can figure that makes me questionable is that the outbound email server for a company does not nessassarily have to have an MX record in DNS, so detecting if it's legit could be difficult. And in many cases the mail exchangers (MX servers) are entirely different than the outbound mail servers... this is almost always 100% true where the company outsources their spam/virus filtering to a third party (which we do alot of now days). Many large organizations do this for load balancing reasons as well or simply for tighter security. Bottom line is... SPF lets the organization that implementted their solution tell you where mail should originate from... your solution is you guessing and even if you guess right... what heappens when they change their infrastructure down the road? If you were to do anything like this I think it would be best to use something like SPF as a basis for your MX check... you can also disable FEATURE(`accept_unresolvable_domains') in your sendmail.mc file and rebuild sendmail (it really should only be enabled in a few firewall/NAT related incidents anyways) and that will take care of alot of them. Jim -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Mimedefang stream-by-recipient and Mailman
The code was:
if (stream_by_recipient())
{
return;
}
The mail should be going out, just more slowly. :-) You should see
a lot of queue files in your clientmqueue directory, which will all
be delivered at the next clientmqueue run.
The interesting thing was that nothing was getting queued up.. it was
getting discarded. :(
The fix, obviously, is:
if ($RelayAddr ne 127.0.0.1) {
return if stream_by_recipient();
}
Glad it was obvious. :) I didn't know (for sure) what variable was
available in filter_begin.
Thanks!
-Rich
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
