procmail
[Top] [All Lists]

RE: disable defang on local users

2003-06-05 18:31:07
yes my definition of internal is exactly as you put it.

Thanks for the ideas, I will definitely try to deploy something like that.

Cheers,
-Andreas



-----Original Message-----
From: procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
[mailto:procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE]On Behalf Of 
Professional
Software Engineering
Sent: Thursday, June 05, 2003 5:56 PM
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Subject: RE: disable defang on local users


At 16:55 2003-06-05 -0700, Andreas Freyvogel did say:
This is our internal email server so I see no need to do that to them

Please define "internal" - is that to say that nobody outside of your LAN
is capable of connecting to this server, and that its connection to the
outside world is gia another mailserver which it must relay through?

Do you think I could create a file with the users that I wish to bypass the
'defang' and have procmail compare against that to decide whether to
'defang' or not?

I've posted a variety of straightforward methods to apply filtering only
for certain local users (as recipients however).  Check the recent
/etc/procmailrc thread.  How to validate that the _sender_ is who they say
they are is a whole different matter - if the username portion of the From:
address within your domain is _consistently_ an actual username, then you
could parse that out and do a simple lookup with it, be it a grep, procmail
regexp, groups, or whatever.

Vague, and easily forged methods include:

Trust that the author's address isn't forged:
* ! ^From:(_dot_)*(_at_)yourdomain\(_dot_)tld
{
         # do your defang stuff
}

Likewise, the envelope sender:

* ! ^From (_dot_)*(_at_)yourdomain\(_dot_)tld

Or, any message with a messageid from the local host (bad - much spam, and
even some legit mail, is sent without a Message-id, and the receiving
server, in an effort to be RFC-compliant, creates the header locally):

* ! ^Message-id:(_dot_)*(_at_)host\(_dot_)yourdomain\(_dot_)tld>

Newer sendmails have two queues - the submission (via localhost) and
regular MTA.  For local _shell_ users, you could check for the submission
queue in the headers:

* ! ^Received: .*by host.yourdomain\.tld \(.*/Submit\)

This could be forged, but CURRENT spams and viruses are UNLIKELY to do
that.  Note emphasis on current and unlikely, which are quantities sure to
change at some point.  OTOH, it'll also appear on any message that runs
through a listserv on your host.  It will not identify messages which are
submitted via SMTP (say, from a MUA on a remote machine, such as a windows
desktop).

If you had SMTP authentication (such as SASL), you could check for the
associated headers - but then you're still assuming that the headers have
not been forged (at some point, a virus is going to simply leech the
complete headers of a message and use them to wrap a virus).

You might find it more appropriate (at least, if you're using Sendmail) to
investigate milter and consider adding the logic for filtering there, that
way, you should have direct access to the authentication for the user (but,
as you say, you're not authenticating the senders).

---
  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer:
<http://www.professional.org/procmail/disclaimer.html>
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail




_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>