Postfix: Bản đồ vận chuyển thông qua máy chủ chuyển tiếp của bên thứ ba


1

Tôi có trang web và email của tôi được lưu trữ với một máy chủ được chia sẻ. Thật không may, máy chủ của họ đang sử dụng CPanel, vì vậy họ bị hạn chế trong các tùy chọn chống spam.

Tôi cũng có một VPS mà tôi sử dụng để thử nghiệm và lưu trữ một số bit và phần khác (Tại sao tôi không sử dụng VPS cho các trang web? Tôi không muốn phải lo lắng về các bản sao lưu!) - Tôi có thể sử dụng nó như là MX cho các miền của tôi, với máy chủ được chia sẻ dưới dạng bản đồ vận chuyển - Tôi đã từng chạy phần mềm riêng của mình và do đó, các mô đun Puppet đã sẵn sàng để sử dụng máy chủ thư.

Máy chủ VPS yêu cầu tôi sử dụng chuyển tiếp thư Postfix để đảm bảo tôi không spam từ phạm vi IP của họ.

Tôi có thể sử dụng các chỉ thị transport_mapsrelay_hostchỉ thị của Postfix cùng nhau để chuyển MX của tôi tất cả thư cho tên miền của tôi đến máy chủ được chia sẻ, nhưng thông qua chuyển tiếp của máy chủ VPS không?

Một ví dụ nữa về kết quả mong muốn của tôi:

  • example.com có một bản ghi MX (cho sự tỉnh táo) của vps.example.com
  • vps.example.comnhận thư đến, sau đó tư vấn transport_mapsvà chuyển tiếp đến đích cuối cùng sharedhost.example.com, sử dụng rơle relayvps.example.netlàm "bước nhảy tiếp theo"

Điều đó có thể nhưng sẽ khá xấu xí nếu bạn hỏi tôi.
lsmooth

Vâng tôi đã tập hợp rằng nó sẽ không đẹp, nó đã là một tình huống không lý tưởng để bắt đầu! Tôi đã hỏi về khả năng bỏ qua chuyển tiếp của máy chủ VPS, nhưng tôi không hy vọng. Bạn có thể thêm một số chi tiết trong một câu trả lời về cách nó có thể?
Craig Watson

Đến đó, bạn yêu cầu nó;)
lsmooth

@Ismooth: Tôi đồng ý.
peterh

@lsmooth - cảm ơn, tôi đã nghĩ rằng đó sẽ là lựa chọn duy nhất, cảm ơn vì đã xác nhận.
Craig Watson

Câu trả lời:


2

Cá nhân tôi sẽ không muốn làm điều này. Nhưng bạn có thể sử dụng địa chỉ chuyển tiếp trên VPS của mình như thế này:

a@example.org -> a@subdomain.example.org
b@example.org -> b@subdomain.example.org
...

Sau đó định cấu hình máy chủ được chia sẻ của bạn dưới dạng MX cho tên miền phụ.example.org. Sau đó sử dụngtransport_maps

transport_maps = hash:/etc/postfix/transport

trong /etc/postfix/transportđặt

@subdomain.example.org smtp:[vps.relay.tld]

sử dụng postmapđể cập nhật bảng tra cứu trong Transport.db với postmap /etc/postfix/transport.

Nếu bạn cần thông tin đăng nhập cho rơle, bạn có thể định cấu hình chúng trong /etc/postfix/saslpass

vps.relay.tld username:password

và sử dụng postmap /etc/postfix/saslpassđể tạo / cập nhật bảng tra cứu.

Trên máy chủ được chia sẻ, thêm tên miền phụ và chuyển tiếp thư trở lại địa chỉ ban đầu. Mặc dù vậy, tôi không chắc chắn nếu chuyển tiếp sẽ không phá vỡ tính năng chống spam trên VPS.


-1

Có, nhưng bạn cần một chút kịch bản ở cả hai bên.

Nếu không có kịch bản, bạn không thể thực hiện việc này, nếu có thể thực hiện được thì đó là một lỗ hổng bảo mật nghiêm trọng (các thư điện tử có thể được gửi trực tiếp đến các máy chủ nội bộ phía sau tường lửa).

Giải pháp kịch bản đơn giản nhất là nếu bạn đóng gói thư để gửi vào thư khác dưới dạng tệp đính kèm và gửi đến mục tiêu. Trên mục tiêu, nó được chờ đợi bởi .procmailrc hoặc tương tự, trích xuất tệp đính kèm và đưa nó vào hàng đợi thư đi của mục tiêu. Tôi đã làm cả hai bên trong perl.


Tôi không chắc bạn có hiểu câu hỏi của tôi không - về cơ bản tôi muốn nói với MTA của tôi "gửi tin nhắn đến các tên miền này đến đích này, nhưng thông qua chuyển tiếp này". Tôi hiểu rằng rơle sẽ tra cứu MX cho đích và cuối cùng sẽ gửi thư trở lại máy chủ gốc.
Craig Watson

Tôi cũng tranh cãi rằng đó là một lỗ hổng bảo mật. Bất kỳ quản trị viên mailserver (tốt) nào cũng sẽ hạn chế quyền truy cập vào tên miền của chính họ và sẽ biết rõ hơn là phạm tội cuối cùng khi chạy rơle mở. Tôi không phiền khi sử dụng rơle trung gian nếu đó là một phần của cơ sở hạ tầng của nhà cung cấp dịch vụ của tôi. Gửi thư đến các máy chủ nội bộ phía sau tường lửa thực sự sẽ tương đối hữu ích (một MTA để lọc thư rác / vi rút trên đường vào và một cụm máy chủ hộp thư) miễn là MTA xâm nhập được cấu hình để phản hồi chính xác.
Craig Watson
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.