Sendmail kuyruğundaki e-posta iletilerini kalıcı olarak nasıl silerim ve geri gelmelerini nasıl önleyebilirim?


18

Burada oldukça can sıkıcı bir sorunum var. Bir uygulamayı test ediyorum ve sahte e-posta adreslerine bazı test e-postaları oluşturdum (sunucumun zaten e-posta göndermek için ayarlanmadığından bahsetmiyorum bile). Tabii ki, sendmailbu mesajları gönderemiyor ve sendmailsıraya takılıyorlar . sendmailGenellikle yeniden denemeyi durdurmak için 5 gün beklemek yerine kuyrukta biriken iletileri el ile silmek istiyorum .

Ubuntu 10.04 kullanıyorum ve /var/spool/mqueue/okuduğum her nasıl yapılırsa sıraya alınan e-postaların tutulduğunu söylüyor. Bu dizindeki dosyaları sildiğimde, sendmailbir cron betiği gibi görünene kadar e-postaları işlemeye çalışmayı durdurur ve bu dizini gönderilmesini istemediğim iletilerle yeniden doldurur. İşte bazı satırları syslog:

Jun  2 17:35:19 sajo-laptop sm-mta[9367]: o530SlbK009365: to=, ctladdr= (33/33), delay=00:06:27, xdelay=00:06:22, mailer=esmtp, pri=120418, relay=e.mx.mail.yahoo.com. [67.195.168.230], dsn=4.0.0, stat=Deferred: Connection timed out with e.mx.mail.yahoo.com.
Jun  2 17:35:48 sajo-laptop sm-mta[9149]: o4VHn3cw003597: to=, ctladdr= (33/33), delay=2+06:46:45, xdelay=00:34:12, mailer=esmtp, pri=3540649, relay=mx2.hotmail.com. [65.54.188.94], dsn=4.0.0, stat=Deferred: Connection timed out with mx2.hotmail.com.
Jun  2 17:39:02 sajo-laptop CRON[9510]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Jun  2 17:39:43 sajo-laptop sm-mta[9372]: o52LHK4s007585: to=, ctladdr= (33/33), delay=03:22:18, xdelay=00:06:28, mailer=esmtp, pri=1470404, relay=c.mx.mail.yahoo.com. [206.190.54.127], dsn=4.0.0, stat=Deferred: Connection timed out with c.mx.mail.yahoo.com.
Jun  2 17:39:50 sajo-laptop sm-mta[9149]: o51I8ieV004377: to=, ctladdr= (33/33), delay=1+06:31:06, xdelay=00:03:57, mailer=esmtp, pri=6601668, relay=alt4.gmail-smtp-in.l.google.com. [74.125.79.114], dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Jun  2 17:40:01 sajo-laptop CRON[9523]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)

Bu mesajlardan kalıcı olarak nasıl kurtulabileceğimi bilen var mı? Bir yan not olarak, sendmaile-posta gönderme "sahte" kurmak için bir yol olup olmadığını bilmek istiyorum . Var mı?


Bu soruna hala bir çözüm bulamadım. Kesinlikle bir tür cron betiği olmasına neden oluyor gibi görünüyor, ancak kuyruktaki mesajları nerede sakladığını anlayamıyorum ...
Steven Oxley

Yanıtlar:


28

Gönderilen veya gönderilmeye çalışılan mesajlar içinde saklanır /var/spool/mqueue. Sendmail'in sıraya koymayı denemediği iletiler bölümünde bulunabilir /var/spool/mqueue-client.

Bu yüzden bunu deneyin ( kuyruktaki tüm iletilerden kurtulmak istediğinizi varsayalım ):

  • Sendmail'i durdur
  • rm /var/spool/mqueue/*
  • Bekleyen mesajları kaldırmak istiyorsanız rm /var/spool/mqueue-client/*,.
  • Sendmail'i başlat

Bu, sistem başka bir ileti alana kadar kuyruk klasör (lerimizi) temizler. mailq(Her iki kuyruk klasörü) veya sendmail -bp(yalnızca kuyruk klasörü) çalıştırarak iki kez kontrol edebilirsiniz .

NOT: Çoğu Linux dağıtımında service sendmail <start|stop|restart>veya ile hizmetleri başlatabilir / durdurabilirsiniz /etc/init.d/sendmail <start|stop|restart>. Her iki seçenek de, durum bayrakları olmadan komut ve hizmete yazılarak gözlemlenebilen birçok durum işaretine sahiptir.


Bunu zaten yaptığını söyledi, ancak mesajlar yeniden ortaya çıktı ...
Massimo

1
Ama önce sendmail'i durdurmadan, mesele bu.
weeheavy

Görünüşe göre kaçırdığım adıma saldırmış olabilirsiniz.
Steven Oxley

Fedora 19'da / var / spool / clientmqueue (/ var / spool / mqueue gibi)
görüyorum

Nedense sudo ile bile bu benim için işe yaramaz (söyleyebilirim no matches found). Böylece chmodklasörleri düzenledim 777ve daha sonra içeriği silebiliyorum.
Sridhar Sarnobat

9

Sıklıkla örneğin rm /var/spool/mqueue/*veya daha kötüsü ( rm -rfvb.) Sendmail'in mqueue dizininden dosyaları kaldırma önerisini bulacaksınız . IMHO, bu çok tehlikeli. Birçok durumda işe yarayacaktır, ancak emniyet kemerlerinizi takmanızı tavsiye ederim. Tüm dosyaları mqueue'dan kaldırmak, geçerli mesajları silebilir.

Kuyruğa alınan iletileri kaldırmadan önce Sendmail'i durdurmak için özellikle çok sayıda iletinin kaldırılması gerekiyorsa iyi bir öneri olur. Ancak, yalnızca birkaç ileti kaldırılacaksa veya sıra düzenli olarak temizleniyorsa, örneğin bir cron işi aracılığıyla Sendmail'i durdurmaya gerek yoktur. En kötü durumda, mesajlardan biri yeniden kuyruğa girecek ve tekrar denediğinizde neredeyse kesinlikle kaldırılacaktır.

Aksine, Sendmail'i (örneğin, Ubuntu ile birlikte service sendmail stop) durdurmak yeterli olmayabilir. Durduğunda bile bazı (alt) işlemler hala çalışıyor olabilir. Biri bitene kadar (tavsiye edilen) veya onları öldürene kadar beklemek zorunda kalacak.

Mqueue'dan mesajları güvenli bir şekilde kaldırmak için mesajların kuyruk kimliklerine ihtiyacınız vardır. Kimlikler günlükte "sm-mta [...]:" ifadesinden sonra gösterilir. Eğer günlük alıntı gelen kimlikleri o530SlbK009365, o4VHn3cw003597... 2 dosya mqueue saklanır kimlikleri, her biri için bir "qf", "df" ile diğer başlangıç ile başlayan.

mailqgenellikle kuyruğun içeriğini listelemek için kullanılır. İlk sütundaki kimlikleri gösterir. Ayrıca, mailqbir iletinin etkin / şu anda işlenip işlenmediğini de gösterdiğinden çıktısına başvurmalısınız . Örneğin

-----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------
oBDDuKAB023946*    1058 Mon Dec 13 14:56 <vfn-l-bounces+so=example.com@fam.tuwi
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <so@example.com>
oBAEMuV8000429     1058 Fri Dec 10 15:22 <vfn-l-bounces+sby=example.com@fam.tuw
                 (Deferred: 450-4.2.1 The user you are trying to contact is re)
                                         <so@example.com>

Bu örnekte oBDDuKAB023946, ekli yıldız tarafından gösterilen kimliğe sahip mesaj şu anda işleniyor. Diğer iletilerin kaldırılması güvenlidir. Örneğin, kimliği oBAEMuV8000429kullanarak iletiyi kaldırmak için

rm /var/spool/mqueue/{d,q}foBAEMuV8000429

Sıradaki iletileri kaldırmak için daha çok yönlü bir yaklaşım, Brandon Hutchinson tarafından Postaları posta kuyruğundan silme konusunda sağlanır . Brandon ayrıca alan adı bölümü, e-posta adresi vb. Dayalı mesajları kaldırmak için komut dosyaları içerir. Brandon'ın komut dosyaları düzenli temizlik veya toplu kaldırma için çok yararlıdır.

Bununla birlikte, Brandon'ın senaryoları bile mesajların durumuyla ilgilenmiyor. Ancak, eklemek kolaydır. Senaryolarının başına dahil et

# Get current mailq status
my $mailq = `mailq`;

Ardından, alt rutin "aranıyor" un başında aktif mesajları atlamak için bir kontrol ekleyin, örn.

# skip if file is currently processed by MTA
if ($mailq =~ /\n$queue_id\*/) {
   $debug && print "$queue_id is locked.\n";
   last;
}

HTH. Ve yedeklemeler yapmayı unutmayın :-)


4

Ben de aynı sorunu vardı ve kuyruk mesajları ile 2 klasör bulundu. / Var / spool / clientmqueue / klasöründe / var / spool / mqueue / içinde teslim edilemedikleri mesajlar vardı. Sorunu çözmek için her iki klasörden dosyaların silinmesi gerekiyordu.

rm -f / var / biriktirme / clientmqueue / * rm -f / var / biriktirme / mqueue / *


0

Bunun bir cron betiğinin işi olduğunu düşünmüyorum, bir uygulama sorunu veya sendmail'in kendisiyle ilgili bir şey olması daha muhtemel; Her neyse, bunu yapan herhangi bir cron işini dışlamak crondiçin, bir süre durup bunun devam edip etmediğini görebilirsiniz.


0

Bunu bu bash betiğini kullanarak yapmayı başardım

for i in `sudo ls /var/spool/mqueue`
do
    sudo rm -rv `echo /var/spool/mqueue/$i`
done

Yani bir alt kabuk sadece çağırmak echove echoparametre olarak kullanmak için adı geçen çıktı almak için açın rm. Hatta nedensiz çatalları görmezden sudove rmbu subshelling düz savurgandır.
Felix Frank

Daha 'kabul edilebilir' bir çözümünüz varsa, bir yorumun ne kadar işe yaramaz olabileceğini göstermek yerine çözümünüzü açıklamak zaman kaybı olmaz. Şimdiden teşekkürler
Shu Hikari

2
Bu rahatsız edici ve kibirli bir durumla karşılaşırsa özür dilerim. Daha ekonomik bir yaklaşım olurdu sudo find /var/spool/mqueue -maxdepth 1 -delete. Özellikle senaryonuzda neyin sorunlu olduğuna dikkat çekmeyi önemli buldum . İncelik eksikliği için özür dileriz.
Felix Frank

2
Evet, ama şimdi açıkladın ve ben tamamen anladım. Ve özür kabul edildi, endişelenme. Teşekkürler: D
Shu Hikari
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.