Re: [Mimedefang] New spam technique
On Fri, 2 Jul 2004, Penelope Fudd wrote: Recently spammers verified their mailing list using this SMTP dialogue. This is an old technique called a dictionary attack or directory harvesting. Sendmail 8.13 has countermeasures, like closing a connection after N bad SMTP commands. I run a script from cron that parses the mail log and firewalls off directory harvesters. -- David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] New spam technique
Recently spammers verified their mailing list using this SMTP dialogue. How do I add this to mimedefang? 220 scotty.example.com ESMTP Sendmail 8.12.11/8.12.11; Thu, 1 Jul 2004 15:08:21 -0700 HELO c-24-1-219-157.client.comcast.net 250 scotty.example.com Hello c-24-1-219-157.client.comcast.net [24.1.219.157], pleased to meet you MAIL FROM: [EMAIL PROTECTED] 250 2.1.0 [EMAIL PROTECTED]... Sender ok RCPT TO: [EMAIL PROTECTED] 550 5.1.1 [EMAIL PROTECTED]... User unknown RCPT TO: [EMAIL PROTECTED] 250 2.1.5 [EMAIL PROTECTED]... Recipient ok RCPT TO: [EMAIL PROTECTED] 250 2.1.5 [EMAIL PROTECTED]... Recipient ok DATA 354 Enter mail, end with . on a line by itself Received: from 55.196.39.38 by 24.1.219.157; Thu, 20 Mar 2003 18:59:10 -0400 Message-ID: S[20 . 250 2.0.0 i61M8Lw7028495 Message accepted for delivery QUIT 221 2.0.0 scotty.example.com closing connection -- Penelope Fudd [EMAIL PROTECTED] ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] New spam technique
On Mon, 2004-07-05 at 09:50, David F. Skoll wrote: Recently spammers verified their mailing list using this SMTP dialogue. This is an old technique called a dictionary attack or directory harvesting. Sendmail 8.13 has countermeasures, like closing a connection after N bad SMTP commands. I think spammers have adapted by sending only a few addresses at a time, perhaps from virus-owned zombie relays. I still have one box running qmail with port 25 open directly to the internet although it's MX is through a sendmail/mimedefang relay. It gets thousands of bad-address spams a day hitting its open port directly but in patterns of 6 or so from any one sender at a time. The domain is due to be moved elsewhere soon so I haven't done anything to try to fix the problem yet. --- Les Mikesell [EMAIL PROTECTED] ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] New spam technique
On Mon, 5 Jul 2004, Les Mikesell wrote: I think spammers have adapted by sending only a few addresses at a time, perhaps from virus-owned zombie relays. That was the logical next step. It's practically impossible to fight that. And honestly, until directory harvest attacks start overloading my machine or costing me bandwidth, I ignore them just like I ignore most port scans. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Using Mail::GPG in filter to examine PGP attachments and message body
I'm trying to implement a corporate policy on use of encryption, with
restrictions in the filter to enforce the policy as much as possible.
The elements of the policy are:
1. All mail to selected domains must be encrypted
2. Encryption is to be all or nothing - if any unencrypted part is found, the
mail is to be rejected
3. All messages must be encrypted to at least two internal keys, one of which
must be the corporate key to ensure that we can recover the message contents if
required. The corporate key ID is 4B771017.
I have a working filter which is capable of spotting encrypted messages by the
presence of a .PGP or .ASC attachment, and also by the presence of a PGP message
block in a text/plain body, but in order to do the rest, I need to be able to
get some details about the keys in the message, and so I have to use something
like Mail::GPG to get the details.
Here is my sub-routine to check entities:
sub pgp_check($$$)
{
my ($entity,$fname,$type) = @_;
use Mail::GPG;
my $pass;
my $reciplist;
open(PASS,/home/defang/.gpgpass) || die Cannot open GNUPG passphrase file;
$pass=PASS;
my $gpg = Mail::GPG-new(default_key_id='4B771017', default_passphrase=$pass,
debug=1,
gnupg_hash_init={ armor = 1,
batch = 1,
homedir = '/home/defang'} );
# try to use GNUPG to work out the keyholders (!)
$encrypted = $gpg-is_encrypted (entity = $entity);
if ( $encrypted)
{
($decrypted_entity, $result) = $gpg-decrypt (
entity = $entity,
passphrase = $pass
);
$encrypted = $result-get_is_encrypted;
$decryption_ok = $result-get_enc_ok;
$encryption_key_id = $result-get_enc_key_id;
$encryption_mail = $result-get_enc_mail;
$signed = $result-get_is_signed;
$signature_ok= $result-get_sign_ok;
$signed_key = $result-get_sign_key_id;
$signed_mail = $result-get_sign_mail;
$signed_mail_aliases = $result-get_sign_mail_aliases;
$stdout_sref = $result-get_gpg_stdout;
$stderr_sref = $result-get_gpg_stderr;
$gpg_exit_code = $result-get_gpg_rc;
if ($encrypted)
{
if ($decryption_ok)
{
($key_id, $key_mail) = $gpg-query_keyring ( search = $encryption_key_id
);
$reciplist = $reciplist.:$key_mail($encryption_mail/$key_id);
}
if ($signed)
{
$gpgcomments = $gpgcomments. Signed by $signed_mail($signed_key);
}
}
$i=1;
foreach $line( split(/\n/,$$stderr_sref) )
{
if ( $line =~ /encrypted with/ )
{
@words = split / /, $line;
$key= $words[7];
$key=~ s/,//g;
($key_id, $key_mail) = $gpg-query_keyring ( search = $key );
$reciplist = $reciplist.:$key_mail($key_id);
}
$i++;
}
}
# now log the details
if ( $encrypted )
{
md_syslog('info',GnuPG debug - $Sender,$fname,$reciplist,$gpgcomments);
}
return 1;
}
When running this check from filter(), the slave dies with the following
messages to STDERR:
gpg: CRC error; 53ae1d - dc353a
gpg: quoted printable character in armor - probably a buggy MTA has been used
However, the documentation for MIME::Parser and MIME::Tools suggests that the
entity should already have been decoded. Testing with a script which creates a
MIME::Entity by calling parse_open on a captured mail file has similar results,
but if I manually take out the quoted-printable encoding (replacing =3D by = in
two places), then it works as expected.
Any idea why it thinks the entity is still encoded?
Best Wishes,
Paul.
__
Paul Murphy
Head of Informatics
Ionix Pharmaceuticals Ltd
418 Science Park, Cambridge, CB4 0PA
Tel. 01223 433741
Fax. 01223 433788
___
DISCLAIMER:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to which they
are addressed. If you have received this email in error please contact
the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741
___
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] New spam technique
I think spammers have adapted by sending only a few addresses at a time, perhaps from virus-owned zombie relays. That was the logical next step. It's practically impossible to fight that. And honestly, until directory harvest attacks start overloading my machine or costing me bandwidth, I ignore them just like I ignore most port scans. One possible approach is to appear to accept all addresses, then check the recipient address but take no action until the DATA phase - at which point you can refuse the message with a 5xx error without indicating whether the address exists or not. That way, they spend time compiling a list where all of their guesses appear to work, but none of their messages get through - and they don't know whether its because the user doesn't exist, or they are blacklisted, or your spam filter caught them, etc. In a good implementation, you could combine this with the greylist database to permanently blacklist any sender/relay combination which had three or more wrong addresses. In the meantime, you have an easy way of identifying anyone using this technique, as you can flag it for Graphdefang to analyse. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] New spam technique
On Mon, 5 Jul 2004, Paul Murphy wrote: One possible approach is to appear to accept all addresses, then check the recipient address but take no action until the DATA phase - at which point you can refuse the message with a 5xx error without indicating whether the address exists or not. That doesn't work if there is more than one recipient, some valid and some invalid. At the end of DATA, you can only indicate success or failure for the entire message and all recipients. Exchange does this by default; it's forced to generate NDN's for invalid recipients. Really, there needs to be an extension to SMTP that lets you return multiple success/failure codes after DATA (one code per recipient). Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] block based on outgoing recipient
Would this item; in filter_end exclude all further mail filtering, on mail
going from localhost to this a particular recipient?
#in filter_end.
if ($recipient =~ /[EMAIL PROTECTED]/) {
exit;
}
Does not appear to be working...
--
Luke Computer Science System Administrator
Security Administrator,College of Engineering
Montana State University-Bozeman,Montana
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Using Mail::GPG in filter to examine PGP attachments and messagebody
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
$pass=PASS;
my $gpg = Mail::GPG-new(default_key_id='4B771017',
default_passphrase=$pass,
debug=1,
gnupg_hash_init={ armor = 1,
batch = 1,
homedir = '/home/defang'} );
Are you really sure you want to do this? The whole point of
end-to-end encryption is to protect from attacks along the way. If
you have the private key and passphrase available on the mail server,
it becomes a single point of failure that would break the encryption
on all of the messages, past and future.
I would recommend that you simply check that the message was
encrypted to the corporate key. Don't actually decrypt it. This does
mean that someone could edit the PGP data to make it look like the
message was encrypted to the corporate key when it wasn't. If this
happens, what is lost? The original recipient can still read the
message, you simply can't decrypt it later with the corporate key.
This may or may not be a problem in your situation.
By the way, E3AA17BD actually looks more like the corporate key (by
its name and the fact that it can revoke your key). For either key,
you've got one subkey setup -- size 2048, never expires. Especially
for a long-life corporate key, you should setup multiple encryption
subkeys with expiration dates. That way, the compromise of one subkey
will only compromise messages that were encrypted to that subkey.
Richard Laager
-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2
Comment: If you don't know what this is, you can safely ignore it.
iQA/AwUBQOm/Tm31OrleHxvOEQJ7FwCg2YPuTb/p3xZGa3ZS0BgnOJbEvLEAoKhU
qdbzlcw8IUvOs4C6PuAZHLO/
=QpMk
-END PGP SIGNATURE-
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] file descriptor scope and embedded perl
Hi All, Since upgrading to the latest MIMEDefang today I have bad file descriptor errors - I assume this is an embedded perl scope issue. So, I currently do the following: 1) I do *not* use filer_initialise 2) The file descriptor are global and are declared *outside* of any function. 3) valid connections are made using a 'connection test function' within functions called within the 3 main filter functions. 4) file descriptors are closed in filter_cleanup I take it that I shouldn't be doing 2? Can/Should I declare *slave* globals in filter_initialise? Thanks for your help, Chris __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] ClamAV not detecting all viruses
Anyway, as of this posting, entity_contains_virus() functions are officially deprecated. They may be removed in a future version of MIMEDefang. thats funny - I thought message_contains_virus was depracated and entity_contains_virus was replacing it. That solves my problems pretty damn quick. Thanks David, Stewart ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] file descriptor scope and embedded perl
Chris Masters wrote: Hi All, Since upgrading to the latest MIMEDefang today I have bad file descriptor errors - I assume this is an embedded perl scope issue. So, I currently do the following: 1) I do *not* use filer_initialise 2) The file descriptor are global and are declared *outside* of any function. 3) valid connections are made using a 'connection test function' within functions called within the 3 main filter functions. 4) file descriptors are closed in filter_cleanup I take it that I shouldn't be doing 2? Can/Should I declare *slave* globals in filter_initialise? Thanks for your help, Chris Chris, The documentation for mimedefang-filter specifically states that if you're using Embedded Perl, you *MUST* use filter_initialize to initilize variables (such as file descriptors) that need to be seen across slaves. with embedded perl, the (outside of any subroutine) global variables are only initialized once on initial startup, and not on a per-slave basis. check the mimedefang-filter man pages for more specific information. hope this helps. alan ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] block based on outgoing recipient
Lucas Albers wrote:
Would this item; in filter_end exclude all further mail filtering, on mail
going from localhost to this a particular recipient?
#in filter_end.
if ($recipient =~ /[EMAIL PROTECTED]/) {
exit;
}
Does not appear to be working...
Lucas,
if you just want to bypass all filtering for mail originating on your
localhost and being sent to a specific recipient, wouldn't using
filter_recipient be more appropriate?
I haven't used it personally, but the pseudo-code could look something like:
sub filter_recipient {
if (localhost) {
if ($recipient =~ /[EMAIL PROTECTED]/) {
return ('ACCEPT_WITH_NO_MORE_PROCESSING', ok);
}
}
}
** this is pseudocode, it's not meant to run as-is. also, I couldn't
remember the return code off the top of my head, so be sure to
double-check it for accuracy
hope this helps,
alan
___
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
[EMAIL PROTECTED]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] file descriptor scope and embedded perl
On Mon, 5 Jul 2004, Chris Masters wrote: Since upgrading to the latest MIMEDefang today I have bad file descriptor errors - I assume this is an embedded perl scope issue. Possibly. 1) I do *not* use filer_initialise You should probably use it. Any files opened at global scope outside any function are opened once upon initialization. When a slave is started, mimedefang-multiplexor calls fork(2) and essentially dup's the file descriptors. However, the multiplexor child process (the one that's about to morph into a slave) then calls close(2) on all open file descriptors. Perl doesn't know about this---it thinks the file descriptors are still open---so when you try to use them, you get error messages. Can/Should I declare *slave* globals in filter_initialise? Yes. (And it's ...ize rather than ...ise, because I'm in North America rather than the UK. :-)) Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
