Conta de usuário preenchendo automaticamente com arquivo dead.letter

2

Eu tenho uma conta de usuário em um servidor com cerca de 400 contas que está sendo preenchida automaticamente. O arquivo dead.letter no diretório inicial dos usuários aumenta automaticamente até que a conta esteja cheia (cerca de 10 a 40 Mb por dia). O usuário está usando o Microsoft Outlook para enviar e receber mensagens.

O que pode estar causando isso e como posso evitar que isso aconteça?

Neste momento, eu tenho um cron-job de emergência para excluir o arquivo, mas gostaria de uma solução "real" .

Editar: a versão do servidor é Red Hat Enterprise Linux ES release 4 (Nahant Update 4)

Editar 2: Parece principalmente spam e eu vejo cabeçalhos de mailer diferentes (de php para o Outlook Express) e um cabeçalho de exibição frequente é [email protected]

Atualização: Eu pedi ao provedor de hospedagem onde eu uso esse servidor dedicado para analisar o problema também, já que é o Painel de Controle que pode ser uma causa do problema.

    
por jeroen 27.02.2012 / 23:40

3 respostas

3

Esse usuário tem uma árvore de conteúdo da web sendo atendida por um servidor web deste sistema?

Verifique sua árvore de conteúdo para um CGI ou algo que lide com envios GET / POST. Meu palpite é que eles têm algum software padrão da web instalado - uma ferramenta de layout de página, ou algo parecido com o WordPress. Algumas empresas de terceiros estão usando alguma falha de segurança nesse software da Web para tentar enviar emails desse sistema. Sua exploração não está funcionando corretamente, ou pelo menos nem sempre, e assim alguns / todos os e-mails de saída estão falhando; o agente de transporte de correio local está colocando o email no dead.letter do usuário.

Eu estou em desvantagem aqui ... mas é onde eu olharia primeiro.

    
por 28.02.2012 / 15:39
2

Aqui está um script que você pode executar contra o arquivo dead.letter e talvez pegar o processo de criá-lo.

#! /bin/bash

if [ $# -eq 0 ]; then
        echo "Syntax: $(basename $0) <file_to_watch>"
        exit 1
fi

FILE_TO_WATCH=$1
LOGFILE=/var/tmp/$(basename $0).$(date +"%Y-%m-%d").log
SLEEP_DELAY=5

if [ ! -e $LOGFILE ]; then
        echo -e "DATE                   COMMAND     PID      USER   FD      TYPE     DEVICE SIZE/OFF       NODE NAME" > $LOGFILE
fi

echo "Starting lsof tail job with PID $$"
echo "lsof output will be appended to $LOGFILE"

while true; do
        if [ -e $FILE_TO_WATCH ]; then
                lsof $FILE_TO_WATCH | sed 1d | sed -e "s/^/$(date +"%Y-%d-%m %H:%M:%S    ")/" >> $LOGFILE 2>/dev/null
                sleep $SLEEP_DELAY
        fi
done

Sinta-se à vontade para alterar as variáveis para tornar o atraso mais agressivo, por exemplo. Se você quiser lançá-lo como um trabalho em segundo plano, basta chamá-lo assim:

nohup script.sh /path/to/dead.letter &

O script fará eco ao PID que ele usa para sua conveniência, para que você possa eliminá-lo.

EDIT: Como por seu comentário, parece que o arquivo não é mantido aberto por um processo longo o suficiente para que você seja capaz de pegá-lo. Outra coisa que você pode tentar é definir o sinalizador imutável no arquivo dead.letter na esperança de que ele gere erros em / var / log / messages ou outro log. Arquivos imutáveis não podem ser alterados até mesmo pelo root.

Siga estas etapas:

# rm -f dead.letter
# touch dead.letter
# chattr +i dead.letter
# lsattr dead.letter
----i---------- dead.letter

Em seguida, tente tocá-lo novamente com raiz. Você vai ter isso:

touch: cannot touch 'dead.letter': Permission denied

Isso confirma que você fez tudo certo.

    
por 28.02.2012 / 03:28
1

Se bem me lembro, eu tive um caso em que isso foi causado por um script cron quebrado há muitos anos, então verifique os usuários crontab .

    
por 27.02.2012 / 23:51