>> Every other solution out there has this one little problem that people >> seem to >> ignore. >> >> Per RFC, if you accept the connection and the mail, you will deliver it. >> That's what it says. It also says this since days long before spam >> problems, >> but still. We all conveniently ignore this if we are talking about what >> *we* >> consider spam, and by "we" I mean "everyone who cares to take an interest >> except the actual recipient". >> >> ... Yet we accepted the mail implying that we will deliver it... > > I don't think it's necessary to break RFC if you reject based on a bogus > HELO. The connection is initiated, but you do not get as far as accepting > the mail. > >> Instantly, 85% of the problem goes >> away, and I have numbers to prove it. > > 85% of the problem goes away if you use Spamhaus, and that doesn't require > you to discard legitimate email. > >> And why is a user on a DSL range running a mail server anyway? > > Personally, from my own point of view, it's so that I can see clearly that a > message has been delivered. > > EG: > > Sep 1 18:42:22 compaq postfix/smtp[6121]: A66A2137D25: > to=<x...@yahoo.co.uk>, relay=mx1.mail.eu.yahoo.com[217.12.11.64], delay=2, > status=sent (250 ok dirdel) > > I get complaints ALL the time from my customers, "oh, my brother / mother / > customer / supplier says they sent me an email and I never received it". The > only way I can debug this is to send them test messages (sometimes daily) > and tell them to let me know if they don't arrive. > > If a customer comes to you with a log entry that looks like the above, > referring to your server's hostname & IP, complaining the message was never > delivered, then you can, reluctantly, look in the problem, grepping for > A66A2137D25. > > If the customer comes to you with a log entry like the above with > relay=smtp.my-isp.com then your response will be "oh, we probably never got > the message from your ISP". I presumably can log a support issue with my ISP > & expect them to come up with the log of the message being delivered to your > servers, but it's simply easier if I can debug non-deliveries myself. > >> The vast >> overwhelming majority of them are Windows zombies! > > Which are easily filtered by checking their HELO resolves to an independent > domain. Or am I missing something here? > > The remainder of those you're inefficiently filtering are Linux enthusiasts > running Postfix on their Gentoo boxes.
Yeah, I was planning on setting up postfix on my home Gentoo box too. I guess I could relay through my ISP to avoid delivery problems like this. Why hasn't greylisting been mentioned? I greylist and it ends up blocking at least 99% of spam in my experience. - Grant >> And finally, my mail servers are mine and I make decisions about them, not >> someone else. > > Sure, but you're making unilateral decisions about the validity of emails on > behalf of your customers. And around here the customer comes first. > > If Bob wants to send Alice an email, he shouldn't have to reconfigure his > email server because Fred, the systems administrator at Alice's ISP, is > being a knob about things. > > You may be the exception, having a narrow pipe and being unable to afford > the Spamhaus / DNS lookups to filter spambots in efficient ways. Most > systems administrators using this policy are unable to justify the decision. > >> Best policy is to stipulate in the ISP's terms of service that you will >> not >> accept inbound mail connections from range you feel you cannot trust and >> users >> must use their ISPs mail relay instead. > > You certainly won't get me subscribing to your service. > > Stroller.
