Postscreen white listing based on MX, SPF

[Lefteris Tsintjelis]

Is it possible to add points to clients based on valid SPF (-/~all) and/or valid MX records? For example, give points to a client if it is a valid MX, and/or, give points again if listed in SPF with -all, give less points if valid client but SPF is ~all etc.

[Noel Jones]

Post by Lefteris Tsintjelis
Is it possible to add points to clients based on valid SPF (-/~all) and/or valid MX records? For example, give points to a client if it is a valid MX, and/or, give points again if listed in SPF with -all, give less points if valid client but SPF is ~all etc.

No. Postscreen only knows the IP address. Any further processing
must be done in the regular smtpd restrictions.


-- Noel Jones

[Wietse Venema]

Post by Lefteris Tsintjelis
Is it possible to add points to clients based on valid SPF (-/~all)
and/or valid MX records? For example, give points to a client if
it is a valid MX, and/or, give points again if listed in SPF with
-all, give less points if valid client but SPF is ~all etc.

That is fundamentally not how postscreen works. postscreen whitelists
the client, not the combination (client + SMTP commands). Its purpose
is to block bad clients with zero overhead for whitelisted clients,
not doing things that require inspecting commands from all SMTP sessions.

I suggest that you do complex access policies with a policy plugin
or content filter. Any DNS lookups by postscreen will be cached in
your local resolver, so it is OK to make those queries a second time.

Besides, I would not allow postscreen to do DNS lookups other than
DNSBL/DNSWL servers. Looking up information from random DNS servers
would mak postscreen a performance bottleneck.

Wietse

[Lefteris Tsintjelis]

Post by Wietse Venema
That is fundamentally not how postscreen works. postscreen whitelists
the client, not the combination (client + SMTP commands). Its purpose
is to block bad clients with zero overhead for whitelisted clients,
not doing things that require inspecting commands from all SMTP
sessions.

I am not sure I follow you with the SMTP commands. Maybe I was not clear
but I was referring to SPF and MX DNS records only which are purely DNS
lookups based on client's IP and do not require any SMTP inspection,
just
like DNSBL/DNSWL.

Post by Wietse Venema
I suggest that you do complex access policies with a policy plugin
or content filter. Any DNS lookups by postscreen will be cached in
your local resolver, so it is OK to make those queries a second time.

I am already using both, policy plugins and content filters.

Post by Wietse Venema
Besides, I would not allow postscreen to do DNS lookups other than
DNSBL/DNSWL servers. Looking up information from random DNS servers
would mak postscreen a performance bottleneck.

It is those bottle necks you are referring that I also try to avoid
content filters, complex plugins and log parsers, as much as possible,
as they can all be expensive and can cause much bigger and continuous
performance issues than random DNS servers every now and then.

I realize of course that postscreen was made for low CPU cost front end
performance rejection mechanism but personally in addition to this I
would like to see a much better and direct way for postfix to cooperate
with firewalls as a front end rejection. I think this is the ultimate
low cost front end rejection that could also cover attacks to the
submission port as well and also has the highest cost for the abuser.

[/dev/rob0]

Post by Lefteris Tsintjelis

Post by Wietse Venema
That is fundamentally not how postscreen works. postscreen
whitelists the client, not the combination (client + SMTP
commands). Its purpose is to block bad clients with zero overhead
for whitelisted clients, not doing things that require inspecting
commands from all SMTP sessions.

I am not sure I follow you with the SMTP commands. Maybe I was not
clear but I was referring to SPF and MX DNS records only which are
purely DNS lookups based on client's IP and do not require any SMTP
inspection, just like DNSBL/DNSWL.

Both points are incorrect.

An MX lookup based on client IP is not possible. There are generally
no MX records in "arpa." zones. MX lookup would be based on the
domain in the MAIL FROM: address. That does indeed require SMTP
inspection. As implemented, postscreen does not know the MAIL FROM:
address until after it has already decided to reject or defer the
client.

This requires both the lookup of the domain's MX, and then an A/AAAA
lookup of the MX hostname[s]. These lookups are necessarily in
sequence rather than in parallel.

Likewise, SPF (the "S" stands for "Sender") needs a lookup of the
domain in MAIL FROM:. From there it could require many more DNS
lookups, depending on whether the SPF/TXT record exists and on the
content thereof.

No, we are not going to see these features in postscreen. They do
not make sense.

[Lefteris Tsintjelis]

Post by /dev/rob0
An MX lookup based on client IP is not possible. There are generally
no MX records in "arpa." zones. MX lookup would be based on the
domain in the MAIL FROM: address. That does indeed require SMTP
address until after it has already decided to reject or defer the
client.
This requires both the lookup of the domain's MX, and then an A/AAAA
lookup of the MX hostname[s]. These lookups are necessarily in
sequence rather than in parallel.
Likewise, SPF (the "S" stands for "Sender") needs a lookup of the
domain in MAIL FROM:. From there it could require many more DNS
lookups, depending on whether the SPF/TXT record exists and on the
content thereof.
No, we are not going to see these features in postscreen. They do
not make sense.

OK, you are right, I see your point and postscreen should not do that.
I was thinking it more in simple DNS terms only and a simply reverse
look up of the IP and then extract the domain from there but it is not
possible without the FROM.

[Jim Reid]

Post by Lefteris Tsintjelis
I was thinking it more in simple DNS terms only and a simply reverse
look up of the IP and then extract the domain from there but it is not
possible without the FROM.

That wouldn’t have worked anyway.

Assuming a reverse lookup of an IP address returns a name -- a big if -- there’s no guarantee that name has any relation to whatever domain name is in the MAIL FROM.

For instance, lots of organisations outsource their email to specialised hosting/service providers. A MAIL FROM might well say example.com while the reverse lookup returns some name in $emailprovider.com for a server that’s delivering email sent by bazillions of customers.

[Lefteris Tsintjelis]

Post by Jim Reid
That wouldn’t have worked anyway.
Assuming a reverse lookup of an IP address returns a name -- a big if
-- there’s no guarantee that name has any relation to whatever domain
name is in the MAIL FROM.
For instance, lots of organisations outsource their email to
specialised hosting/service providers. A MAIL FROM might well say
example.com while the reverse lookup returns some name in
$emailprovider.com for a server that’s delivering email sent by
bazillions of customers.

No guarantees of course but the majority of valid MX servers return a
name.

It would have worked for smaller orgs where they usually have one MX
server and a relativly simple mail and domain setup. Besides, this would
have been a white listing only method so no harm done other than the
additional DNS lookups but I guess it is not postscreen's job for this.

[Erwan David]

Post by Lefteris Tsintjelis

Post by Jim Reid
That wouldn’t have worked anyway.
Assuming a reverse lookup of an IP address returns a name -- a big if
-- there’s no guarantee that name has any relation to whatever domain
name is in the MAIL FROM.
For instance, lots of organisations outsource their email to
specialised hosting/service providers. A MAIL FROM might well say
example.com while the reverse lookup returns some name in
$emailprovider.com for a server that’s delivering email sent by
bazillions of customers.

No guarantees of course but the majority of valid MX servers return a
name.
It would have worked for smaller orgs where they usually have one MX
server and a relativly simple mail and domain setup. Besides, this would
have been a white listing only method so no harm done other than the
additional DNS lookups but I guess it is not postscreen's job for this.

MX are for *incoming* messages. No garantee at all that outgoing servers
are the same. For big companies, it is quite standard to use different
servers for incoming and outgoing messages.