ANN: ORF 5.4.1 Beta R02 RSS

1

We just have released the second beta of ORF 5.4.1. The new release fixes the R01 issue with Before Arrival filtering being broken under Exchange 2016/2013 Edge Transport Servers. Get the new beta from:

https://vamsoft.com/beta/

by Péter Karsai (Vamsoft) 1 year ago
2

Hi Peter,
running this without Problems so far.

Regards
Norbert

by NorbertFe 1 year ago
3

@NorbertFe: Thank you!

by Péter Karsai (Vamsoft) 1 year ago
(in reply to this post)

4

https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xml
defines specific status codes (instead of generic 5.7.1) for various rejects and the references to the respective RFCs are supplied:

5.7.27 No MX record and/or MX/A/CNAME records
5.7.25 No Reverse DNS

by Andy Schmidt 1 year ago
5

Before Arrival Actions, editing Response to "HELO blacklist", change the text, click OK. Will always revert back to default text. The other 4 above in that list work.

by Andy Schmidt 1 year ago
6

@Andy Schmidt: Hello Andy,

Thank you for bringing our attention to the above issues. Please give us a few days to investigate these as we are currently understaffed due to the holidays. We will get back to you as soon as possible.

by Daniel Novak (Vamsoft) 1 year ago
(in reply to this post)

7

@Andy Schmidt: Hello Andy,

Thank you, I confirm that this a bug. The fix will be available in the next regular release in mid-January 2017. This is a persistency bug, so if you feel confident editing the ORF configuration file orfent.ini, you can work the issue around by that.

by Péter Karsai (Vamsoft) 1 year ago
(in reply to this post)

8

@Andy Schmidt: Thank you, Andy.

We have adopted 5.7.25 as the new default for reverse DNS PTR action as per RFC7372 3.3. Although the test described by this RFC is more complete than the one ORF uses (we merely check for the existence of PTR, instead of an SPF "ptr"-style validation), a reasonable argument can be made for the test to fail lacking PTR to begin with.

The 5.7.27 enhanced code appears to be specifically reserved for the NULL MX proposal (RFC7505), which quite different from what ORF does. In my opinion, using this code would be misleading due to the different check carried out.

The change will ship with ORF 5.4.1.

by Péter Karsai (Vamsoft) 1 year ago
(in reply to this post)

9

@Péter Karsai (Vamsoft): Uh - yes. 5.7.27 is indeed specific to NULL MX.

Which of course, would raise the follow-up question, whether ORF will (for policy testing purposes only) treat a "." MX equivalent to that domain having *NEITHER* an MX nor an A.

The point of a null MX to signal senders to NOT to even attempt the "A" record (because it's no SMTP host) in absence of an "MX" record - effectively instructing senders to act as if NEITHER record existed.

by andy.schmidt 1 year ago
(in reply to this post)

10

@andy.schmidt: Hello Andy,

As of version 5.4.1, the Reverse DNS test of ORF checks whether an MX (or A) record exists for the tested domain, but it does not evaluate the content of the MX record. This means, a domain with a null "." MX record would pass the test, since it has a published MX RR.

A null MX record check is something that we will definitely consider adding in a future release. Thank you for bringing our attention to this.

by Daniel Novak (Vamsoft) 1 year ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

Nickname:
Email address (will not be published):
Your comment:

ORF Technical Support

Configuring, installing and troubleshooting ORF.

News & Announcements

Your dose of ORF-related news and announcements.

Everything but ORF

Discuss Exchange and system administration with fellow admins.

Feature Test Program

Feature Test Program discussion. Membership is required to visit this forum.

ORF Beta

Join the great bug hunt of the latest test release.

Customer Service

Stay Informed