Làm cách nào để xóa vĩnh viễn các tin nhắn e-mail trong hàng đợi sendmail và giữ chúng không quay trở lại?


18

Tôi có một vấn đề khá khó chịu ở đây. Tôi đã thử nghiệm một ứng dụng và đã tạo một số e-mail thử nghiệm đến các địa chỉ e-mail không có thật (chưa kể rằng máy chủ của tôi không thực sự được thiết lập để gửi e-mail). Tất nhiên, sendmailkhông thể gửi những tin nhắn này và chúng đã bị kẹt trong sendmailhàng đợi. Tôi muốn xóa thủ công các tin nhắn đã được xây dựng trong hàng đợi thay vì chờ 5 ngày sendmailthường phải dừng thử lại.

Tôi đang sử dụng Ubuntu 10.04 và /var/spool/mqueue/là thư mục mà mọi cách tôi đã đọc nói rằng các e-mail được xếp hàng được giữ lại. Khi tôi xóa các tệp trong thư mục này, sendmaildừng cố gắng xử lý e-mail cho đến khi tập lệnh cron chạy và nhập lại thư mục này với các tin nhắn tôi không muốn gửi. Dưới đây là một số dòng từ của tôi 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)

Có ai biết làm thế nào tôi có thể thoát khỏi những tin nhắn này vĩnh viễn? Là một lưu ý phụ, tôi cũng muốn biết liệu có cách nào để thiết lập sendmailđể gửi e-mail "giả" hay không. Lanhung?


Chà, tôi vẫn chưa tìm được giải pháp nào cho vấn đề này. Nó chắc chắn trông giống như một loại kịch bản cron nào đó đang xảy ra, nhưng tôi không thể tìm ra nơi nó đang lưu trữ các tin nhắn được xếp hàng ...
Steven Oxley

Câu trả lời:


28

Các tin nhắn đã được gửi hoặc đang cố gắng gửi được lưu trữ trong /var/spool/mqueue. Tin nhắn mà Sendmail chưa thử xếp hàng có thể được tìm thấy trong /var/spool/mqueue-client.

Vì vậy, hãy thử điều này (tôi giả sử bạn muốn loại bỏ tất cả các tin nhắn trong hàng đợi):

  • Dừng gửi thư
  • rm /var/spool/mqueue/*
  • Nếu bạn muốn xóa tin nhắn trong chờ đợi rm /var/spool/mqueue-client/*.
  • Bắt đầu gửi thư

Điều này sẽ xóa (các) thư mục hàng đợi của bạn cho đến khi hệ thống nhận được một tin nhắn khác. Bạn có thể kiểm tra lại bằng cách chạy mailq(cả hai thư mục hàng đợi) hoặc sendmail -bp(chỉ thư mục hàng đợi).

LƯU Ý: Với hầu hết các bản phân phối Linux, bạn có thể bắt đầu / dừng dịch vụ bằng service sendmail <start|stop|restart>hoặc /etc/init.d/sendmail <start|stop|restart>. Cả hai tùy chọn đều có nhiều cờ trạng thái khác có thể được quan sát bằng cách nhập lệnh và dịch vụ mà không có cờ trạng thái.


Anh ta nói rằng anh ta đã làm điều này, nhưng tin nhắn lại xuất hiện ...
Massimo

1
Nhưng không dừng lại gửi mail trước, đó là điểm chính.
trăng mật

Chà, có vẻ như bạn có thể đã bước vào bước mà tôi đã bỏ lỡ.
Steven Oxley

Trên Fedora 19, tôi thấy / var / spool / clientmqueue (cũng như / var / spool / mqueue)
TomG

Vì một số lý do ngay cả với sudo, điều này sẽ không hiệu quả với tôi (nó sẽ nói no matches found). Vì vậy, tôi chmoded các thư mục đến 777và sau đó có thể xóa nội dung.
Sridhar Sarnobat

9

Bạn thường sẽ tìm thấy đề xuất để xóa các tệp khỏi thư mục mqueue của Sendmail chẳng hạn rm /var/spool/mqueue/*hoặc tệ hơn ( rm -rfv.v.). IMHO, đây là nguy hiểm rõ ràng. Nó sẽ hoạt động trong nhiều trường hợp nhưng tôi khuyên bạn nên thắt dây an toàn. Chỉ cần xóa tất cả các tệp khỏi mqueue có thể xóa các tin nhắn hợp pháp.

Để dừng Sendmail trước khi xóa tin nhắn xếp hàng là lời khuyên tốt đặc biệt là nếu cần xóa nhiều tin nhắn. Tuy nhiên, nếu chỉ xóa một vài tin nhắn hoặc nếu hàng đợi được dọn sạch một cách thường xuyên, ví dụ như bằng một công việc định kỳ thì thực sự không cần phải dừng Sendmail. Trong trường hợp xấu nhất, một trong những tin nhắn sẽ được xếp hàng lại, gần như chắc chắn sẽ bị xóa khi bạn thử lại.

Ngược lại, dừng Sendmail (ví dụ trong Ubuntu với service sendmail stop) có thể không đủ. Ngay cả khi dừng một số quy trình (con) vẫn có thể chạy. Người ta sẽ phải đợi cho đến khi họ hoàn thành (được khuyến nghị) hoặc giết chúng.

Để xóa tin nhắn khỏi mqueue một cách an toàn, bạn cần ID hàng đợi của tin nhắn. ID được hiển thị trong nhật ký sau "sm-mta [...]:". ID từ đoạn trích nhật ký của bạn là o530SlbK009365, o4VHn3cw003597... Đối với mỗi tệp ID 2 được lưu trữ trong mqueue, một tệp bắt đầu bằng "qf", tệp kia bắt đầu bằng "df".

mailqthường được sử dụng để liệt kê nội dung của hàng đợi. Nó hiển thị ID trong cột đầu tiên. Hơn nữa, bạn nên tham khảo mailqđầu ra của nó bởi vì nó cũng cho biết liệu một tin nhắn đang hoạt động / hiện đang được xử lý. Ví dụ

-----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>

Trong ví dụ này, thông báo có ID oBDDuKAB023946hiện đang được xử lý, được hiển thị bằng dấu hoa thị được nối thêm. Các tin nhắn khác là an toàn để được gỡ bỏ. Ví dụ: để xóa tin nhắn có oBAEMuV8000429sử dụng ID

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

Một cách tiếp cận linh hoạt hơn để xóa thư xếp hàng được Brandon Hutchinson cung cấp trong Xóa thư khỏi hàng đợi thư . Brandon cũng bao gồm các tập lệnh để xóa tin nhắn dựa trên phần tên miền, địa chỉ email, v.v. Các tập lệnh của Brandon rất hữu ích để dọn dẹp thường xuyên hoặc xóa hàng loạt.

Tuy nhiên, ngay cả các tập lệnh của Brandon cũng không quan tâm đến trạng thái của tin nhắn. Tuy nhiên, thật dễ dàng để thêm. Bao gồm ở phần đầu kịch bản của anh ấy

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

Sau đó, khi bắt đầu thói quen phụ "muốn" thêm một kiểm tra để bỏ qua các tin nhắn đang hoạt động, ví dụ như với

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

HTH. Và, hãy nhớ tạo bản sao lưu :-)


4

Tôi gặp vấn đề tương tự và thấy rằng có 2 thư mục với các tin nhắn xếp hàng. Thư mục / var / spool / clientmqueue / có các tin nhắn kết thúc bằng / var / spool / mqueue / nếu chúng không được gửi. Xóa các tập tin từ cả hai thư mục là cần thiết để giải quyết vấn đề.

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


0

Tôi không nghĩ rằng đây là công việc của một tập lệnh cron, nó có nhiều khả năng là một vấn đề ứng dụng hoặc một cái gì đó liên quan đến chính sendmail; dù sao, để loại trừ bất kỳ công việc định kỳ nào làm việc này, bạn chỉ cần dừng lại crondmột lúc và xem điều này có tiếp tục xảy ra không.


0

Tôi quản lý để làm điều này bằng cách sử dụng tập lệnh bash này

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

Vì vậy, bạn mở một subshell chỉ để gọi echovà lấy đầu ra đã nói echođể sử dụng làm tham số rm. Ngay cả việc bỏ qua các dĩa vô cớ sudorm, việc chia nhỏ này là lãng phí.
Felix Frank

Chà, nếu bạn có một giải pháp 'chấp nhận được' hơn, sẽ không lãng phí thời gian để giải thích giải pháp của bạn thay vì chỉ cho thấy một nhận xét có thể vô dụng như thế nào. Cảm ơn trước
Shu Hikari

2
Xin lỗi nếu điều này đi qua gây khó chịu và kiêu ngạo. Một cách tiếp cận kinh tế hơn sẽ là sudo find /var/spool/mqueue -maxdepth 1 -delete. Tôi đã thấy điều quan trọng là chỉ ra những gì có vấn đề với kịch bản của bạn nói riêng. Xin lỗi vì sự thiếu khéo léo.
Felix Frank

2
Đúng, nhưng bây giờ bạn đã giải thích quan điểm của bạn và tôi hoàn toàn hiểu nó. Và lời xin lỗi được chấp nhận, đừng lo lắng. Cảm ơn: D
Shu Hikari
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.