[Dshield] Delayed Attachment Delivery?
wolfgang at sweet-haven.com
Sat Feb 28 16:43:07 GMT 2004
I certainly agree about the users. But placing your
security posture into the hands of thousands of
users, however well trained, is classic "security
I was thinking about a process that would unpack
all attachments, then determine actual filetypes.
Double-extent filenames would be rejected right away,
as would filetypes on a "reject" policy list. All
others with executable content would be sent to the
delay-queue. Then, zipped files would be unpacked
and if found to contain executables would also be placed
in the delayed-delivery queue. From what we've seen
this week, a three-hour delay would probably suffice
if signatures are updated on a one-hour schedule.
Then, the delayed messages would be sent through the
rest of the delivery process, including the virus
We don't want to implement a blanket deny policy
for zipped attachments due to the nature of our workload.
We currently use MailScanner, SpamAssassian and a
major-brand virus checker with sendmail. MailScanner
already uses a two-queue process; it might be fairly
easy to implement a third delay queue.
Johannes B. Ullrich wrote:
>>Zipped executables would be the candidates for delayed delivery.
>>Does anyone have any thoughts or recommendations?
> sounds like a good idea (however,it would be better to teach your
> users not to click :-(). I think its techincally doable, bu delivering
> the mail to a queue instead of the end user and delivering the
> mail from the queue using a cron job.
> It will be difficult to pick the right time delay. It can easily take
> 6 hours for signatures to come out. Are your users willing to
> wait that long?
More information about the list