Điểm:0

kiểm tra những quá trình kết nối với cổng bên ngoài

lá cờ au

Tôi đang điều hành một máy chủ email cho một tổ chức xã hội của trường học và chúng tôi cung cấp dịch vụ chuyển tiếp email cho các sinh viên đã tốt nghiệp, cung cấp cho họ một bí danh email trong tên miền của chúng tôi, chẳng hạn như [email protected] và chúng tôi chuyển tiếp email đến địa chỉ cá nhân được chỉ định của họ đã đăng ký với chúng tôi .

Gần đây, chúng tôi đã nâng cấp từ một máy chủ email rất cũ mà phiên bản TLS mới hơn không còn được hỗ trợ nữa và đã chuyển sang cấu hình kiểm tra ubuntu20 postfix + spamassassin + perl spf. Sau khi thiết lập, chúng tôi nhận thấy rằng IP này có tiếng xấu là gửi email rác. Tôi đã kiểm tra lại postfix main.cf và postfix này không hoạt động như rơle mở.

smtpd_sender_restrictions =
    allow_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain
smtpd_relay_restrictions =
    allow_mynetworks,
    permit_sasl_authenticated,
    defer_unauth_destination

việc tra cứu khối lượng email hơi đáng lo ngại vì một số trang web dường như ghi lại IP của tôi gửi 1 trong số 30 triệu email trên thế giới vào một số ngày

https://talosintelligence.com/reputation_center/lookup

lịch sử email email uy tín

tất nhiên tôi không nghĩ họ cài máy chủ của tôi để kiểm tra tôi nên tôi không biết dữ liệu của họ đến từ đâu

Tôi đang nghĩ đến việc kiểm tra xem có chương trình nào khác có thể đang gửi email trên máy chủ của tôi không

Tôi đã thiết lập ufw để cho phép cổng đích 25 xuất ra khi đăng nhập

trạng thái #sudo ufw
Đến hành động từ
-- ------ ----
25 CHO PHÉP NGOÀI Ở Mọi nơi (nhật ký)

Tôi thấy khoảng 6000 mục đã hết trong 60 giờ qua trong ufw.log của grep "DPT=25 ", điều này có vẻ hợp lý đối với tôi vì chúng tôi có số lượng thành viên theo thứ tự là 1000.

cũng đã kiểm tra mail.log, số dòng cần gửi (250 ok, 550*, 454*) thêm vào khoảng 3000 dòng.

Và tôi cũng đã thấy nhiều lần postfix cố gắng gửi một số thông báo không gửi được nhưng kết nối bị hết thời gian chờ hoặc bị từ chối. Kể từ đó, tôi đã tăng thời gian dự phòng tối thiểu và tối đa, đồng thời giảm thời gian tồn tại của hàng đợi để cố gắng giảm khối lượng thử lại của một số email spam mà chúng tôi nhận được ở các bí danh.

Tôi cũng nhận được thư trả lại từ gmail chẳng hạn và một số máy chủ smtp khác

status=bounced (host gmail-smtp-in.l.google.com[74.125.130.26] said: 550-5.7.26 Thư này không có thông tin xác thực hoặc 550-5.7.26 không vượt qua kiểm tra xác thực. Để bảo vệ tốt nhất người dùng của chúng tôi, tin nhắn đã bị chặn
status=bounced (host gmail-smtp-in.l.google.com[74.125.130.26] said: 550-5.7.1 [MY IP] Hệ thống của chúng tôi đã phát hiện ra rằng thư này có khả năng là 550-5.7.1 là thư không mong muốn. Đến giảm lượng thư rác gửi đến Gmail, thư này đã bị chặn
status=bounced (host gmail-smtp-in.l.google.com[74.125.130.26] said: 550-5.7.1 [MY IP] Hệ thống của chúng tôi đã phát hiện ra rằng thư này là 550-5.7.1 có khả năng đáng ngờ do địa chỉ IP gửi 550-5.7.1 có uy tín rất thấp. Để bảo vệ tốt nhất người dùng của chúng tôi khỏi thư rác, thư đã bị chặn 550-5.7.1.
status=deferred (máy chủ imsmx1.netvigator.com[219.76.94.45] từ chối nói chuyện với tôi: 554-wironin01.netvigator.com 554 Bị từ chối: Spam email từ máy chủ IP <MY IP> bị chặn bởi Talos Vui lòng truy cập "https: //www.talosintelligence.com/reputation_center/lookup?search=MY IP"
status=deferred (kết nối với mail.feed-silver.cam[89.144.62.60]:25: Kết nối bị từ chối)
(thông báo không gửi được của người gửi) status=bounced (host aspmx.l.google.com[142.251.12.26] said: 550-5.1.1 Tài khoản email mà bạn cố truy cập không tồn tại. Vui lòng thử 550-5.1.1 kiểm tra kỹ địa chỉ email của người nhận để tìm lỗi chính tả hoặc khoảng trắng 550-5.1.1 không cần thiết.
  1. Tôi có nên lo lắng về bất kỳ quy trình nào khác đang gửi email trên máy chủ của mình làm ảnh hưởng đến danh tiếng email của tôi không? đó là lý do tại sao tôi ước mình có thể kiểm tra từ nhật ký ufw xem quy trình nào đã cố tạo kết nối với cổng 25 bên ngoài
  2. dữ liệu trang web danh tiếng email có đáng tin cậy không? Ý tôi là, tôi không chắc liệu email tập 2+ có đáng lo ngại hay không, nhưng netvigator với tư cách là một ISP kiểm tra nó mang lại mức độ tin cậy hợp lý.
  3. cho hiệp hội của chúng tôi cung cấp dịch vụ chuyển tiếp email. Chúng ta có nên loại bỏ hoàn toàn các email có điểm thư rác cao hay chỉ đơn giản sử dụng phương pháp mặc định của spamassassin để thêm [SPAM] vào chủ đề và để người nhận cuối cùng quyết định việc xử lý? thẩm quyền giải quyết: https://support.google.com/a/answer/175365?hl=vi
  4. chúng tôi có chuyển tiếp thư rác email rác uy tín của IP gửi của chúng tôi không?
  5. chúng ta có nên chuyển tiếp thông báo không gửi được của người gửi cho người gửi không? Mặc dù đôi khi tôi đọc trong nhật ký thư thì có vẻ bị lỗi ngay, nghi ngờ họ giả mạo tiêu đề email.
  6. có IP nào tương đương SPF với tên miền không? hoặc là nó hoàn toàn không thể do chuyển tiếp email.
  7. việc thiết lập dkim có giúp danh tiếng của IP của tôi không? chúng tôi có một lượng nhỏ email được gửi qua miền riêng của chúng tôi.
lá cờ cn
Bob
Nói chung, vấn đề với việc cung cấp dịch vụ chuyển tiếp là trừ khi bạn thực hiện quá trình lọc khá nghiêm ngặt, bạn cũng sẽ chuyển tiếp tất cả thư rác mà mọi người nhận được. Và máy chủ của bạn sẽ thường xuyên hơn không được coi là nguồn gốc của thư rác đó đối với bất kỳ bộ lọc thư rác nào đang chạy trên đích mà bạn chuyển tiếp thư đến. Đó là điều không thể tránh khỏi AFAIK.
lá cờ cn
Bob
Vì vậy, trừ khi bạn ngừng chuyển tiếp thư rác, nếu không danh tiếng của bạn sẽ không được cải thiện.Gửi thư bị trả lại là điều bạn muốn tránh, tán xạ ngược là một vấn đề khác mà người chuyển tiếp thường phải chịu trách nhiệm (xem ví dụ https://willem.com/blog/2019-09-10_fight-backscatter-spam-at-server-level/)
Điểm:0
lá cờ cm
  1. Có và không. Bạn nên lo lắng; tìm ra nguyên nhân thực sự. Nhưng thủ phạm có thể không phải là máy chủ thư. Nó cũng có thể là một thiết bị giả mạo trong mạng chia sẻ IP hiển thị công khai. Nhưng vì chúng tôi không biết cấu trúc liên kết mạng của bạn hoàn toàn là suy đoán.
  2. Vâng, họ có uy tín. IP được sử dụng càng lâu (đối với ham và thư rác) thì phân tích càng đáng tin cậy. Các gai lớn bất thường như được hiển thị là đáng lo ngại và cần điều tra kỹ lưỡng nguyên nhân.
  3. Không cờ (và sau đó chuyển tiếp), cũng không thả. Nó phải bị từ chối trước khi chấp nhận thư. Điều này được gọi là lọc trước hàng đợi.
  4. Hoàn toàn đồng ý. Nhưng vấn đề của bạn ngay bây giờ là một cái gì đó khác nhau. Hacking, spam-bot, account-breach, relay-attack, virus, ...
  5. NDN phải được gửi lại cho người gửi ban đầu. Nhưng trước tiên hãy thực hiện 3). Ngoài ra, hãy theo dõi NDN để xem địa chỉ chuyển tiếp của bạn có còn tồn tại hay không. Một số người dùng đóng tài khoản của họ và không thông báo cho bạn rằng chuyển tiếp sẽ không bao giờ hoạt động kể từ đó hoặc phải đến một địa chỉ khác thay thế.
  6. Tôi không hiểu cái đó. SPF dựa vào tên miền để phân loại IP gửi. Hay ý bạn là DNSRBL? Chúng cũng nên là một phần trong các biện pháp chống thư rác của bạn 3).
  7. Có, nhưng để chuyển tiếp thư thì nó không thực sự hữu ích. Nó giúp cho các thư có nguồn gốc từ phía bạn. Nhưng danh tiếng bị mất bởi nguyên nhân bùng phát thư rác thực sự.

Vì vậy, trước tiên hãy tìm ra thủ phạm và loại bỏ nó.Sau đó, áp dụng các kỹ thuật chống thư rác để giảm thiểu việc chấp nhận thư rác và do đó chuyển tiếp thư rác. Làm như vậy bằng cách từ chối thư đến; lọc không tốt, trừ khi bạn thực hiện lọc trước hàng đợi trong hộp thoại SMTP.

Sau khi làm điều đó, hãy tự hỏi bản thân xem chuyển tiếp thư có phải là cách nên làm hay không. Tất cả ứng dụng thư khách có thể xử lý nhiều tài khoản, vì vậy hãy tự lưu trữ thư.

lá cờ au
cảm ơn @mailq, vì vậy 1, tôi đang cố gắng tìm cách ghi nhật ký bất kỳ nỗ lực nào để kết nối với cổng 25 bên ngoài, tôi muốn biết liệu có bất kỳ quy trình nào khác ngoại trừ hậu tố đang "gửi" email đi hay không. nó không phải là máy chủ dùng chung, chúng tôi là người dùng duy nhất của IP đó 2. lý do tôi đặt câu hỏi về độ tin cậy của nó là vì máy chủ gửi email khá nhiều mỗi ngày nhưng vào những ngày, họ đăng nhập 0 khối lượng. 8. trường khá có uy tín, chúng tôi đang cung cấp cho các thành viên một địa chỉ email với tên miền uy tín như một dịch vụ, chúng tôi không sẵn sàng quản lý các hộp thư, vì vậy có vẻ như dịch vụ chuyển tiếp bí danh là dịch vụ duy nhất chúng tôi có thể cung cấp.
lá cờ au
cảm ơn bạn một lần nữa @mailq, sẽ nhận lời khuyên của bạn và điều chỉnh thêm máy chủ
lá cờ au
cho 3. máy lọc spamassassin đã được triển khai được một tuần rồi
lá cờ cm
Đối với tôi "đáng tin cậy" không có nghĩa là "chính xác".Chúng không thể chính xác vì chúng chỉ giám sát lưu lượng thư một cách gián tiếp. Chỉ bước nhảy mạng tiếp theo của bạn mới có thể chính xác về các con số (nếu chúng đo được). Đối với thang logarit trong hình: Tôi có thông tin chi tiết về một dự án tương tự với quy mô giống hệt nhau và người gửi lớn nhất thế giới là Google xếp hạng 7 (trên mỗi IP).
lá cờ au
Có, tôi hiểu rằng họ phải sử dụng phương pháp lấy mẫu. Tuy nhiên, đối với tôi, điều đó cũng có nghĩa là tôi sẽ mong đợi có thể chênh lệch gấp 10 lần (giả sử nó có thể bị tắt bởi nhật ký 1) trong ước tính khối lượng để xem liệu IP của tôi có thực sự là thư rác hay không và dường như không có nhiều dấu hiệu cho thấy mức độ thư rác như thế nào được tính toán và nó liên quan như thế nào đến khối lượng email, điều mà tôi không chắc chắn về cách đánh giá độ tin cậy của nó. Tôi có thể phải đối xử với mọi thứ ceteris paribus và chỉ tìm kiếm những thay đổi xu hướng

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.