Using Postfix WARN Action Properly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Using Postfix WARN Action Properly

Rich Shepard
    The Postfix book tells me that using the WARN option on a restriction
(such as in the /etc/postfix/header_checks file) logs the warning while
delivering the message. However, there is apparently no marking of the
message so it's clearly identified as one that tripped that warning.

    I want to examine delivered messages that contain
"Content-Transfer-Encoding: base64" in the header. Adding that string to the
header_checks file with a WARN option does not explicitly identify those
messages.

    Use of the warn action is not giving me the results I want. How should I
be doing this? Alternatively, if I use the HOLD option instead, where are
those messages held until I can examine them?

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

Ralf Hildebrandt
* Rich Shepard <[hidden email]>:
>    The Postfix book tells me that using the WARN option on a restriction
> (such as in the /etc/postfix/header_checks file) logs the warning while
> delivering the message. However, there is apparently no marking of the
> message so it's clearly identified as one that tripped that warning.

Usually you can identify the message using sender, recipient and/or
message-id:

Oct  6 22:59:28 mail postfix/cleanup[2703]: 75B5C1C360A: warning: header Subject: AARON LORDSON ON A TALENT SHOW !! from
server009.hostspectrum.com[64.92.105.16]; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<server009.hostspectrum.com>

using the QueueID I can retrieve the message-id:

Oct  6 22:59:28 mail postfix/cleanup[2703]: 75B5C1C360A: message-id=<[hidden email]>

>    I want to examine delivered messages that contain
> "Content-Transfer-Encoding: base64" in the header.

Basically that would be all messages...

> Adding that string to the header_checks file with a WARN option does
> not explicitly identify those messages.
>
>    Use of the warn action is not giving me the results I want. How should I
> be doing this? Alternatively, if I use the HOLD option instead, where are
> those messages held until I can examine them?

What exactly is it that you want to do.
In real life almost ALL mails are base64 encoded...

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  [hidden email] | http://www.charite.de
           

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

Wietse Venema
In reply to this post by Rich Shepard
Rich Shepard:
>     The Postfix book tells me that using the WARN option on a restriction
> (such as in the /etc/postfix/header_checks file) logs the warning while
> delivering the message. However, there is apparently no marking of the
> message so it's clearly identified as one that tripped that warning.
>
>     I want to examine delivered messages that contain
> "Content-Transfer-Encoding: base64" in the header. Adding that string to the
> header_checks file with a WARN option does not explicitly identify those
> messages.

Perhaps "warn" is not the right concept for inspecting mail.
Options more directly related to mail inspection would be:

hold Freeze the mail in the queue until acted upon.

filter Divert the message into some external program.

filter has its own documentation, FILTER_README, also on-line
as http://www.postfix.org/FILTER_README.html.

>     Use of the warn action is not giving me the results I want. How should I
> be doing this? Alternatively, if I use the HOLD option instead, where are
> those messages held until I can examine them?

Frozen mail can be inspected with "postcat -q queueid", or
deleted/requeued with the "postsuper" command.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

Rich Shepard
In reply to this post by Ralf Hildebrandt
On Tue, 6 Oct 2009, Ralf Hildebrandt wrote:

>>    I want to examine delivered messages that contain
>> "Content-Transfer-Encoding: base64" in the header.
>
> Basically that would be all messages...

Ralf,

   I asked locally about that because much of the spam I receive is coded
base64 while almost all other traffic is either encoded 7bits or doesn't
have a Content-Transfer-Encoding specification in the header.

> What exactly is it that you want to do. In real life almost ALL mails are
> base64 encoded...

   I want to explore the possibility of using this to identify spam that is
obfuscated and passes the other postfix UCE filters. There are some
persistent spammers with the same text string in the body of the message
that I can initially catch with a body_checks filter. But, soon the messages
make it into my inbox despite that phrase being in the body_checks. Looking
at the headers of these I see the "Content-Transfer-Encoding: base64" line,
and I don't see it in other messages in my inbox. I think that alpine
automatically decodes them after postfix hands them off to procmail so the
UCE filters stop working.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

Rich Shepard
In reply to this post by Wietse Venema
On Tue, 6 Oct 2009, Wietse Venema wrote:

> Perhaps "warn" is not the right concept for inspecting mail. Options more
> directly related to mail inspection would be:
>
> hold Freeze the mail in the queue until acted upon.

> Frozen mail can be inspected with "postcat -q queueid", or
> deleted/requeued with the "postsuper" command.

Wietse,

   Thank you. I'll try this instead of the warn action.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

Stan Hoeppner
In reply to this post by Rich Shepard
Rich Shepard put forth on 10/6/2009 4:38 PM:

> On Tue, 6 Oct 2009, Ralf Hildebrandt wrote:
>
>>>    I want to examine delivered messages that contain
>>> "Content-Transfer-Encoding: base64" in the header.
>>
>> Basically that would be all messages...
>
> Ralf,
>
>   I asked locally about that because much of the spam I receive is coded
> base64 while almost all other traffic is either encoded 7bits or doesn't
> have a Content-Transfer-Encoding specification in the header.

Hi Rich,

Would you please forward me a few copies (off list), with full headers,
of the spams causing you this grief, and also a list of all the IPs that
have sent you this particular kind of spam.

Thanks.

--
Stan

P.S.  Please also join the spam-l spam fighters mailing list:
http://spam-l.com/mailman/listinfo/spam-l
Reply | Threaded
Open this post in threaded view
|

So--how do I set up localhost to not require authentication

phorgan1
In reply to this post by Rich Shepard
I'd like email from localhost to not require certificates or
authentication--especially since we assume that people on the machine,
or tunneling to the machine have already passed some level of
authentication.  How do I do it?

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: So--how do I set up localhost to not require authentication

Noel Jones-2
On 10/6/2009 7:16 PM, Patrick Horgan wrote:
> I'd like email from localhost to not require certificates or
> authentication--especially since we assume that people on the machine,
> or tunneling to the machine have already passed some level of
> authentication. How do I do it?
>
> Patrick
>

# main.cf
mynetworks = 127.0.0.1

and everywhere that you have "permit_sasl_authenticated", make
sure it now says "permit_mynetworks, permit_sasl_authenticated".


   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: So--how do I set up localhost to not require authentication

phorgan1
Noel Jones wrote:
> # main.cf
> mynetworks = 127.0.0.1
>
> and everywhere that you have "permit_sasl_authenticated", make sure it
> now says "permit_mynetworks, permit_sasl_authenticated".
Is the order significant, i.e. is permit_mynetworks,
permit_sasl_authenticated the same as
permit_sasl_authenticated,permit_mynetworks?

Patrick

Reply | Threaded
Open this post in threaded view
|

Re: So--how do I set up localhost to not require authentication

Sahil Tandon
On Tue, 06 Oct 2009, Patrick Horgan wrote:

> Noel Jones wrote:
> ># main.cf
> >mynetworks = 127.0.0.1
> >
> >and everywhere that you have "permit_sasl_authenticated", make
> >sure it now says "permit_mynetworks, permit_sasl_authenticated".
> Is the order significant, i.e. is permit_mynetworks,

The order of restrictions is generally significant.

> permit_sasl_authenticated the same as
> permit_sasl_authenticated,permit_mynetworks?

No.  The first example does not allow networks specified in $mynetworks
to relay through your server without authentication.

--
Sahil Tandon <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: So--how do I set up localhost to not require authentication

phorgan1
Sahil Tandon wrote:

Is the order significant, i.e. is permit_mynetworks,
    

The order of restrictions is generally significant.

  
permit_sasl_authenticated the same as
permit_sasl_authenticated,permit_mynetworks?
    

No.  The first example does not allow networks specified in $mynetworks
to relay through your server without authentication.
  
Really!  I'm surprised, I would have thought the rule would be first matched.   So permit_mynetworks,permit_sasl_authenticated won't allow $mynetworks through without authentication?  Just asking for verification because I'm so surprised!  (And because it seems to be working just fine right now!)

patrick

Reply | Threaded
Open this post in threaded view
|

Re: So--how do I set up localhost to not require authentication

Noel Jones-2
On 10/6/2009 8:06 PM, Patrick Horgan wrote:

> Sahil Tandon wrote:
>>>
>>> Is the order significant, i.e. is permit_mynetworks,
>>>
>>
>> The order of restrictions is generally significant.
>>
>>
>>> permit_sasl_authenticated the same as
>>> permit_sasl_authenticated,permit_mynetworks?
>>>
>>
>> No.  The first example does not allow networks specified in $mynetworks
>> to relay through your server without authentication.
>>
> Really! I'm surprised, I would have thought the rule would be first
> matched. So permit_mynetworks,permit_sasl_authenticated won't allow
> $mynetworks through without authentication? Just asking for verification
> because I'm so surprised! (And because it seems to be working just fine
> right now!)
>
> patrick

You misunderstood Sahil's answer.

Hopefully to clarify, Yes the order of restrictions is
significant; first "permit" or "reject" match wins.

However, in the case of {permit_sasl_authenticated,
permit_mynetworks} vs. {permit_mynetworks,
permit_sasl_authenticated} the order is not significant.  If a
client matches either of the restrictions, it will be
considered "permit".  If the rule doesn't match at all
(DUNNO), then continue processing with the next rule.


   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

@lbutlr
In reply to this post by Ralf Hildebrandt
On 6-Oct-2009, at 15:02, Ralf Hildebrandt wrote:
> In real life almost ALL mails are base64 encoded...

Wait, what?

  $ grep -ir "^Content-Transfer-Encoding" . | wc -l
198485
  $ grep -ir "^Content-Transfer-Encoding" . | grep -v base64 | wc -l
195574

Looking at my mail spool almost ALL mail is either 7bit, 8bit, or  
quoted-printable.


--
"I'm not bad; I'm just drawn that way."

Reply | Threaded
Open this post in threaded view
|

Re: Using Postfix WARN Action Properly

Rich Shepard
On Wed, 7 Oct 2009, LuKreme wrote:

> Looking at my mail spool almost ALL mail is either 7bit, 8bit, or
> quoted-printable.

   That's what I've seen here, too.

   Regardless, when I put those base64 messages on hold and looked at them
this morning, none was base64 Content-Transfer-Encoded. I'm without a clue
why they ended up in the hold queue.

   Anyway, this filter string does not seem to be working for me.

Rich
Reply | Threaded
Open this post in threaded view
|

Using Postfix WARN Action Properly

Stan Hoeppner
Rich Shepard put forth on 10/7/2009 1:38 PM:

> On Wed, 7 Oct 2009, LuKreme wrote:
>
>> Looking at my mail spool almost ALL mail is either 7bit, 8bit, or
>> quoted-printable.
>
>   That's what I've seen here, too.
>
>   Regardless, when I put those base64 messages on hold and looked at them
> this morning, none was base64 Content-Transfer-Encoded. I'm without a clue
> why they ended up in the hold queue.
>
>   Anyway, this filter string does not seem to be working for me.
>
> Rich

Hi Rich,

Say, could you grep your mail log for 65.41.216.221 please?  My OOB
reply seems to have been rejected by rule B16.

Thanks.

--
Stan