Scalix Forums

Hello,

we just installed a new server with scalix 11.0.1, so far it looks good.

I just stumbled over the smtpd.cfg file, where I find these entries:


# NB Authenticated RELAYs are always allowed
RELAY accept 127.0.0.1
RELAY accept .mydomain.ch
RELAY Log_Reject ALL


What looks strange to me is the second "relay accept" line.
If I read it correctly, then any IP where the reverse lookup does return *.mydomain.ch is allowed to relay mails.

Is that true, or do I have misiterpreted something ? (Putting a wrong domain in the reverse lookup is very very simple...)

André

Yes this is correct - it'll allow any client machine from where the reverse lookup does return *.mydomain.ch is allowed to relay mails. However your reverse lookup is controlled by your reverse DNS server and the client can not pretend that is coming from your domain if his IP is not configured your reverse DNS server.

swordfish wrote:Yes this is correct - it'll allow any client machine from where the reverse lookup does return *.mydomain.ch is allowed to relay mails. However your reverse lookup is controlled by your reverse DNS server and the client can not pretend that is coming from your domain if his IP is not configured your reverse DNS server.

I'm not sure this is not a issue. If the server only does a reverse lookup and does NOT verify it via a forward lookup, then we have a issue.

Example:

I (as a spammer) set the reverse lookup for ip 34.54.232.2 to me.swordfish.com.
Now I send a mail via your mailserver from the ip 34.54.232.2.

The scalixserver will do a reverselookup for the IP 34.54.232.2 and it will receive me.swordfish.com.
This matches it's relay rules, and my spam is happily forwarded to it's destination.

We would only be safe, if the server does check (via a forward lookup) if me.swordfish.com realy resolves to the ip 34.54.232.2

André

Theoretically this could be possible however nowdays most spammers are bots or DSL users which do not control over the reverse DNS. In any case the best would be to use SMTP AUTH for any relay emails. But anyway may be Scalix should remove this entry from the default settings.

swordfish wrote:Theoretically this could be possible however nowdays most spammers are bots or DSL users which do not control over the reverse DNS. In any case the best would be to use SMTP AUTH for any relay emails. But anyway may be Scalix should remove this entry from the default settings.

Ok,

how do we get scalix to remove this in default setups ?

Open a issue in bugzilla, or what is best for this ?

André

They should be reviewing this forum and see any suggestions. Please anyone from Scalix correct this if we are making a wrong assumptions here and if there is reason for this entry to be on by default.

swordfish wrote:They should be reviewing this forum and see any suggestions. Please anyone from Scalix correct this if we are making a wrong assumptions here and if there is reason for this entry to be on by default.

Do you think they have seen it ?

You also have to take into consideration situations where SMTP Auth is not fully possible (large numbers of POP3 mailboxes, maybe). Or where you run clients that for some reason cannot do auth (automated processes jump to mind). In this scenario the defaults are quite reasonable.

Also, your DNS should return only return names when you do a reverse lookup on entries that actually belong to you. If it does for an IP not under your control you should be examining running a different DNS server internally. I know with BIND as I set it up even if someone outside my network uses my domain in a reverse lookup I wouldn't relay, as my DNS server believes it is authoritative for my domain and therefore won't make any further queries outwards.

Hello,

sure these settings CAN be useful, but I still think they are not safe as default values.

When I have my DNS server being authoritative for mydomain.ch, then it will of course not forward queries for any *.mydomain.ch

But if I ask my server what is the name of 34.54.232.2, then my DNS server is not authoritative for this lookup () and forwards it to a name server who is not under our control and this one can return spam.mydomain.ch.

The name servers I know, now don't validate this answer with a lookup for the IP of spam.mydomain.ch.

Yes, you are correct with the DNS lookup. I suppose it depends on the site more than anything else. When I do an installation I would of course check this, but someone new to Scalix may not.

We will have to see what the Scalix people think of this, ultimately.

I actually think what you're proposing is a good idea.

I don't actually know if we're doing double reverse lookups, but I agree that we should make sure that nobody abuses such possibilities.

It would be best if you could open up a bug in Bugzilla for this - I'll make sure it's being looked at as I review most of the external incoming entries.

The original reason for this is long-gone - when there was a product before Scalix, it didn't provide SMTP auth, so this setting was needed for internal users. For Scalix 11, we now also made SWA use SMTP auth, so the requirement to list the SWA server's IP address in there is also no longer there. We can also use separate ports for submission and incoming, as per comments in the config file. Using all those makes us pretty spam-proof.

I do agree we should do better in the default config.

Cheers, Thanks,
Florian.

Hello Florian

florian wrote:It would be best if you could open up a bug in Bugzilla for this - I'll make sure it's being looked at as I review most of the external incoming entries.

It's done, Bug #14840

florian wrote:The original reason for this is long-gone - when there was a product before Scalix, it didn't provide SMTP auth, so this setting was needed for internal users. For Scalix 11, we now also made SWA use SMTP auth, so the requirement to list the SWA server's IP address in there is also no longer there. We can also use separate ports for submission and incoming, as per comments in the config file. Using all those makes us pretty spam-proof.

Thanks

André

Hi Andre,

So now we know that Scalix support is watching these issues and taking care of the them

swordfish wrote:Hi Andre,

So now we know that Scalix support is watching these issues and taking care of the them

That's good to know.

André