Jacob Anawalt [EMAIL PROTECTED] 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.
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...
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?
> So none of the email is to bob+debian? Nice to know that Swen writer
> didn't try too hard. Maybe others won't and people who can should use +/-
> in their email address.
None of the Swen email (that I've noticed) But I'm using SpamAssassin
to kill Swen and not looking at the To address.
> > Only accepting email that comes from the list to the +debian address
> > wouldn't work because of people (like yourself) that reply to my mails.
>
> Hey! I thought I'd been very careful on this thread to only send directly
> to the list. I even double checked just now. :P
Well you might have replied privately. :P
> While I did get your cc'd reply faster than the one you sent to the list,
> I would have gotten the one from the list all the same, and your cc'd
> reply would have bounced with the error code I suggested in that other
> thread.
Check this swanky procmail rule:
# Maintain a msgid cache, and compare incoming mails to eliminate duplicate
# mails (from crossposted lists, usually), see 'man procmailex'
:0 Wh: msgid.lock
|formail -D 8192 msgid.cache
Cheers,
Bob McElrath [Univ. of California at Davis, Department of Physics]
"Knowledge will forever govern ignorance, and a people who mean to
be their own governors, must arm themselves with the power knowledge
gives. A popular government without popular information or the means
of acquiring it, is but a prologue to a farce or a tragedy or
perhaps both."
- James Madison
signature.asc
Description: Digital signature
