Solved Help with freebsd-ports@freebsd.org

I subscribed to freebsd-ports@freebsd.org and received a confirmation email with instruction:

Welcome to the freebsd-ports@freebsd.org mailing list!

To post to this list, send your message to:

freebsd-ports@freebsd.org

However, when I am trying to send an email I am getting an error:

Code:
  ----- Transcript of session follows -----
... while talking to mx1.freebsd.org.:
>>> DATA
<<< 450 4.7.1 <***.com>: Helo command rejected: Host not found
<freebsd-ports@freebsd.org>... Deferred: 450 4.7.1 <***.com>: Helo command rejected: Host not found
<<< 554 5.5.1 Error: no valid recipients
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
*** - edited

Where to go for help? Likely freebsd-ports-owner@freebsd.org won't work either...
 
Your mailhost doesn't appear to have proper DNS entries (both forward and reverse). To somewhat prevent spam it needs to be a valid hostname that's resolvable.
 
The email is sent from @gjunka.com host, which is the email host and which itself is resolvable. Why the mailhost itself needs public DNS entries? Mailhosts aren't usually public-facing servers. That's like exposing the internal network architecture to the outside world.
 
If you're using a smarthost system to send your emails the messages need to masqueraded to come from a publicly resolvable domain. There is a very strict requirement that any email message has a resolvable return address so that they can be bounced to sender in case of any errors, freebsd.org mail handling server is enforcing that requirement here so that it won't end up accepting messages that it can't bounce back or report errors to the sender.
 
The email is send from an email address and my understanding is that the host of that email address needs to be resolvable, no the mailhost itself. At least that's what all the on-line SMTP checking tools are verifying. I have not had a single problem with that for the last 2 years or so, only the freebsd.org server is rejecting emails.

I am not using a smarthost, I am configuring sendmail myself.

On the other hand sending emails with internal name of the host (not masqueraded) isn't much less public than adding a DNS alias for it, I guess. If only configuring sendmail wasn't that difficult...
 
The email is send from an email address and my understanding is that the host of that email address needs to be resolvable, no the mailhost itself. At least that's what all the on-line SMTP checking tools are verifying. I have not had a single problem with that for the last 2 years or so, only the freebsd.org server is rejecting emails.

The final mail server that delivers the email needs to be resolvable and also to provide all the proper headers.

The error message 450 4.7.1 <***.com>: Helo command rejected: Host not found means that HELO used a non resolvable host name.
 
What's exactly the "final mail server"? If you get the public IP of the server that delivered the email then it's resolvable. If you take the server name reported in the header by the mail server itself then it's not. But as I am configuring what is being put to that header I can put there anything, like gmail.com, and it will be resolvable. Will it start to work then?
 
What's exactly the "final mail server"? If you get the public IP of the server that delivered the email then it's resolvable. If you take the server name reported in the header by the mail server itself then it's not.

Let me put it to you differently, you might use a many relays as you want. However, the last hop needs to match the hostname with a valid IP.

But as I am configuring what is being put to that header I can put there anything, like gmail.com, and it will be resolvable. Will it start to work then?

That's a common spammer practice, I don't understand why you want to to that unless you want to blacklist your server eventually.
 
Since you're not using a smarthost set up (that would save you a lot of headaches by the way) you must have public DNS records for your own domain, specifically MX records for that domain, for the reasons already listed. You have been very lucky so far if your set up has worked for you but times are changing and mail handling hosts have become much stricter in what they accept.
 
Let me put it to you differently, you might use a many relays as you want. However, the last hop needs to match the hostname with a valid IP.

That's a common spammer practice, I don't understand why you want to to that unless you want to blacklist your server eventually.

OK, I see. Of course I don't want to do that. That was an example to better get my point across.

Since you're not using a smarthost set up (that would save you a lot of headaches by the way) you must have public DNS records for your own domain, specifically MX records for that domain, for the reasons already listed. You have been very lucky so far if your set up has worked for you but times are changing and mail handling hosts have become much stricter in what they accept.

I was looking into smarthost set up but I couldn't use because of some reason, I don't remember why now unfortunately. The MX record of my DNS entry points to the MTA, the emails are being sent out by the MSA. Those are two different hosts, albeit with the same public IP. They are different behind the firewall.

BTW I am not lucky, it's the FreeBSD server that is unnecessarily strict.
 
Can you show how the MX records for your domain and the A records for the mail handling hosts are set up. Blank out some of the actual numbers if you don't want to disclose them.
 
Since you're not using a smarthost set up (that would save you a lot of headaches by the way) you must have public DNS records for your own domain, specifically MX records for that domain, for the reasons already listed.
Although this is the recommended setup, an MX record is not strictly needed. If there is just an A record and the machine there accepts mail for that domain on port 25, this counts as valid. But the problem here is not the mail domain but this:
The error message 450 4.7.1 <***.com>: Helo command rejected: Host not found means that HELO used a non resolvable host name.
In HELO or EHLO, the client introduces itself to the server using its own hostname. This can be in an entirely different domain, of course. But the server is free to double-check this information with DNS, this of course helps to stop some spam. Most systems just ignore whatever the sender writes in HELO/EHLO. Still, checking it won't break a properly configured sender.
 
Code:
abcka.com. A 123.24.638.233 - - 14400
abcka.com. MX 0 abcka.com
mail.abcka.com. CNAME abcka.com

(domain and IP faked)

The MSA is on its own subdomain msa1.someserver.abcka.com and that's how it introduces itself to other SMTP servers. It works because I asked my ISPs to add my domain to the reverse DNS lookup. So when they receive SMTP from my server they do a reverse DNS lookup for the IP and they get the domain name that matches the DNS entry for the main host and for the host from the From field.

In HELO or EHLO, the client introduces itself to the server using its own hostname. This can be in an entirely different domain, of course. But the server is free to double-check this information with DNS, this of course helps to stop some spam. Most systems just ignore whatever the sender writes in HELO/EHLO. Still, checking it won't break a properly configured sender.

As I said, only FreeBSD rejects emails from my server among all the servers I had a chance to send emails to (including hotmail and gmail). I am not saying my server is properly configured, however this must be a common scenario in hosting companies where the actual mail server doesn't have it's own DNS entry.
 
As I said, only FreeBSD rejects emails from my server among all the servers I had a chance to send emails to (including hotmail and gmail). I am not saying my server is properly configured, however this must be a common scenario in hosting companies where the actual mail server doesn't have it's own DNS entry.
It's probably not common at all -- SMTP requires you to put the FQDN in HELO, so any sending MTA needs a DNS entry. The original intent was to allow the receiving MTA to write the "Received:" line without querying DNS. Back when spam wasn't heard of yet. The reason most sites don't reject mail for a wrong HELO is that this violates SMTP, too.

edit: it's actually not entirely clear because a correct "Received:" line contains the FQDN. So without a DNS entry and a "fake" HELO, the receiver has a little problem here.
 
Code:
4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)

   These commands are used to identify the SMTP client to the SMTP
   server.  [b]The argument field contains the fully-qualified domain name
   of the SMTP client if one is available.  In situations in which the
   SMTP client system does not have a meaningful domain name (e.g., when
   its address is dynamically allocated and no reverse mapping record is
   available), the client SHOULD send an address literal (see section
   4.1.3), optionally followed by information that will help to identify
   the client system.[/b]  y The SMTP server identifies itself to the SMTP
   client in the connection greeting reply and in the response to this
   command.
https://www.ietf.org/rfc/rfc2821.txt
 
The MSA is on its own subdomain msa1.someserver.abcka.com and that's how it introduces itself to other SMTP servers. It works because I asked my ISPs to add my domain to the reverse DNS lookup. So when they receive SMTP from my server they do a reverse DNS lookup for the IP and they get the domain name that matches the DNS entry for the main host and for the host from the From field

If you are sending only from msa1.someserver.abcka.com and you have proper DNS setup for that machine you should not have a problem. Just make sure that the HELO is msa1.someserver.abcka.com and add an SPF record for that host.
 
All right, I give up. I added an alias from msa1.someserver.abcka.com to abcka.com and now it works. I hope that no one interested in subscribing to the list have had or will have such a problem, otherwise the community might be already a bit smaller than it could have been because of some overreacting server :-) Thanks everyone for your help.
 
Back
Top