[BlueOnyx:21697] Re: mailserver; possible security issue?

[Dirk Estenfeld]

Hello Michael,

thank you for the explanations and for the tip with the SPF Config-Settings in Spamassassin.

One feature request at this point ;)
Could it be possible to add a checkbox in the AV-SPAM Module with "Reject SPF_FAIL mails" and a GUI configurable setting that SPF_FAIL will get additional 50 points in spamassassin?
SPF_SOFTFAIL or SPF_NEUTRAL can stay as they are. However I would like to see a feature which will reject SPF fail mails if a SPF for a domain is present. 

Best regards,
Dirk 


---

blackpoint GmbH - Friedberger Straße 106b - 61118 Bad Vilbel

-----Ursprüngliche Nachricht-----
Von: Blueonyx [mailto:blueonyx-bounces at mail.blueonyx.it] Im Auftrag von Michael Stauber
Gesendet: Donnerstag, 25. Januar 2018 18:55
An: blueonyx at mail.blueonyx.it
Betreff: [BlueOnyx:21690] Re: mailserver; possible security issue?

Hi all,

Earlier I wrote:
> Can Sendmail be hardened to prevent these kind of things? Yes and no.
> Yes, but in ways that make it less practical for roaming clients and you
> would need a separate MTA for users *sending* emails than the MTA that
> generally receives the emails.

To elaborate on that with respect to Sendmail let me say the following.

I looked at our Sendmail configuration to see if there are any "best
practices" or recommendations which we aren't already following. Not
really. To the contrary: We already took it to certain extremes.

Are there Sendmail methods or configurational options that could be used
to prevent local email spoofing? Aside from outside methods such as SPF
or DEMARC?

Yes. But that would come with a loss of functionality. We could deny
that our Sendmail relays for local domains/users. It would still accept
emails via SMTP-Auth. But it would no longer relay for our own
domain(s). This - however - is impractical if you have applications on
the server. Such as mailing lists, online shops, contact forms, blogs or
email ticket systems that send emails to you and don't use SMTP-Auth.

Which sort of kills that idea right there.

Then I looked at some extreme measures and an extension of Milter-GeoIP
(or a Milter in general) came to mind. With a Milter I can check header
and body of incoming emails and can act on pointers. I do see there
where an email comes from, if it's a relayed message (originating
elsewhere or via a localhost relay), can see if SMTP-Auth is used and
can also check sender and recipient.

I could create a Milter or Milter-function that checks for several
related cases:

Remote relay:
==============

Sender email address claims to be from a local domain or email address.
In that case we could check if the remote sender is covered by our
MX-Records (or a local table in which we list allowed domains/networks)
and if not, we refuse to accept the email. That would stop a bit of FROM
forgery.

Local relay:
============

Like telnet connection to our server to port 25 or a script on our
server trying to send emails to a local recipient. If it's a connection
from a remote IP (like via Telnet or from another email-server) we get
an originating IP. If the FROM claims to be a local domain, we can again
check the MX-Records (or a local table in which we list allowed
domains/networks) and allow/deny based on that. Furthermore we can check
if SMTP-Auth is being used for remote connections and if not, we deny
the email with the faked FROM that claims to be from a local user.

Problems:
==========

It still leaves open what happens if a local non-network-socket
connection is made. Like via invoking /usr/sbin/sendmail or the "mail"
command directly. Depending on the usage case I might see the origin IP
as empty, "127.0.0.1", "::1", "localhost". Such as from a PHP-script or
similar that doesn't use SMTP-Auth. I could waive all of that through,
but it's an avenue for both local and remote forgery as well.

But: Via remote access it could be that someone claims he's from
"localhost" or "127.0.0.1" or another IP that we possibly happen to
relay for and it must be made sure that we don't fall for that in the
Milter-stage.

Soo ... it's something to look into and there are some ideas that can be
rolled around for practicability in a Milter.

Yet it would be somewhat redundant as SPF already covers this in a
pretty neat and more lightweight fashion.

-- 
With best regards

Michael Stauber
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx