Spoofed sender domain not logged in System messages?

[kgoodknecht]

Should spoofed sender domain be logged on the System messages tab?
IIRC they were logged in one of the earlier builds, I'm now using build 1005 and I noticed thay are not logged. Is this designed behavior?
Is there any way to make them show on the System Messages tab?

[adrien]

Hi

We only introduced this feature in WinGate 6.0, by which time I had arrived at the conclusion that the system messages tab was not a great place to be logging these sorts of things, so the short answer, is no, we have never sent these particular messages to the system messages window.

We have plans for a replacement for the system messages with an alarm panel, which will have a counter against triggered alarms. This will make the whole system message thing a lot more manageable, since on our server for instance, we get thousands of these per hour.

Adrien

[kgoodknecht]

Hi

We only introduced this feature in WinGate 6.0, by which time I had arrived at the conclusion that the system messages tab was not a great place to be logging these sorts of things, so the short answer, is no, we have never sent these particular messages to the system messages window.

We have plans for a replacement for the system messages with an alarm panel, which will have a counter against triggered alarms. This will make the whole system message thing a lot more manageable, since on our server for instance, we get thousands of these per hour.

Adrien

It is better than having to dig through the service logs, hopefully you do have something better in the works. But I found my mail server was rejecting mail from important senders because they don't have their MX records set up right. I would have liked to have had a visible alert of these. I have added that domain to the no check list but I have lost quite a few emails from them.

Just to add, does this option only check MX records or does it also check SPF records?

[adrien]

OK, I see the problem.

It checks MX, and PTR->A record for verified reverse name lookups to compare against MX servers etc.

So it is kinda like SPF, but doesn't require the domain to have an SPF TXT record.

Just waiting for SPF to settle down, then will probably put it in, since we are doing most of the work already anyway.

Adrien

[kgoodknecht]

OK, I see the problem.

Adrien

So does that mean you're going to make it easier to see the rejected mail due to spoofed sender domain?

In addition, I think the format for SPF is pretty much nailed down, many domains have published SPF, including qbik.com, dnsreport.com has added SPF checking. It would be nice if mail server's would actully check SPF and reject on failure of either SPF or PTR/MX lookup.

[adrien]

We will make it easier, since eventually it will have a dedicated alarm, which shows instances of being triggered (so you can see all the spoof attempts in one place).

You can also see these in the history, and they flicker up in the activity panel as well (not that useful but I have seen many that way).

As for SPF, it would be in there already if only they hadn't put in redirects and includes.... makes for some potential vulnerabilities. Most people don't use these though, so we could start with a partial implementation that would cover 99.9% of domains I guess (i.e. just MX, A, and PTR).

Adrien

[kgoodknecht]

We will make it easier, since eventually it will have a dedicated alarm, which shows instances of being triggered (so you can see all the spoof attempts in one place).

You can also see these in the history, and they flicker up in the activity panel as well (not that useful but I have seen many that way).

As for SPF, it would be in there already if only they hadn't put in redirects and includes.... makes for some potential vulnerabilities. Most people don't use these though, so we could start with a partial implementation that would cover 99.9% of domains I guess (i.e. just MX, A, and PTR).

Adrien

Excellent, I want to add, just checking the MX records has reduced the incoming spam by several hundred a day on just one mail server. I plan on upgrading two more to v6 in the next thirty days just to add this feature.

[adrien]

Yeah, we basically developed this system on our live mail server to see what it did, and ended up with a hybrid approach.

We do about 3 checks with this "anti-spoofing" check, since just MX is not fine enough.

1. We do an MX lookup. If there is no MX record, we verify a few things about the IP / name itself. If no A record, it is an invalid domain.

Any DNS failure is deemed inconclusive.

So, once we have the MX records, we check that none of them resolve to bogus IP addresses (like localhost, or any local IP of the WinGate machine), and that the names aren't obviously bogus such as "dev.null" or "localhost". these are deemed poisoned MX records, and are treated harshly.

Next step. We check to see if the IP of the client is in the same class C subnet as any MX resolved IP. If so, then good.

Else, we do a PTR lookup, followed by an A record lookup. If there is no PTR record, we fail at this point. This is the usual cause for manual whitelist entries.

If the A record lookup on the result of the PTR lookup doesn't match we also fail.

If they match (usual case surprisingly), then we do a lexical comparison of the validated name associated with the IP (result of the PTR) with

a) the domain being delivered for
b) the names of all the MX servers for the domain.

to one significant token in the name. Significant being things other than .com, .edu, country codes, etc etc.

b) catches the case where an ISP receives mail (is MX) for a domain, yet the client of the ISP delivers directly.

this combination we found had the smallest number of false rejections, but we still had to add manual entries where:

1. The IP of the client had no reverse DNS.
2. The client had no MX for their mail

This is why we offered 2 modes of operation in the end (initial betas of this were all "check all except...") . So now on our own server, we add commonly spoofed domains to the list of things to check, rather than adding commonly blocked domains to the list of things not to check.

However, the former more brutal method certainly we found to be very effective. I guess if we had been less lazy about false positives, we could be running it that way. It is a bit tough when you need to take sales email from all over.

One improvement that has been suggested is to allow the deferral of the check until after the RCPT command, and allow certain recipient email addresses to be whitelisted. This would allow all mail into sales@wingate.com for example, but be more conservative for other addresses. This is planned for upcoming.

Adrien

[labull]

Please allow me to add my $.02USD.

Between the Open Relay Detetction and the Block spoofed sender-address we block over 1500 pieces of junk each day.

This results in significant cost savings to my company and sure makes me look good in the eyes of my boss!

False positives are minimal. After an initial flurry of activity when these measures were first implemented, we now add just one or two entries to the allow list per week.

And with the future enhancements Adrien mentions above, he and Qbik once again demonstrate their commitment listening to the customer and providing a highly configurable solution to their Internet connection needs.

Nobody does it better!


Larry

[kgoodknecht]

Please allow me to add my $.02USD.

Between the Open Relay Detetction and the Block spoofed sender-address we block over 1500 pieces of junk each day.

This results in significant cost savings to my company and sure makes me look good in the eyes of my boss!

False positives are minimal. After an initial flurry of activity when these measures were first implemented, we now add just one or two entries to the allow list per week.

And with the future enhancements Adrien mentions above, he and Qbik once again demonstrate their commitment listening to the customer and providing a highly configurable solution to their Internet connection needs.

Nobody does it better!


Larry

I agree 100%, Things have gotten a lot better since Qbik to Wingate, I've used Wingate since an ealy version 3.
I do beleive that adding support for SPF can reduce the false positives. I've found that some legitimate mail domains use mail servers for delivery that don't have an MX record for the mail domain. The one I had trouble with didn't have an MX record but they did have an SPF record. SPF is beginning to take hold and is getting more wide spread.
One thing I have noticed big time, when my mail server sends an NDR due to someone trying to guess legitimate mail boxes I'm getting a lot fewer NDRs.

[adrien]

aw shucks guys!

I agree about the SPF, mainly because it is a lot more deterministic. We have the DNS resolver to do it with.

[kgoodknecht]

aw shucks guys!

I agree about the SPF, mainly because it is a lot more deterministic. We have the DNS resolver to do it with.

Well good, does that mean we might see SPF support?
And an easier way to see the spoofed sender domain rejects?

[adrien]

definitely both of those... just a matter of when....

Adrien