Re: [Mimedefang] Strange activity
On Wed, 4 Jan 2006, Dave Helton wrote: The next strain of the Sober virus is due to hit on the 5th of this month. In some parts of the world... it already is the 5th. Actually, I've seen it reverse, my logs fills with entries that the remote server dropped the connection during TLS handshake, even partners that used to be solid as rock (but very large, hence, it's likely that they are hit by virus attacks very hard). Bye, -- Steffen Kaiser ___ 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] Re: set_reply returned MI_FAILURE
On Wed, 04 Jan 2006 21:17:04 -0500, David F. Skoll [EMAIL PROTECTED]
wrote:
Tim Boyer wrote:
return action_drop_with_warning(\n.\n\n);
[...]
I've changed action_drop_with_warning to action_bounce.
Instead of bouncing, however, I'm getting the set_reply returned
MI_FAILURE in logs, and the message is not being rejected.
You can't have newlines (\n) in the text part of a bounce message.
That's probably the problem.
David, I'll give that a try - thanks much! But just FYI, that's what's in the
stock mimedefang-filter in 2.54:
if (filter_bad_filename($entity)) {
md_graphdefang_log('bad_filename', $fname, $type);
action_notify_administrator(A MULTIPART attachment of type $type,
named $fname was dropped.\n);
return action_drop_with_warning(An attachment of type $type, named
$fname was removed from this document as it\nconstituted a security hazard. If
yourequire this document, please contact\nthe sender and arrange an alternate
means of receiving it.\n);
}
# eml is bad if it's not message/rfc822
if (re_match($entity, '\.eml') and ($type ne message/rfc822)) {
md_graphdefang_log('non_rfc822',$fname);
return action_drop_with_warning(A non-message/rfc822 attachment named
$fname was removed from this document as it\nconstituted a security hazard. If
you require this document, please contact\nthe sender and arrange an alternate
means of receiving it.\n);
}
--
tim boyer
[EMAIL PROTECTED]
___
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] Re: set_reply returned MI_FAILURE
On Wed, 04 Jan 2006 21:17:04 -0500, David F. Skoll [EMAIL PROTECTED] wrote: Tim Boyer wrote: return action_drop_with_warning(\n.\n\n); [...] I've changed action_drop_with_warning to action_bounce. Instead of bouncing, however, I'm getting the set_reply returned MI_FAILURE in logs, and the message is not being rejected. You can't have newlines (\n) in the text part of a bounce message. That's probably the problem. That was it. Thanks much - and I'll submit a bug report. The default filter won't work, either. -- tim boyer [EMAIL PROTECTED] ___ 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] Re: set_reply returned MI_FAILURE
On Thu, 5 Jan 2006, Tim Boyer wrote: On Wed, 04 Jan 2006 21:17:04 -0500, David F. Skoll [EMAIL PROTECTED] wrote: Tim Boyer wrote: return action_drop_with_warning(\n.\n\n); [...] I've changed action_drop_with_warning to action_bounce. Instead of bouncing, however, I'm getting the set_reply returned MI_FAILURE in logs, and the message is not being rejected. You can't have newlines (\n) in the text part of a bounce message. That's probably the problem. David, I'll give that a try - thanks much! But just FYI, that's what's in the stock mimedefang-filter in 2.54: drop and bounce are two different things. drop simply discards the message part while bounce refuses the message in the SMTP conversation. You're using bounce, when the examples use drop. See the mimedefang-filter manpage for the details. -n -- --- nathan hruby [EMAIL PROTECTED] uga enterprise information technology services core services support --- In 1972 a crack commando unit was sent to prison by a military court for a crime they didn't commit ___ 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] Re: set_reply returned MI_FAILURE
Tim Boyer wrote: That was it. Thanks much - and I'll submit a bug report. The default filter won't work, either. Sure it will. action_drop_with_warning can have a multiline message, but action_bounce can't. My mistake if I misled you with my previous mail. 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
Re: [Mimedefang] Re: set_reply returned MI_FAILURE
On Thu, Jan 05, 2006 at 08:32:35AM -0500, David F. Skoll wrote:
Sure it will. action_drop_with_warning can have a multiline message, but
action_bounce can't.
It can if you patch mimedefang.c to use smfi_setmlreply instead of
smfi_setreply... (and some more patching to split into lines, etc).
However, it probably won't work on older milter implementations, if I
recall correctly, since smfi_setmlreply was added later on (in
sendmail 8.13? I forgot).
Not that I'm offering to provide a patch, currently... (unless someone
slows down the rotation of the earth by the couple of hours that I seem
to miss at the end of each day (or sometimes the end of the night :))
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
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] Re: set_reply returned MI_FAILURE
Jan Pieter Cornet wrote: Sure it will. action_drop_with_warning can have a multiline message, but action_bounce can't. It can if you patch mimedefang.c to use smfi_setmlreply instead of smfi_setreply... (and some more patching to split into lines, etc). That might appear in a future release of MIMEDefang. Algorithm will probably go like this: 1) If reply text does not contain \n, use smfi_setreply. 2) Otherwise, if milter library does not support smfi_setmlreply, convert \n to , use smfi_setreply, and log a warning. 3) Otherwise, split reply appropriately and feed to smfi_setmlreply. Not that I'm offering to provide a patch, currently... (unless someone slows down the rotation of the earth by the couple of hours that I seem to miss at the end of each day (or sometimes the end of the night :)) Well, come on, Jan. You had an extra second in 2005. Don't tell me you wasted it! 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
Re: [Mimedefang] Strange activity
On Wed, Jan 04, 2006 at 03:31:53PM -0500, David F. Skoll wrote:
Has anyone noticed some strange activity lately? Specifically, one of our
customers has been hit by hundreds or thousands of machines that open SMTP
connections to his boxes and then just sit there, leaving the connection
idle. This wreaks havoc by creating tons and tons of Sendmail processes.
Are you sure they just sit there after the initial connect? If so, you should
also see the did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
message logged at the same time as the timeout.
We fixed it by setting confTO_COMMAND to 3 minutes instead of the default one
hour; we're seeing about one connection every few seconds timing out (and
new ones coming into the start of the pipe, of course.) This is for a
smallish ISP.
Our logs don't go back very far, but I haven't seen a recent huge increase,
at least not since december 30th. I see in our logs about 1000 - 2000
per hour of these, which I consider background noise on our mail volume.
Most of these seem to be lost input channel from ... to MTA after rcpt,
so that seems more like (dictionary) scanning.
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
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] Strange activity
Jan Pieter Cornet wrote: Are you sure they just sit there after the initial connect? If so, you should also see the did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA message logged at the same time as the timeout. Does Sendmail log that message if *it* closes the connection? I thought it only did so if the client closes the connection. They may not actually be sitting doing nothing. I traced one which issued a RCPT command and then sat for over 10 minutes doing nothing. I killed it after 10 minutes, so don't know if it ever would have issued another command. Our logs don't go back very far, but I haven't seen a recent huge increase, at least not since december 30th. I see in our logs about 1000 - 2000 per hour of these, which I consider background noise on our mail volume. Most of these seem to be lost input channel from ... to MTA after rcpt, so that seems more like (dictionary) scanning. We see a lot of these, but hardly any timeout waiting for input from [xx.xx.xx.xx] during server cmd read except on this one client's systems. 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
Re: [Mimedefang] Strange activity
I have seen this on occasion. It appears to be a bad spam-bot. i.e. a
grooup of infected PCs supposed to be blasting you with spam were
incorrectly programmed/instructed and are instead doing what you described.
My evidence of this is that we track spam by source IP in real time,
tracking average spam score, number of good vs bad recipients etc, and block
the sending IPs in ip-tables in real time so they can not even connect. if
an IP has never sent legitimate mail it gets blocked after only the fourth
bad recipient for a short time, then longer, longer etc, until we are
blocking them for days at a time.
On any given day I see 10,000 to 15,000 IPs being involved in dictionary
style attacks against us (we now have over 2,000 mail domains, so we are a
big target). When I see the DOS style events you described it is the same
sets of IPs, and I usually see real spam start coming from them after a
while.
John
- Original Message -
From: David F. Skoll [EMAIL PROTECTED]
To: mimedefang@lists.roaringpenguin.com
Sent: Wednesday, January 04, 2006 3:31 PM
Subject: {SPAM} [Mimedefang] Strange activity
Has anyone noticed some strange activity lately? Specifically, one of our
customers has been hit by hundreds or thousands of machines that open SMTP
connections to his boxes and then just sit there, leaving the connection
idle. This wreaks havoc by creating tons and tons of Sendmail processes.
We fixed it by setting confTO_COMMAND to 3 minutes instead of the default
one
hour; we're seeing about one connection every few seconds timing out (and
new ones coming into the start of the pipe, of course.) This is for a
smallish ISP.
I'm wondering if it's an attack specifically on our customer, or if
there's
a DDoS botnet (or a buggy spam-sending botnet) around?
Typical Sendmail log excerpt (trimmed somewhat):
15:27:32 k04KOVAD016073: timeout waiting for input from [200.193.225.54]
during server cmd read
15:27:35 k04KOXAD016096: timeout waiting for input from
adsl-153-140-231.cha.bellsouth.net during server cmd read
15:27:36 k04KOWAD016072: timeout waiting for input from
80.178.87.220.adsl.012.net.il during server cmd read
15:27:38 k04KOEAD015968: timeout waiting for input from
abfh249.neoplus.adsl.tpnet.pl during server cmd read
15:28:00 k04KOoAD016164: timeout waiting for input from [200.55.54.94]
during server cmd read
15:28:09 k04KP7AD016293: timeout waiting for input from
12-208-169-86.client.insightBB.com during server cmd read
15:28:13 k04KP5AD016263: timeout waiting for input from
213-238-114-168.adsl.inetia.pl during server cmd read
15:28:19 k04KPHAD016353: timeout waiting for input from
f151173.upc-f.chello.nl during server cmd read
15:28:31 k04KPSAD016412: timeout waiting for input from
82-46-163-134.stb.ubr02.chwo.blueyonder.co.uk during server cmd read
15:28:31 k04KPUAD016422: timeout waiting for input from
djz211.neoplus.adsl.tpnet.pl during server cmd read
15:28:35 k04KP1AD016270: timeout waiting for input from
200164210160.user.veloxzone.com.br during server cmd read
15:28:42 k04KPeAD016473: timeout waiting for input from
xdsl-2217.elblag.dialog.net.pl during server cmd read
15:28:57 k04KPnAD016543: timeout waiting for input from
80.178.139.180.adsl.012.net.il during server cmd read
15:29:24 k04KQHAD016773: timeout waiting for input from
80.178.139.180.adsl.012.net.il during server cmd read
15:29:45 k04KQiAD016923: timeout waiting for input from
20150212040.user.veloxzone.com.br during server cmd read
15:29:51 k04KQoAD016953: timeout waiting for input from
82-170-159-208.dsl.ip.tiscali.nl during server cmd read
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
___
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] Improvement of re_match
Hello,
I would like to suggest an improvement of re_match in order to get to know
_why_ the filename is bad, the following function is modelled after
re_match:
===
sub ska_match ($$) {
my($entity, $regexp) = @_;
my($head) = $entity-head;
my($guess) = $head-mime_attr(Content-Disposition.filename);
if(defined($guess)) {
$guess = decode_mimewords($guess);
if(my @result = decode_mimewords($guess) =~ /$regexp/i) {
return @result; # return the match
}
}
$guess = $head-mime_attr(Content-Type.name);
if (defined($guess)) {
$guess = decode_mimewords($guess);
if(my @result = decode_mimewords($guess) =~ /$regexp/i) {
return @result; # return the match
}
}
$guess = $head-mime_attr(Content-Description);
if (defined($guess)) {
$guess = decode_mimewords($guess);
if(my @result = decode_mimewords($guess) =~ /$regexp/i) {
return @result; # return the match
}
}
return (); # No match found
}
if(re_match(...)) {
}
works as usual; but you get to know, what match (usually the $bad_exts),
because the n'th item in the array corresponds to the (n+1)'th '(' block
of the regex (aka $1, $2 a.s.o).
E.g.:
if(my @bad = re_match(...)) {
return action_bounce('Attachments of type ' . $bad[0] . ' are
blocked');
}
Bye,
--
Steffen Kaiser
___
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] Strange activity
On Thu, Jan 05, 2006 at 10:17:53AM -0500, David F. Skoll wrote:
Are you sure they just sit there after the initial connect? If so, you
should
also see the did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
message logged at the same time as the timeout.
Does Sendmail log that message if *it* closes the connection? I thought it
only did so if the client closes the connection.
Yes, at least, my own test against a 8.13.3 sendmail does so.
They may not actually be sitting doing nothing. I traced one which issued
a RCPT command and then sat for over 10 minutes doing nothing. I killed
it after 10 minutes, so don't know if it ever would have issued another
command.
It might be a spambot running on some lusers DSL connection who noticed
the strange activity (or his ISP did) and simply terminated the DSL connection
immediately. You'd be left (on your side) with a half-open TCP connection,
and not know about it until the timeout comes.
This might even be common for infected DSL machines where the user thinks:
time for lunch, *click*.
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
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] Strange activity
HI. From: David F. Skoll Subject: [Mimedefang] Strange activity Has anyone noticed some strange activity lately? Specifically, one of our customers has been hit by hundreds or thousands of machines that open SMTP connections to his boxes and then just sit there, leaving the connection idle. This wreaks havoc by creating tons and tons of Sendmail processes. I would like to suggest another possible explanasion to the buggy spam bot. Issues like that might also be related to MTU . Have you checked the MTU value of your customer mail servers? Can you try to ping with different packet sizes to some of the sender IP addresses? I do agree that the most reasonable explanasion so far is a spam/dictioanry/other attack software, but in addition you should also consieder layer 3 networking issues, or a combination of attacks hanging due to layer 3 problems or client side limitted bandwidth. Yizhar Hurwitz http://yizhar.mvps.org ___ 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] Strange activity
Yizhar Hurwitz wrote: I would like to suggest another possible explanasion to the buggy spam bot. Issues like that might also be related to MTU . Have you checked the MTU value of your customer mail servers? All I can check is the MTU of the Ethernet interface, which is 1500. I doubt it's an MTU issue, because lots of normal mail (including large messages) is flowing through perfectly well. Also, *all* of the machines (well, at least all of the ones I can tell from a PTR record) that are timing out are DSL, dial-up or cable modem machines. If it were an MTU issue, I'd expect to see the occasional legitimate mail server having problems. 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
sendmail logging question Re: [Mimedefang] Strange activity
Does Sendmail log that message if *it* closes the connection? I thought it only did so if the client closes the connection. I am 99% sure that it does in my testing with 8.13.3 and 8.13.5 but I'm trying to figure out sendmail logging weirdness as well. For example: tail /var/log/maillog -f | grep -i vacation run vacation from the prompt with no params. You'll probably see: Jan 5 12:30:49 intel1 vacation[22479]: uid 0: usage: vacation [-a alias] [-C cfpath] [-d] [-f db] [-i] [-j] [-l] [-m msg] [-R returnaddr] [-r interval] [-s sender] [-t time] [-U] [-x] [-z] login Create a .forward and .vacation.msg file on a user called test. Put in: \test, |vacation or |/usr/adm/sm.bin/vacation or whatever works on your system I would expect to get the same error but I don't and in fact I never get any vacation logs. Any thoughts? Is sendmail just wacky on logging? Regards, KAM ___ 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] resending mail sent to /var/spool/mail
We had one of our internal mail servers die for a little while today and when I run mailq (I'm on a Solaris 9 system) there are 1600 messages waiting with connection refused errors in /var/spool/mqueue. However, since I'm using mimedefang with sendmail as a gateway, my sendmail processes are only looking at the mimedefang socket for messages and since sendmail is going to look in the /etc/mail/sendmail.cf file, I'm at a loss on how to get this messages delivered. Ok, just started to read the man pages and there is a -C option I can use. Any suggestions for getting these messages out and running another sendmail to check this queue? Thanks __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.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] resending mail sent to /var/spool/mail
Try: sendmail -q Jason A. Bertoch Network Administrator [EMAIL PROTECTED] ElectroNet Intermedia Consulting 3411 Capital Medical Blvd. Tallahassee, FL 32308 (V) 850.222.0229 (F) 850.222.8771 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Ford Sent: Thursday, January 05, 2006 4:50 PM To: mimedefang@lists.roaringpenguin.com Subject: [Mimedefang] resending mail sent to /var/spool/mail We had one of our internal mail servers die for a little while today and when I run mailq (I'm on a Solaris 9 system) there are 1600 messages waiting with connection refused errors in /var/spool/mqueue. However, since I'm using mimedefang with sendmail as a gateway, my sendmail processes are only looking at the mimedefang socket for messages and since sendmail is going to look in the /etc/mail/sendmail.cf file, I'm at a loss on how to get this messages delivered. Ok, just started to read the man pages and there is a -C option I can use. Any suggestions for getting these messages out and running another sendmail to check this queue? Thanks __ Yahoo! DSL - Something to write home about. Just $16.99/mo. or less. dsl.yahoo.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 smime.p7s Description: S/MIME cryptographic signature ___ 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] resending mail sent to /var/spool/mail
Stephen Ford wrote: We had one of our internal mail servers die for a little while today and when I run mailq (I'm on a Solaris 9 system) there are 1600 messages waiting with connection refused errors in /var/spool/mqueue. This should do it: sendmail -q -O QueueDirectory=/path/to/queue That starts a sendmail process that will run through the queue once. -- Kelson Vibber SpeedGate Communications, www.speed.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] resending mail sent to /var/spool/mail
On Thu, Jan 05, 2006 at 02:23:32PM -0800, Kelson Vibber wrote: sendmail -q -O QueueDirectory=/path/to/queue That starts a sendmail process that will run through the queue once. If your queue is large (and the concept of large really depends on your hardware -- it could mean 1000 entries, or 5), you might also want to add one of: -OQueueSortOrder=file or -OQueueSortOrder=random to your 'sendmail -q' invocation. The default QueueSortOrder is priority, which means that before processing any queued message, the queue runner needs to read each qf file, get the priority, and then process the resulting list in priority order. Using 'file', the queue runner just processes them in filename order, which is fine if you have one queue runner. If you want to run multiple queue runners, the 'random' method is better, as the queue runners won't be trying to process the queued files in the same order Cheers, Dave -- Dave O'Neill [EMAIL PROTECTED]Roaring Penguin Software Inc. +1 (613) 231-6599 ext. 104 http://www.roaringpenguin.com/ For CanIt technical support, please mail: [EMAIL PROTECTED] ___ 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] Strange activity
On Thu, Jan 05, 2006 at 02:50:09PM -0500, David F. Skoll wrote:
All I can check is the MTU of the Ethernet interface, which is 1500.
I doubt it's an MTU issue, because lots of normal mail (including
large messages) is flowing through perfectly well. Also, *all* of the
machines (well, at least all of the ones I can tell from a PTR record)
that are timing out are DSL, dial-up or cable modem machines. If it
were an MTU issue, I'd expect to see the occasional legitimate mail
server having problems.
No, not necessarily. In fact, the MTU suggestion is a very good one.
Usually it's not the MTU on the mail server that's the problem. It's
the MTU on the other side.
A lot of DSL solutions use some form of tunneling, thereby limiting the
max MTU to something like 1480. Now if you somewhere have a stupid
firewall that blocks all ICMP (including the fragmentation needed ICMP
subtype, which is used for path MTU discovery). When the server then
sends a packet over 1480 bytes long, it will need fragmentation by the
receiving dsl modem, which will send back an ICMP fragmentation needed,
which will get discarded by the silly firewall before the mailserver,
and communication will hang.
However, this situation is kindof hard to trigger when receiving mail
on the mailserver (which will only send out short replies after each
command received), and it's easy to spot using tcpdump, because you'll
see a normal tcp-exponential-backoff-repeat-the-last-packet without
seeing a reply (repeats the last packet with intervals of 3, 6, 12, 24...
etc seconds).
The only way I can see it triggering max MTU and then hanging in cmd read
is if the sending side sent a large amount of SMTP commands in one packet.
Which would be very indicative of a spambot or scanbot.
--
#!perl -wpl # mmfppfmpmmpp mmpffm [EMAIL PROTECTED]
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}-(map{/p|f/i+/f/i}split//,$)+97):qw(m p f)[map{((ord$)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$;$f.eig;# Jan-Pieter Cornet
___
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] Re: set_reply returned MI_FAILURE
On Thu, 05 Jan 2006 08:32:35 -0500, David F. Skoll [EMAIL PROTECTED] wrote: Tim Boyer wrote: That was it. Thanks much - and I'll submit a bug report. The default filter won't work, either. Sure it will. action_drop_with_warning can have a multiline message, but action_bounce can't. My mistake if I misled you with my previous mail. Regards, David. Ah - that make sense. I _thought_ it was rather odd that I was the first person to notice this! :) Thanks much... -- tim boyer [EMAIL PROTECTED] ___ 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] resending mail sent to /var/spool/mail
Move the mqueue directory to something like mqueue-temp and make a new one with same permissions/owners (do this with sendmail stopped) then start sendmail, once load is low enough you can start a new sendmail process to process that mqueue-temp like this: sendmail -q -oQ/full/path/to/mqueue-temp If for some peverse reason you want to watch the mail being processed, add a -v flag to the command line above. This will run through the queue once. It will have to be run several times for all the deliverable messages to be delivered To just run the main queue do sendmail -q -v (or leave off the -v to not see output). Jim Stephen Ford wrote: Any suggestions for getting these messages out and running another sendmail to check this queue? ___ 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
