Re: [Mimedefang] Spam ethics question
I've been using spampoison.com of late. Kinda makes me laugh. -Ben -- Ben Kamen - O.D.T., S.P. = Email: bkamen AT benjammin DOT net Web: http://www.benjammin.net ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
--- On Thu, 1/14/10, Ben Kamen wrote: > I had that for a bit where my low priority MX host was routed to self > and SBC (Ameritech) used to reject any email from as their servers > knew the seconday/low-priority route was bogus. OK, but I'm not suggesting its use on a live host (or domain). I'm suggesting it for honeypots, spamtraps, and other purposes in dealing with malicious senders. Any precise application is left to the reader. However, I do have some fake mailboxes using such a configured host sprinkled across my web pages. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
On 1/14/2010 4:12 PM, - wrote: I had that for a bit where my low priority MX host was routed to self and SBC (Ameritech) used to reject any email from as their servers knew the seconday/low-priority route was bogus. Poo. -Ben -- Ben Kamen - O.D.T., S.P. = Email: bkamen AT benjammin DOT net Web: http://www.benjammin.net ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
Playing games with spammers is fun. You could always do something like this: DNS records: fake.hostname.example.com. IN MX 10 tarbaby.junkemailfilter.com. MX 20 mail.example.invalid. MX 30 localhost. MX 40 @ ;itself. MX 50 mx.fakemx.net. A 0.0.0.0;any non-routable. 2001:DB8::1;any non-routable. SPF "v=spf1 -all" ;never a sender. localhost. IN ::1 A 127.0.0.1 SPF "v=spf1 a -all" All but the #2 MX resolve. The first and last are trap hostnames that always reject (but log the sender). Some spammers skip the first and/or last MX entries. The fourth generates timeout delays or "no route to host" errors. If the spammer can resolve "localhost" (the third) and accept the mail for relay, this could catch the spam in a loop on the spammer's machine (at least until a "Received:" header loop detector catches it). "Sit and spin" is a good result for a spammer. Delivery only occurs with "localhost." As for the original question, send the spammer a mailbox redirection to a mailbox under your fake hostname and let them sit and spin. ;-) ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
wbr...@e1b.org wrote: > Kelson wrote on 01/14/2010 02:43:35 PM: > >> It's not the effect that's at issue, it's the process. >> >> The whole point of a honeypot is that you have a guarantee that no one >> has ever requested that mail go to that address, so any mail sent there >> is unsolicited by definition. >> >> If you subscribe an address to a list, then *you* have solicited mail >> for that address. As a result, your data is no longer reliable, because >> at least some of that mail coming into that address is mail that you >> requested. > > This is the best argument against what I asked about. Thanks > >> OTOH, if you actively *unsubscribe* an address, then you have >> specifically requested that mail *not* go there. If they turn around and >> use that information to put the address on one of their lists, then >> you've caught them violating your request. It's still unsolicited, so >> it's valid data. > > Other option is to raise hell with the mail outsourcing company but does > that really work? Have you tried to report every such spam via spamcop.net (and knujon)? -- [pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu Recent research has tended to show that the Abominable No-Man is being replaced by the Prohibitive Procrastinator. -- C. N. Parkinson ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
Kelson wrote on 01/14/2010 02:43:35 PM: > It's not the effect that's at issue, it's the process. > > The whole point of a honeypot is that you have a guarantee that no one > has ever requested that mail go to that address, so any mail sent there > is unsolicited by definition. > > If you subscribe an address to a list, then *you* have solicited mail > for that address. As a result, your data is no longer reliable, because > at least some of that mail coming into that address is mail that you > requested. This is the best argument against what I asked about. Thanks > OTOH, if you actively *unsubscribe* an address, then you have > specifically requested that mail *not* go there. If they turn around and > use that information to put the address on one of their lists, then > you've caught them violating your request. It's still unsolicited, so > it's valid data. Other option is to raise hell with the mail outsourcing company but does that really work? Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
On 1/14/2010 10:05 AM, Andrzej Adam Filip wrote: "David F. Skoll" wrote: wbr...@e1b.org wrote: Why shouldn't I find some honey-pot addresses and submit submit them to subscribe? Because, IMO, that subverts the purpose of honeypots. A honeypot is designed as a passive spammer attractor; actively subscribing someone is a no-no. But actively un-subscribing not subscribed email addresses is OK => as far as I have heard the effect is almost identical :-) It's not the effect that's at issue, it's the process. The whole point of a honeypot is that you have a guarantee that no one has ever requested that mail go to that address, so any mail sent there is unsolicited by definition. If you subscribe an address to a list, then *you* have solicited mail for that address. As a result, your data is no longer reliable, because at least some of that mail coming into that address is mail that you requested. OTOH, if you actively *unsubscribe* an address, then you have specifically requested that mail *not* go there. If they turn around and use that information to put the address on one of their lists, then you've caught them violating your request. It's still unsolicited, so it's valid data. -- Kelson Vibber SpeedGate Communications ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
On 1/14/2010 12:05 PM, Andrzej Adam Filip wrote: "David F. Skoll" wrote: wbr...@e1b.org wrote: Why shouldn't I find some honey-pot addresses and submit submit them to subscribe? Because, IMO, that subverts the purpose of honeypots. A honeypot is designed as a passive spammer attractor; actively subscribing someone is a no-no. But actively un-subscribing not subscribed email addresses is OK => as far as I have heard the effect is almost identical :-) Hahahahah! ALthough I would speculate that their unscrupulous ways will catch up with them and they'll run into a honeypot sooner or later and get DNS-BL'd by one of the bigger lists. (and then trickle down) -Ben -- Ben Kamen - O.D.T., S.P. = Email: bkamen AT benjammin DOT net Web: http://www.benjammin.net Fortune says: Once, there was NO fun ... This was before MENU planning, FASHION statements or NAUTILUS equipment ... Then, in 1985 ... FUN was completely encoded in this tiny MICROCHIP ... It contain 14,768 vaguely amusing SIT-COM pilots!! We had to wait FOUR BILLION years but we finally got JERRY LEWIS, MTV and a large selection of creme-filled snack cakes! ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] exe in defective zip attachments gettingthrough mimedefang
Reference my last email ... I wasn't very clear.
Here is the original code:
sub re_match_in_zip_directory ($$) {
my($zipname, $regexp) = @_;
unless ($Features{"Archive::Zip"}) {
md_syslog('err', "$MsgID: Attempted to use
re_match_in_zip_directory, but Perl module Archive::Zip is not installed.");
return 0;
}
my $zip = Archive::Zip->new();
# Prevent carping about errors
Archive::Zip::setErrorHandler(\&dummy_zip_error_handler);
if ($zip->read($zipname) == AZ_OK()) {
foreach my $member ($zip->members()) {
my $file = $member->fileName();
return 1 if ($file =~ /$regexp/i);
}
}
return 0;
}
=== HERE IS MY SUGGESTION: === (added test for AZ_STREAM_END and FAIL all
other codes)
sub re_match_in_zip_directory ($$) {
my($zipname, $regexp) = @_;
unless ($Features{"Archive::Zip"}) {
md_syslog('err', "$MsgID: Attempted to use
re_match_in_zip_directory, but Perl module Archive::Zip is not installed.");
return 0;
}
my $zip = Archive::Zip->new();
# Prevent carping about errors
Archive::Zip::setErrorHandler(\&dummy_zip_error_handler);
my($archiveZipResults) = $zip->read($zipname);
if (($archiveZipResults == AZ_OK())||($archiveZipResults ==
AZ_STREAM_END())) {
foreach my $member ($zip->members()) {
my $file = $member->fileName();
return 1 if ($file =~ /$regexp/i);
}
} else { return 1; }
}
-Original Message-
From: mimedefang-boun...@lists.roaringpenguin.com
[mailto:mimedefang-boun...@lists.roaringpenguin.com]on Behalf Of Dave
O'Neill
Sent: Thursday, January 14, 2010 11:10 AM
To: mimedefang@lists.roaringpenguin.com
Subject: Re: [Mimedefang] exe in defective zip attachments
gettingthrough mimedefang
On Thu, Jan 14, 2010 at 10:54:14AM -0600, Cliff Hayes wrote:
> if Archive::Zip doesn't return an AZ_OK then mimedefang lets the
attachment
> through. From what I could find out, if Archive::Zip doesn't return AZ_OK
> then there is a problem with the zip file. I'd rather block defective zip
> files then let them through. In the code below, I substituted "return 0;"
> with "else { return 1; }" and that solved my problem. Now good zips still
> go through, zips with exe's get replaced with warning, and defective
(hacked
> I'm assuming) get replaced with warnings too. I'm surprised that standard
> procedure is to let defective zips through. Or am I understanding this
> wrong?
What value is ->read() returning? It might be nice to check the status
value and determine if it's failing due to a corrupt zip file, or simply
due to a zip format that Archive::Zip doesn't recognize.
If you can grab a sample of the zip in question and send it to me
offlist, I'll take a look.
Cheers,
Dave
--
Dave O'Neill Roaring Penguin Software Inc.
+1 (613) 231-6599http://www.roaringpenguin.com/
For CanIt technical support, please mail: supp...@roaringpenguin.com
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.725 / Virus Database: 270.14.139/2619 - Release Date: 01/14/10
01:35:00
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] exe in defective zip attachments gettingthrough mimedefang
On Thu, Jan 14, 2010 at 12:14:47PM -0600, Cliff Hayes wrote: Tried to send you 2 samples; got this error "550 5.1.1 ... User unknown" That's odd -- I can't find any delivery attempt in our logs. I did get your off-list reply telling me that you were about to send the samples, though. Were the samples sent from the same address? Anyway... Based on the above, shouldn't you be allowing AZ_OK and AZ_STREAM_END? Both seem to be equivalent to OK. I think I'll block 2, 3, and 4 Should be better than existing behaviour. Or, use Kevin McGrail's changes, posted earlier. Cheers, Dave -- Dave O'Neill Roaring Penguin Software Inc. +1 (613) 231-6599http://www.roaringpenguin.com/ For CanIt technical support, please mail: supp...@roaringpenguin.com ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
Andrzej Adam Filip wrote on 01/14/2010 01:05:49 PM: > But actively un-subscribing not subscribed email addresses is OK > => as far as I have heard the effect is almost identical :-) In many cases that's probably true. Upon further review of the headers, they are passing through mail outsourcer Magnet Mail. How likely is it that complaining to them about their customer will do any good? Our abuse address does not ever send email, and as far as I know it only appears on the domain records of any domain hosted on our DNS servers, and our ARIN records. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] exe in defective zip attachments gettingthrough mimedefang
Dave,
Tried to send you 2 samples; got this error "550 5.1.1
... User unknown"
I checked the valuse of ->read() per your request. It is "3" which is
"format error in the zip file" which is what I expected. Did some further
checking and here are the possible values:
AZ_OK (0) Everything is fine.
AZ_STREAM_END (1) The read stream (or central directory) ended normally.
AZ_ERROR (2) There was some generic kind of error.
AZ_FORMAT_ERROR (3) There is a format error in a ZIP file being read.
AZ_IO_ERROR (4) There was an IO error.
Based on the above, shouldn't you be allowing AZ_OK and AZ_STREAM_END? Both
seem to be equivalent to OK.
I think I'll block 2, 3, and 4
Thanks,
Cliff
-Original Message-
From: mimedefang-boun...@lists.roaringpenguin.com
[mailto:mimedefang-boun...@lists.roaringpenguin.com]on Behalf Of Dave
O'Neill
Sent: Thursday, January 14, 2010 11:10 AM
To: mimedefang@lists.roaringpenguin.com
Subject: Re: [Mimedefang] exe in defective zip attachments
gettingthrough mimedefang
On Thu, Jan 14, 2010 at 10:54:14AM -0600, Cliff Hayes wrote:
> if Archive::Zip doesn't return an AZ_OK then mimedefang lets the
attachment
> through. From what I could find out, if Archive::Zip doesn't return AZ_OK
> then there is a problem with the zip file. I'd rather block defective zip
> files then let them through. In the code below, I substituted "return 0;"
> with "else { return 1; }" and that solved my problem. Now good zips still
> go through, zips with exe's get replaced with warning, and defective
(hacked
> I'm assuming) get replaced with warnings too. I'm surprised that standard
> procedure is to let defective zips through. Or am I understanding this
> wrong?
What value is ->read() returning? It might be nice to check the status
value and determine if it's failing due to a corrupt zip file, or simply
due to a zip format that Archive::Zip doesn't recognize.
If you can grab a sample of the zip in question and send it to me
offlist, I'll take a look.
Cheers,
Dave
--
Dave O'Neill Roaring Penguin Software Inc.
+1 (613) 231-6599http://www.roaringpenguin.com/
For CanIt technical support, please mail: supp...@roaringpenguin.com
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.725 / Virus Database: 270.14.139/2619 - Release Date: 01/14/10
01:35:00
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
"David F. Skoll" wrote: > wbr...@e1b.org wrote: > >> Why shouldn't I find some honey-pot addresses and submit submit them to >> subscribe? > > Because, IMO, that subverts the purpose of honeypots. A honeypot > is designed as a passive spammer attractor; actively subscribing > someone is a no-no. But actively un-subscribing not subscribed email addresses is OK => as far as I have heard the effect is almost identical :-) -- [pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu The road to hell is paved with NAND gates. -- J. Gooding ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] exe in defective zip attachments gettingthrough mimedefang
Actually this topic was covered a while back when there were RAR files
masquerading as zip files.
Here's a function I call from filter_bad_filename. I've modified my filter
to handle a return of 1 as a bad file and 2 as a really bad file which
outright blocks the email.
sub filter_bad_filename ($) {
# Look inside ZIP files
if (re_match($entity, '\.zip$') and $Features{"Archive::Zip"}) {
my $bh = $entity->bodyhandle();
if (defined($bh)) {
my $path = $bh->path();
if (defined($path)) {
#CORRUPTED ZIPS ARE DANGEROUS - RETURN A REALLY BAD FILENAME
return 2 if (&check_for_corrupt_zip($path,
$entity->head->recommended_filename()));
return re_match_in_zip_directory($path, $re);
}
}
}
return 0;
}
sub check_for_corrupt_zip {
my ($path, $recommended_filename) = @_;
my ($filehandle, $header);
#OPEN THE FILE, GRAB THE HEADER AND TEST
$filehandle = new IO::File("< $path");
if (defined $filehandle) {
read($filehandle,$header,4);
close ($filehandle);
#IS IT A RAR FILE DISGUISED AS A ZIP?
if ($header =~ /^Rar!/i) {
md_syslog('warning', "$QueueID: Discarding because of RAR file
disguised as ZIP File: $recommended_filename");
return 1;
}
#IS IT A ZIP FILE WITH A VALID MAGICK NUMBER? - IDEA From Tomasz
Ostrowski
if ($header !~ /^PK\003\004/i) {
md_syslog('warning', "$QueueID: ZIP file has an invalid ZIP Magic
Number: $recommended_filename");
return 1;
}
}
return 0;
}
- Original Message -
From: "Dave O'Neill"
To:
Sent: Thursday, January 14, 2010 12:09 PM
Subject: Re: [Mimedefang] exe in defective zip attachments gettingthrough
mimedefang
On Thu, Jan 14, 2010 at 10:54:14AM -0600, Cliff Hayes wrote:
if Archive::Zip doesn't return an AZ_OK then mimedefang lets the
attachment
through. From what I could find out, if Archive::Zip doesn't return
AZ_OK
then there is a problem with the zip file. I'd rather block defective
zip
files then let them through. In the code below, I substituted "return
0;"
with "else { return 1; }" and that solved my problem. Now good zips
still
go through, zips with exe's get replaced with warning, and defective
(hacked
I'm assuming) get replaced with warnings too. I'm surprised that
standard
procedure is to let defective zips through. Or am I understanding this
wrong?
What value is ->read() returning? It might be nice to check the status
value and determine if it's failing due to a corrupt zip file, or simply
due to a zip format that Archive::Zip doesn't recognize.
If you can grab a sample of the zip in question and send it to me offlist,
I'll take a look.
Cheers,
Dave
--
Dave O'Neill Roaring Penguin Software Inc.
+1 (613) 231-6599http://www.roaringpenguin.com/
For CanIt technical support, please mail: supp...@roaringpenguin.com
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] exe in defective zip attachments getting through mimedefang
On Thu, Jan 14, 2010 at 10:54:14AM -0600, Cliff Hayes wrote:
if Archive::Zip doesn't return an AZ_OK then mimedefang lets the attachment
through. From what I could find out, if Archive::Zip doesn't return AZ_OK
then there is a problem with the zip file. I'd rather block defective zip
files then let them through. In the code below, I substituted "return 0;"
with "else { return 1; }" and that solved my problem. Now good zips still
go through, zips with exe's get replaced with warning, and defective (hacked
I'm assuming) get replaced with warnings too. I'm surprised that standard
procedure is to let defective zips through. Or am I understanding this
wrong?
What value is ->read() returning? It might be nice to check the status
value and determine if it's failing due to a corrupt zip file, or simply
due to a zip format that Archive::Zip doesn't recognize.
If you can grab a sample of the zip in question and send it to me
offlist, I'll take a look.
Cheers,
Dave
--
Dave O'Neill Roaring Penguin Software Inc.
+1 (613) 231-6599http://www.roaringpenguin.com/
For CanIt technical support, please mail: supp...@roaringpenguin.com
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] exe in defective zip attachments getting through mimedefang
Hello,
We're getting the standard UPS attachment scam. An exe is inside a zip
file.
Mimedefang catches most of these but it misses a few. I decided to track
one of the few through mimedefang and found out why in mimedefang.pl
if Archive::Zip doesn't return an AZ_OK then mimedefang lets the attachment
through. From what I could find out, if Archive::Zip doesn't return AZ_OK
then there is a problem with the zip file. I'd rather block defective zip
files then let them through. In the code below, I substituted "return 0;"
with "else { return 1; }" and that solved my problem. Now good zips still
go through, zips with exe's get replaced with warning, and defective (hacked
I'm assuming) get replaced with warnings too. I'm surprised that standard
procedure is to let defective zips through. Or am I understanding this
wrong?
Thanks, Cliff
sub re_match_in_zip_directory ($$) {
my($zipname, $regexp) = @_;
unless ($Features{"Archive::Zip"}) {
md_syslog('err', "$MsgID: Attempted to use
re_match_in_zip_directory, but Perl module Archive::Zip is not installed.");
return 0;
}
my $zip = Archive::Zip->new();
# Prevent carping about errors
Archive::Zip::setErrorHandler(\&dummy_zip_error_handler);
if ($zip->read($zipname) == AZ_OK()) {
foreach my $member ($zip->members()) {
my $file = $member->fileName();
return 1 if ($file =~ /$regexp/i);
}
}
else { return 1; }
}
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Spam ethics question
wbr...@e1b.org wrote: Why shouldn't I find some honey-pot addresses and submit submit them to subscribe? Because, IMO, that subverts the purpose of honeypots. A honeypot is designed as a passive spammer attractor; actively subscribing someone is a no-no. Regards, David. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Spam ethics question
I just got spammed by a company that claims on their website "We hate SPAM as much as you do." So why did they repeatedly send it to our abuse address? They also sent it to almost every school district we filter email for. To the best of my knowledge, none of them requested the email either. Needless to say, they got a block in our global rules and submitted to SURBL. As I was checking their web site, I found the statement above right below the box to sign up for their newsletter, which was at the very top of the page. My dilemma is this: Why shouldn't I find some honey-pot addresses and submit submit them to subscribe? -- William Brown Web Development & Messaging Services Technology Services, WNYRIC, Erie 1 BOCES (716) 821-7285 Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
