Re: MS mail bombs
Bob McElrath said:
> Jacob Anawalt [jacob@cachevalley.com] wrote:
>>
>> Bob McElrath said:
>> > Darn, I was hoping (aren't we all) for a way to reject it before the
>> > whole thing is sent. You know...it wouldn't be hard to scan the input
>> > for the EXE header and close the connection as soon as it's seen.
>> Then
>> > you'd only download 1k or so rather than 150k...
>>
>> While you _could_ do that, and if you _knew_ the mail had been sent
>> directly from some Windowz end user system and not relayed through a
>> valid
>> server (I've noticed a couple of "we dropped the virus but sent you the
>> message anyway" swen messages in my inbox) then I guess that would be
>> just
>> fine, might as well throw up a firewall rule to block their next
>> attempts
>> or have your mail server send 550 reject at the next connection.
>>
>> If it's a real server, I thought that it would just try the connection
>> again because it didn't get a yes 250 or a no 5xx or even a maybe later
>> 3-4xx, and you might not want to firewall or reject all email from a
>> mailserver just because one of their users is infected.
>
> Well Swen sends mail directly, no? Does it retry? As you said you
> could send a 550 on the second connection from that server.
>
> Also I discovered the MaxMessageSize option for sendmail...which
> generates a 550. But I'm weary of using it for all the people that
> might complain after trying to send me their 10MB postscript paper.
I don't know if it retries on a dropped connection. I could watch the logs
closer to see if it retries on a 550. I sure hope it isn't :( I need to be
catching and firewalling or immediatly 5xx'ing on HELO to these senders
after the first try if they are retrying.
I had thought that Swen mailed directly, but now I believe that it will
relay when it cannot do direct mailing - based on the number of "Notice,
this email had Swen but we were cool and removed it. We suck though
because even though it _was_ a virus sent email, we sent it to you anyway!
Thank-you for reading how cool we are. Have a nice day!" emails I've been
getting. Even worse would be if they were also sending a message to the
likely forged "From" address. Sure they drop the exe and advertise how
dumb they are, but they also turn one email into two, neither of which
reach the user of the infected system.
weary - wary?
I guess you could tell them 'If you want to mail big stuff, do it from on
campus' or 'upload it to here'. If you haven't had a file size issue, then
I guess it's not an issue for you. I have a 1 or 2 MB limit on this
address. It isn't smaller for similar reasons.
>
> The whole idea being to reduce the bandwidth eaten by copying virii
> around...
>
>> Anyone, please correct me if I'm wrong here. Doesn't protocol dictate
>> that
>> if I accept HELO, MAIL FROM and RCPT TO that I'm suppose to accept the
>> whole of DATA before I can say 'not ok'. Wouldn't a "connection reset by
>> peer" just cause the sending server (if it wasn't a dumb virus smtp
>> session) to resend later?
>
> If only we could see the MIME envelope before as part of the SMTP
> negotiation...
Ya, if only. We need a new mail transport protocol. :) Instead of email
it's email2 (like internet2) if your ISP uses e2 to send mail it gets
there faster (or falls back to email) because it uses some trust metric
like GPG, oppertunistic ipsec and states upfront what type of data it is
transporting. Mail admins decide who they trust, and that mail comes in
_unscanned_ lickety split. Someone becomes a problem, they get untrusted
and have to use normal email who's scanning duties are shuffled off to an
old 386 running NT for maximum slowness!
"Where's my email from Bob? Bob@<someopenrelay.com>? They allow spam so
it's going through the New Technology Technology server. Should be
processed in a day or so."
>
> Well there was that idea a while ago of exponential falloff -- when you
> recognize a virus just don't send TCP ACK's (or, send them but double
> the time between ACK's between each packet). This way you not only stop
> the virus but also tie up a TCP connection for a long time on the
> sender's side. But the mail would still get delivered. What ever
> happened to that idea?
Teergrubing is still out there. The writeup I read was about having the
mailserver delay not your ip stack. A good idea that I have yet to
implement.
[snip]
>
> Check this swanky procmail rule:
>
[snip]
Thanks for the rule! :)
--
Jacob
Trying out SquirrelMail
Reply to: