Why RFC's arent always right.....

Forum for things that doesn't really have anything to do with hMailServer. Such as php.ini, beer, etc etc.
Post Reply
User avatar
jimimaseye
Moderator
Moderator
Posts: 8295
Joined: 2011-09-08 17:48

Why RFC's arent always right.....

Post by jimimaseye » 2016-12-16 20:59

RFC5321 says that smtp banners should advertise the FQDN host name of the mail server for SMTP. Personally I choose not to do this. And the following is a perfect example as why I choose not to do this:
"SMTPD" 5032 17608 "2016-12-12 17:31:24.003" "80.82.78.92" "SENT: 220 Northcote SMTP"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.034" "80.82.78.92" "RECEIVED: EHLO User"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.034" "80.82.78.92" "SENT: 250-mycompany.com[nl]250-SIZE 26214000[nl]250-AUTH LOGIN[nl]250 HELP"
"SMTPD" 3352 17608 "2016-12-12 17:31:24.081" "80.82.78.92" "RECEIVED: AUTH LOGIN"
"SMTPD" 3352 17608 "2016-12-12 17:31:24.081" "80.82.78.92" "SENT: 334 VXNlcm5hbWU6"
"SMTPD" 4376 17608 "2016-12-12 17:31:24.112" "80.82.78.92" "RECEIVED: dGVzdEBOb3J0aGNvdGU="
"SMTPD" 4376 17608 "2016-12-12 17:31:24.112" "80.82.78.92" "SENT: 334 UGFzc3dvcmQ6"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.143" "80.82.78.92" "RECEIVED: ***"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.174" "80.82.78.92" "SENT: 535 Authentication failed. Too many invalid logon attempts."
For those of you wondering:

"RECEIVED: dGVzdEBOb3J0aGNvdGU=" means they tried logging in as "test@Northcote" where "Northcote" was extracted from my banner "Northcote SMTP".

Now, imagine I had actually written my host domain name as RFC's recommend (ie, mycompany.com). They would have been 1 step closer to getting an exact match to guessing a user account.

I keep my system like this purely because of the risk shown above (its extra security) and I have never experienced problems for doing so.

Just saying.
5.7 on test.
SpamassassinForWindows 3.4.0 spamd service
AV: Clamwin + Clamd service + sanesecurity defs : https://www.hmailserver.com/forum/viewtopic.php?f=21&t=26829

User avatar
SorenR
Senior user
Senior user
Posts: 3315
Joined: 2006-08-21 15:38
Location: Denmark

Re: Why RFC's arent always right.....

Post by SorenR » 2016-12-16 23:43

jimimaseye wrote:RFC5321 says that smtp banners should advertise the FQDN host name of the mail server for SMTP. Personally I choose not to do this. And the following is a perfect example as why I choose not to do this:
"SMTPD" 5032 17608 "2016-12-12 17:31:24.003" "80.82.78.92" "SENT: 220 Northcote SMTP"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.034" "80.82.78.92" "RECEIVED: EHLO User"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.034" "80.82.78.92" "SENT: 250-mycompany.com[nl]250-SIZE 26214000[nl]250-AUTH LOGIN[nl]250 HELP"
"SMTPD" 3352 17608 "2016-12-12 17:31:24.081" "80.82.78.92" "RECEIVED: AUTH LOGIN"
"SMTPD" 3352 17608 "2016-12-12 17:31:24.081" "80.82.78.92" "SENT: 334 VXNlcm5hbWU6"
"SMTPD" 4376 17608 "2016-12-12 17:31:24.112" "80.82.78.92" "RECEIVED: dGVzdEBOb3J0aGNvdGU="
"SMTPD" 4376 17608 "2016-12-12 17:31:24.112" "80.82.78.92" "SENT: 334 UGFzc3dvcmQ6"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.143" "80.82.78.92" "RECEIVED: ***"
"SMTPD" 3416 17608 "2016-12-12 17:31:24.174" "80.82.78.92" "SENT: 535 Authentication failed. Too many invalid logon attempts."
For those of you wondering:

"RECEIVED: dGVzdEBOb3J0aGNvdGU=" means they tried logging in as "test@Northcote" where "Northcote" was extracted from my banner "Northcote SMTP".

Now, imagine I had actually written my host domain name as RFC's recommend (ie, mycompany.com). They would have been 1 step closer to getting an exact match to guessing a user account.

I keep my system like this purely because of the risk shown above (its extra security) and I have never experienced problems for doing so.

Just saying.
The RFC's say your server should be FCrDNS compliant, they don't say you should host the same maildomain as your hostdomain... :wink:

"EHLO User" is a known robot, why do you allow it to progress that far ??

Code: Select all

   Function Lookup(strRegEx, strMatch)
      With CreateObject("VBScript.RegExp")
         .IgnoreCase = True
         .Global = False
         .Pattern = strRegEx
         If .Test(strMatch) Then
            Lookup = True
         Else
            Lookup = False
         End If
      End With
   End Function

   Sub OnHELO(oClient)

      ' Local LAN ...
      If (Left(oClient.IPAddress, 10) = "192.168.0.") Then Exit Sub
      Dim strRegEx
      If (oClient.Port = 25) Then

         ' AUTH LOGIN Disabled on port 25, only allow FQDN's - no IP's of any kind
         ' WHY ? - Because I can ;-)
         strRegEx = "^(?=^.{1,254}$)(^(?:(?!\.|-)([a-z0-9\-\*]{1,63}|([a-z0-9\-]{1,62}[a-z0-9]))\.)+(?:[a-z]{2,})$)$"
      Else

         ' Oops.. mobile phones, iPhone in particular only send IP address as hostname in EHLO string!
         strRegEx = "^\[(?:[0-9]{1,3}\.){3}[0-9]{1,3}\]$|" &_
                    "^(?=^.{1,254}$)(^(?:(?!\.|-)([a-z0-9\-\*]{1,63}|([a-z0-9\-]{1,62}[a-z0-9]))\.)+(?:[a-z]{2,})$)$"
      End If
      If Not Lookup(strRegEx, oClient.HELO) Or InStr(oClient.HELO, "127.0.0.1") Then
         Result.Value = 2
         Result.Message = "5.7.1 Your access to this mail system has been rejected due to the " &_
                          "sending MTA's poor reputation. If you believe that this failure is " &_
                          "in error, please contact the intended recipient via alternate means."
         Exit Sub
      End If
   End Sub
SørenR.

“With age comes wisdom, but sometimes age comes alone.”
- Oscar Wilde

tunis
Normal user
Normal user
Posts: 237
Joined: 2015-01-05 20:22
Location: Sweden

Re: Why RFC's arent always right.....

Post by tunis » 2016-12-19 12:34

I have using "Make my day, punk!" since I setup my hmailserver 2009.
HMS 5.6.8 B2494.24 on Windows Server 2019 Core VM.
HMS 5.6.8 B2494.24 on Windows Server 2016 Core VM.
HMS 5.6.7 B2425.16 on Windows Server 2012 R2 Core VM.

User avatar
Dravion
Senior user
Senior user
Posts: 1611
Joined: 2015-09-26 11:50
Location: Germany
Contact:

Re: Why RFC's arent always right.....

Post by Dravion » 2016-12-20 04:27

Its a dangerous business tying to hide secret infos within a System which is not designef to keep data private. But neverthelesd you could use Email-Adresses like contact / support / service @ domain.com

One of te best countermeasures is something like rpz where you can filter and reject incomning DNS requests from rogue hosts / dns zones like the russian business networkIf you enable it you can knock out entire dns rogue zones of attacking zombie hosts / bots even if they try to randomnize shit because you block everything on DNS Layer before the SMTP Server is even comes into play.

User avatar
ras07
Normal user
Normal user
Posts: 227
Joined: 2010-03-11 08:51

Re: Why RFC's arent always right.....

Post by ras07 » 2016-12-20 05:32

jimimaseye wrote:RFC5321 says that smtp banners should advertise the FQDN host name ...
The words "must", "should", "may", etc. have very specific meanings in RFC language. Per RFC 2119 :

Code: Select all

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
In other words, you are free to ignore this advice as long as you're sure you know what your'e doing (which in your case, I'm sure you do).

In short, you can rest easy tonight that you are completely RFC5321 compliant.

ras

User avatar
Dravion
Senior user
Senior user
Posts: 1611
Joined: 2015-09-26 11:50
Location: Germany
Contact:

Re: Why RFC's arent always right.....

Post by Dravion » 2016-12-20 05:38

ras07 wrote: In short, you can rest easy tonight that you are completely RFC5321 compliant.
ras
You can sleep whithout worry allnight long, because RFC's only matters to Programmers,
programming a new SMTP-Server compliant to a RFC. Its up to you how you run the Server
on your Site.

User avatar
ras07
Normal user
Normal user
Posts: 227
Joined: 2010-03-11 08:51

Re: Why RFC's arent always right.....

Post by ras07 » 2016-12-20 06:01

Dravion wrote:RFC's only matters to Programmers
Well, I wouldn't go quite that far ... I'd imagine that many, if not most, "RFC compliant" services give users enough rope to hang themselves with in terms of configuring in a non-RFC compliant manner, if the user so chooses. Doing so is at your own risk, of course; it may or may not cause problems when communicating with other "RFC compliant" servers. This is the whole point of RFCs.

In this case, declining to specify your FQDN in your SMTP welcome banner is completely within RFC specs. "Should" <> "Must"; therefore, if an incoming SMTP server refuses to communicate with you just because your welcome message does not include your FQDN, they are the one who is non-RFC-compliant, not you.

ras

User avatar
Dravion
Senior user
Senior user
Posts: 1611
Joined: 2015-09-26 11:50
Location: Germany
Contact:

Re: Why RFC's arent always right.....

Post by Dravion » 2016-12-20 06:48

All true, but you can run in error situations with other widely used SMTP MTA's like Postfix

Quote:
Postfix 2.2.x (3.1.3 is released since October 2016) uses reject_non_fqdn_hostname and reject_invalid_hostname, respectively.

There are also other settings like this which can be a showstopper:
# /etc/postfix/main.cf
# HELO restrictions:
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit
http://www.postfix.org/postconf.5.html

The same goes for Exim4, which is another big player in the MTA Segment.
Exim4 has the "helo_verify" param which evaluates HELO/EHLO commands as part
of a antispam measurement see: http://www.exim.org/exim-html-3.20/doc/ ... ec_45.html

And even on good old Sendmail knows the trick:
H?${BadHELO}?X-bad-HELO-cmd: Host name in HELO/EHLO did not have any dots
C{persistentMacros} {BadHELO}
Microsoft Exchange also can be configured to reject non HELO/EHLO compliant connection
attempts: see: https://technet.microsoft.com/en-us/lib ... 98294.aspx (Helo/Fqdn)


If activated, this will surely knockout any incoming connections on the HELO/EHLO sequence.

Ref: Marketshare of most used SMTP MTA's
mxsurveyplot.jpg

Post Reply