John D. Hardin wrote:

Wed, 23 Aug 2006, Philip Prindeville wrote:


>
>>Hmm Maybe if I post with a more obvious subject line
>>
>>What is the notation for writing a "whitelist_from" or
>>"whitelist_from_rcvd" when the sender is <? (As in "MAIL FRM:
>><>")
>
>>
>
>Are you sure you want to use that broad a brush? There is a *lot* of
>garbage that is sent as faked mailer daemon bounces.

Well, yes, especially since the IP address of the sender is reserved for
a machine that does ticketing and auto-replies exclusively (I was going
to use whitelist_from_rcvd and not just whitelist_from).

>When dealing with a known correspondent's brokenness, it's safer to
>focus your permissiveness rather tightly. Try a meta rule that matches
>a Received: line on a bounce from them, add a rule that ANDs that meta
>with the rule that fires on their malformed date, and score it to
>cancel out the malformed date score.

I'm not ready to work that hard

I'd rather catch the broken email, point it out to them, have them fix it,
and then remove the whitelisting when they've fixed their agent.
-Philip

Philip Prindeville wrote:
>
>
>
Well, yes, especially since the IP address of the sender is reserved for
a machine that does ticketing and auto-replies exclusively (I was going
to use whitelist_from_rcvd and not just whitelist_from).

At that point, you should be able to use:

whitelist_from_rcvd * rdns.host.name

Which will effectively white-list the host.

Matt Kettler wrote:

>Philip Prindeville wrote:


>>Well, yes, especially since the IP address of the sender is reserved for
>>a machine that does ticketing and auto-replies exclusively (I was going
>>to use whitelist_from_rcvd and not just whitelist_from).
>
>>
>
>At that point, you should be able to use:
>
whitelist_from_rcvd * rdns.host.name
>
>Which will effectively white-list the host.

There's no way to whitelist just the empty address then? Rather than
everything?
-Philip

Philip Prindeville wrote:

There's no way to whitelist just the empty address then? Rather than
everything?

-Philip

Not given the simple file-glob format of the whitelist commands. You'd
need a regular expression and negation.

You could do it with a rule

header __NULL_RETURN From !~ /./i
header __RCVD_MYHST Received =~ /<insert Received header regex
matching your servers exchanging>/
meta MY_NULL_RETURN (__NULL_RETURN && __RCVD_MYHST)

Matt Kettler wrote:

>Philip Prindeville wrote:

>
>>There's no way to whitelist just the empty address then? Rather than
>>everything?
>>
Philip
>>
>
>
>>
>Not given the simple file-glob format of the whitelist commands. You'd
>need a regular expression and negation.
>
>You could do it with a rule
>
>header __NULL_RETURN From !~ /./i
>header __RCVD_MYHST Received =~ /<insert Received header regex
>matching your servers exchanging>/
>meta MY_NULL_RETURN (__NULL_RETURN && __RCVD_MYHST)

How about modifying the source to accept some sort of notation for an
empty address in whitelist_from_rcvd?
-Philip

Matt Kettler wrote:

>Philip Prindeville wrote:

>
>>There's no way to whitelist just the empty address then? Rather than
>>everything?
>>
Philip
>>
>
>
>>
>Not given the simple file-glob format of the whitelist commands. You'd
>need a regular expression and negation.
>
>You could do it with a rule
>
>header __NULL_RETURN From !~ /./i
>header __RCVD_MYHST Received =~ /<insert Received header regex
>matching your servers exchanging>/
>meta MY_NULL_RETURN (__NULL_RETURN && __RCVD_MYHST)
>
>

It's not the From, but rather the EnvelopeFrom.

2006-08-29 09:16:46.000000000 -0600
2006-10-19 20:44:18.000000000 -0600
@@ -631,6 +631,10 @@
unless (defined $value && $value !~ /^$/) {
return $;
}
+ # email from postmaster, abuse autoresponders, etc.
+ if ($value eq '<>') {
+ return $conf->{parser}->add_to_addrlist ($key, '');
+ }
$conf->{parser}->add_to_addrlist ($key, split (' ', $value));
}

I tried the above fix, but it didn't work.

Not sure why
-Philip

Philip Prindeville wrote:
Matt Kettler wrote:


>Philip Prindeville wrote:
>
>>
>
There's no way to whitelist just the empty address then? Rather than
everything?

-Philip


>Not given the simple file-glob format of the whitelist commands. You'd
>need a regular expression and negation.
>>
>You could do it with a rule
>>
>header __NULL_RETURN From !~ /./i
>header __RCVD_MYHST Received =~ /<insert Received header regex
>matching your servers exchanging>/
>meta MY_NULL_RETURN (__NULL_RETURN && __RCVD_MYHST)
>>
>>
>
>>
>
>
It's not the From, but rather the EnvelopeFrom.

A rule matching "header From" should match any "from like" header,
including Return-Path.

Unless you're calling SA before the return-path header is created, in
which case you can't match it with SA at all.
>
>
>

Matt Kettler wrote:

>Philip Prindeville wrote:

>
>>Matt Kettler wrote:
>>
>
>
>>
Philip Prindeville wrote:

There's no way to whitelist just the empty address then? Rather than
everything?

Philip

Not given the simple file-glob format of the whitelist commands. You'd
need a regular expression and negation.

You could do it with a rule

header __NULL_RETURN From !~ /./i
header __RCVD_MYHST Received =~ /<insert Received header regex
matching your servers exchanging>/
meta MY_NULL_RETURN (__NULL_RETURN && __RCVD_MYHST)


>>It's not the From, but rather the EnvelopeFrom.
>
>
>>
>A rule matching "header From" should match any "from like" header,
>including Return-Path.

Not sure I follow.

The From: header will be <mailer-daemon (AT) foo (DOT) baror <postmaster (AT) foo (DOT) bar>
or something similar (depending on the agent).

The Sender (EnvelopeFrom will be empty, however). I believe that MdF
sticks that into the ReturnPath: header.
-Philip

>Unless you're calling SA before the return-path header is created, in
>which case you can't match it with SA at all.

>
>
>
>>
>

Philip Prindeville wrote:
Matt Kettler wrote:


>Philip Prindeville wrote:
>
>>
>
Matt Kettler wrote:

Not given the simple file-glob format of the whitelist commands. You'd
need a regular expression and negation.

You could do it with a rule

header __NULL_RETURN From !~ /./i
header __RCVD_MYHST Received =~ /<insert Received header regex
matching your servers exchanging>/
meta MY_NULL_RETURN (__NULL_RETURN && __RCVD_MYHST)

It's not the From, but rather the EnvelopeFrom.


>A rule matching "header From" should match any "from like" header,
>including Return-Path.
>
>>
>
>
Not sure I follow.

The From: header will be <mailer-daemon (AT) foo (DOT) baror <postmaster (AT) foo (DOT) bar>
or something similar (depending on the agent).

The Sender (EnvelopeFrom will be empty, however). I believe that MdF
sticks that into the ReturnPath: header.

Yes, I understand. And what I'm telling you is a header rule checking
the "from" header, will match EITHER the contents of From: or Return-Path:

It won't just look at the From: header. SA considers both to be "From"
headers of a sort, so it runs the rules against both of them. This saves
a lot of duplication of rules that would need to be written to check all
the possible "from" type headers in a message. It's more-or-less the
same as why a body rule can match the Subject: header text.

As long as SA is being called after your MDA adds the Return-Path:
header, the rule should work.

If it's not working, try this one:

header MY_NULL_RETURN2 From =~/\<\>/
score MY_NULL_RETURN2 0.5