In my experience what works best is to:
1) Not have your real MX record as one of the first 2
2) Not have your real MX record as the last one
A lot of companies foolishly have their mail systems configured so the
high priority servers are with message labs or other spam filtering
services, but keep their own relay as the lowest priority one "just on
case". Spammers figured this out so some of them go straight for the
lowest priority MX.
On 10/12/2014 02:45 AM, Robert Moskowitz wrote:
Well I am kind of back for Holiday (middle days now), and just checked
my logwatch from my current mail server; no real change in number of
spams processed.
I implemented nolisting wednesday by making mx,10 point to
medon.htt-consult.com which has iptables blocking port 25. mx,20 is my
mailserver, klovia.htt-consult.com. By now I might think the change has
propagated, but I am still at ~70%. Either:
I did it wrong.
These guys now process MX records.
I never really got this class of spam, or not much of it.
On 10/08/2014 03:22 PM, Gordan Bobic wrote:
On 10/08/2014 08:12 PM, R P Herrold wrote:
On Wed, 8 Oct 2014, Gordan Bobic wrote:
On a somewhat tangentially related note, do you really
need to use spamassassin? I find I solved most of my
spam problems by:
1) Nolisting
Downside - you need multiple IPs.
ehh? just assign an A record for the closest handy RFC 1918.
Perfectly legal, and indeed sensible and functional if the
next more distant actually CAN reach the closest, such as by
it being a backside network interface. Hard to get much
closer than that
As I think it through, one could even ** alias ** an RFC 1918
IP on top of the interface of the next more distant outside
interface if there is not a backside, and kill two birds with
one rock (the seeming second closest 'knows' it is also the at
the IP of final destination unit) It 'should' know that, but
adding that A record to the list of hostnames for which that
unit knows it receives, may be needed
That's dangerous and may result in mail being completely undeliverable
as well as leave it open to malicious redirection.
For example, of the sending mail server has two subnets, one of which
is RFC 1918, it will try sending to the IP in the primary MX record.
If you are unlucky and the server is a mail server, it will respond
with a permanent failure and the mail will bounce straight back on the
sending side without ever attempting being delivered to the recipient
using nolisting.
To make it work properly and reliably, you need proper valid IPs you
control. You cannot rely on every possible sender to not be sending
from a network where the RFC 1918 you configure won't be a mail server.
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
