Slackware.com Majordomo lists
 

Does anybody know who looks after the Majordomo list server, and for that case the mail server, of Slackware.com? I'm trying to change my subscription address for the slackware-announce and slackware-security lists. I was able to unsubscribe from my old address fine, but trying to mail majordomo@slackware.com from a new mail system I've just setup on my own domain (mvtech.ca), I never receive any response back from Majordomo, not even from a "help" command. I'm guessing that my mail is being rejected for some reason, even though I see from my sendmail logs that it is being delivered successfully, and I am able from my server to send and receive mail to other sites fine, including GMail and Hotmail. I was able to get Majordomo to send me a confirmation email to the new address when I sent a subscribe command from another address, but then was unable respond to that email to complete the confirmation. This makes me suspect that slackware.com's mail server thinks my mail is spam and is rejecting it for some reason.

Check your server's outgoing mail for any filtering of spam mail being sent, and make sure you have the protocols for sending outgoing mail configured in the firewall, if you run one.

No outbound spam filtering being done, only inbound, and per /var/log/maillog, I can see that the mail is being accepted on slackware.com fine. It's what happens after it gets there that I'm wondering about.

I guess maybe it has to do something for the mx to be on a dial-up connection (and the reverse address not resolving properly)
I think you will have problems because of this also with other mailservers

That's what I was thinking, but that shouldn't be a reason for a mail server to reject mail, should it? This is not an abnormal situation for anyone owning their own domain and setting up a SOHO network. As long as there is a PTR record for the IP address, it shouldn't matter if the name matches or not, as long as the PTR record returned when looked up gives the matching IP address, which it does in my case.

I can't ask Teksavvy (my ISP) to change the PTR record to my domain's name, because they own it, not me. Besides, even if they did change it, that would solve the mail problem, but there are other A records that use the same address (other virtual servers on my network), so what about them?

Just for fun, I decided to write Teksavvy's support site to see if they could supply me with a static IP and change the PTR record in their DNS, and this is the reply I received:

"Thank you for this inquiry. We are sorry to have to inform you that we do not have static IP's for our Cable internet customers. We only offer these to our DSL customers. Again sorry that we could not help you."

So if this is the reason my mail is being rejected at Slackware.com, and possibly other sites, the only other solution for me is to send my mail via another mail server or service, or configure sendmail to use a "'Smart' relay host"... but then what's the point of setting up your own mail server? :-(

This is normal - many ISPs don't permit their customers to even send outbound on tcp/25 (apart from through their own relays). Most spam detection systems apportion negative points to mail sent from IP's on consumer IP space since a lot of spam originates from compromised windows machines.
slackware.com's mail is filtered through the anti spam service in place at the ISP in which our web server lives. This is most likely what is eating your mail.

Why not just rent a small VPS and set up your mail server on that? The small ones are usually really cheap. I have a single core VPS with 4GB of RAM and 200GB disk space, costs only 12€ a month and is just fine for a mail server (also used for some other things).

True enough... I know because I am the postmaster at the university where I work, and do this on our mail system.

Adding a few points to a spam score for mail sent from a mail server that has DNS incorrectly configured (or in my case not able to be configured correctly) is fine, and I believe the anti-spam system that I maintain at work does this as well, but a message should not be outright rejected solely because of this... IMHO anyways.

Thank you for that information. I have opened up a support ticket with them to see if this is indeed the reason my mail is being rejected.

I also did some Googling and understand that AOL.com also supposedly does this. Just to test, I did a telnet to port 25 of one of their mail servers, and got this:
Now, does this mean that if a PTR record exists but doesn't match the corresponding A record, the mail is accepted? Must be, because it did accept the connection from my IP address. I think this behavior is acceptable.

Have you looked into Dynamic DNS?

It's not the same as having a static IP but it can help when DHCP fails you, and you need a constant addressing scheme.

http://www.dmoz.org/Computers/Intern...s/Dynamic_DNS/

Dynamic DNS won't be of help in this case, because no matter what DNS provider I choose, if someone decides to do a PTR lookup on my IP address, it will always return the value assigned by the owner of the IP address' DNS server. In my case, it will check Teksavvy's DNS servers, and return the PTR value from there, even though I purchased my domain from and use the DNS services of Hover.com.

But it shouldn't eat mail silently, that's a bad practice. It should reject them at the SMTP stage, because DUL detection/blacklisting can go wrong.

For sending mail you need a static IP address, because every serious mail provider blacklists dynamic IP ranges for good reasons. For receiving mail Dynamic DNS should be enough, though it's not very reliable and I wouldn't recommend it. And behind a CGNAT you're basically screwed.

Long-term solution: Get yourself a IPv6 tunnel. They are free (tunnelbroker.he.net) and provide static addresses including DNS mappings. Although you won't reach @slackware.com this way, because their mail server still lives in the past. ;)

Living in the past... that sounds like me! I still boot my Linux server with a floppy disk because the SCSI hard disk and controller I use doesn't support booting! And I compile my kernels with "make config" and answer each question Y, N, or M! What is this IPv6 you speak of? :D

(In case anybody is wondering, the above is a joke. Although, when I first started using Slackware back in 1994, the above was true.)

BTW, I did get a very quick response from Slackware.com's ISP Succeed.net confirming that yes they are rejecting my mail based solely on the PTR record, but when I asked them why they have this policy, they weren't so quick in responding back... we'll see if they actually do.

Do they reject them with a 55x error code or do they accept (code 2xx) and then silently delete them? Because the latter is not correct RFC-conform behavior. Transport errors must be reported back to the sending SMTP.