Re: [exim] DoS attack with nested MIME levels

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Mark Nipper
Fecha:  
A: Michael Haardt
Cc: exim-users
Asunto: Re: [exim] DoS attack with nested MIME levels
On 14 Jul 2005, Michael Haardt wrote:
> out of the blue, I am getting a bunch of mails with a very deep MIME
> nesting and an "email-info.scr" file inside. Our mailer rejects them,
> but it takes forever and a day to scan it. The whole thing looks like
> a mail loop, because the sending MTA encapsulates the message together
> with the 550 error message from our MTA into a new mail and tries again
> (that's why the nesting gets so deep). Were this a single host, I'd
> block it. But I see that from hosts all over the world.
>
> Any idea what that crap is?


    I'd also be very interested in feedback on this issue as
I've had the exact same situation crop up just recently.  In my
case, I know exactly where the message is coming from though.  I
have a user forwarding mail from another Unix machine via a
.forward file and most of his mail comes through okay.  However,
lately, the remote side has been trying to forward a phishing
message of some type which was accepted on the remote side but is
being rejected with a 5xx level error message on my side because
clamav is detecting it as phishing trash.  This results in an
error message which the remote side encapsulates in one
additional layer of MIME, and then tries to attempt delivery
again to my end!


    As far as I've read, the remote end is in error here and
should have stopped attempting delivery after the first 5xx level
error message resulting in an undeliverable message or some such
frozen in the remote SMTP queue.  But unfortunately, that isn't
happening.


    So yeah, I've been toying with the idea of just blocking
this host from here on out, but I can see this being a larger
problem for other administrators if they are seeing this type of
junk from multiple remote sites.  Even blocking the message due
to some maximum number of MIME parts doesn't seem like it would
help in my case at least since it would just generate more
bounced messages the remote side would try to redeliver.  It
seems like an acceptance and trashing of the message would be the
only way around it.


-- 
Mark Nipper                                                e-contacts:
4475 Carter Creek Parkway                           nipsy@???
Apartment 724                               http://nipsy.bitgnome.net/
Bryan, Texas, 77802-4481           AIM/Yahoo: texasnipsy ICQ: 66971617
(979)575-3193                                      MSN: nipsy@???


-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GG/IT d- s++:+ a- C++$ UBL++++$ P--->+++ L+++$ !E---
W++(--) N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--)
Y+ PGP t+ 5 X R tv b+++@ DI+(++) D+ G e h r++ y+(**)
------END GEEK CODE BLOCK------

---begin random quote of the moment---
'Whenever a politician starts talking about "the children,"
keep one eye on your wallet and the other on your liberty.'
-- anonymous
----end random quote of the moment----