$| what does it mean
John Kelly
like check_relay or check_rcpt?
All I could find in the book is mention of a macro conditional. But
this looks like something else.
Claus Aßmann
> What is the meaning of $| when it appears on the LHS or RHS of a rule
> like check_relay or check_rcpt?
doc/op/op.*:
5.1.4.1. check_relay
The check_relay ruleset is called after a
connection is accepted by the daemon. It is not
called when sendmail is started using the -bs
option. It is passed
client.host.name $| client.host.address
where $| is a metacharacter separating the two
parts. This ruleset can reject connections from
various locations.
--
If you feel the urgent wish to send me a courtesy copy of a Usenet
posting, then make sure it's recognizable as such!
The FAQ: http://www.sendmail.org/faq/ Before you ask.
John Kelly
> client.host.name $| client.host.address
>
> where $| is a metacharacter separating the two
> parts. This ruleset can reject connections from
> various locations.
Yes, I had read that in the docs, but I did not understand it at
first. I thought $| had some value.
I think I have the correct understanding now, so I wrote this rule to
check forged sender addresses with SMTP-AUTH:
> SLocal_check_rcpt
> R$* $: $1 $| $&{daemon_name}
> R$* $| $@ $1
> R$* $| MSA $: $1 $| MSA $| $( generics $&{auth_authen} $: DISABLED $)
> R$* $| MSA $| DISABLED $#error $@ 5.7.1 $: "550 Account " $&{auth_authen} " SMTP disabled"
> R$* $| MSA $| $&f $@ $1
> R$* $| MSA $| $* $#error $@ 5.7.1 $: "550 Forged sender address " $&f " rejected"
> R$* $| $* $@ $1
I use two separate IP addresses for listeners, one for MTA (port 25),
and another for MSA (port 25 and 587). All connections to the MTA
listener are denied relaying; it accepts inbound traffic from other
ISPs.
Relaying is only permitted via MSA listeners (port 25 and 587), and
SMTP AUTH is mandatory on them, so all users are forced to use SMTP
AUTH for relaying. I will implement that policy with users.
In the ruleset, if a message did not arrive on an MSA listener, then
no special processing is done.
Because of my mail policy, any messages arriving on an MSA listener
are authenticated with SMTP AUTH. So I look up the user account name
in the generics table, to see if their email address on file matches
what they configured in their email client software.
If their record is not found in the generics table, or has the value
DISABLED, they get a "disabled" message. If their record is found but
does not match the email address they supply, then they get a "forged"
message.
Works great!
But I have a question about the rule writing. It seems that I could
simplify it, if only I could do a "not" match on the literal MSA.
The bat book and other docs only talk about "not" matches with ~ and
classes. Can I "not" match a literal or a variable, to avoid defining
a class just for my one value of MSA?
John
Claus Aßmann
> > R$* $: $1 $| $&{daemon_name}
> > R$* $| $@ $1
> > R$* $| MSA $: $1 $| MSA $| $( generics $&{auth_authen} $:
> But I have a question about the rule writing. It seems that I could
> simplify it, if only I could do a "not" match on the literal MSA.
Just exit the ruleset if there is something else.
R$* $: $1 $| $&{daemon_name}
R$* $| MSA $@ $1
R$* $| $* $# $1
....
rest of rules only apply if $&{daemon_name} == MSA.
John Kelly
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:
>Just exit the ruleset if there is something else.
>R$* $: $1 $| $&{daemon_name}
>R$* $| MSA $@ $1
Am I misunderstanding? It looks like the line above, with the $@
template symbol will exit if $&{daemon_name} == MSA, the opposite of
what I need.
>R$* $| $* $# $1
The docs says only use $# in ruleset 0. What does $# do in this case?
How about this:
> R$* $: $1 $| $&{daemon_name}
> R$* $| MSA $: $1
> R$* $| $* $@ $1
> ......
>rest of rules only apply if $&{daemon_name} == MSA.
Am I correct?
Neil W Rickert
>> SLocal_check_rcpt
>> R$* $: $1 $| $&{daemon_name}
>> R$* $| $@ $1
>> R$* $| MSA $: $1 $| MSA $| $( generics $&{auth_authen} $: DISABLED $)
>> R$* $| MSA $| DISABLED $#error $@ 5.7.1 $: "550 Account " $&{auth_authen} " SMTP disabled"
>> R$* $| MSA $| $&f $@ $1
>> R$* $| MSA $| $* $#error $@ 5.7.1 $: "550 Forged sender address " $&f " rejected"
>> R$* $| $* $@ $1
>[snip]
>In the ruleset, if a message did not arrive on an MSA listener, then
>no special processing is done.
>Because of my mail policy, any messages arriving on an MSA listener
>are authenticated with SMTP AUTH. So I look up the user account name
>in the generics table, to see if their email address on file matches
>what they configured in their email client software.
>If their record is not found in the generics table, or has the value
>DISABLED, they get a "disabled" message. If their record is found but
>does not match the email address they supply, then they get a "forged"
>message.
Ouch, that's nasty. The DISABLED, I understand. But if your users
are running linux and sendmail, they might want to use ".forward"
files, and might generate DSNs. So they will be then be sending mail
with other than the approved email address. This should be perfectly
legitimate behavior. So why will you reject their mail with a
"forged" message?
Neil W Rickert
>On 7 Apr 2001 13:39:10 GMT, Claus Assmann
><ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> wrote:
>>Just exit the ruleset if there is something else.
>>R$* $: $1 $| $&{daemon_name}
>>R$* $| MSA $@ $1
>Am I misunderstanding? It looks like the line above, with the $@
>template symbol will exit if $&{daemon_name} == MSA, the opposite of
>what I need.
Perhaps that was intended to be MTA.
>>R$* $| $* $# $1
>The docs says only use $# in ruleset 0. What does $# do in this case?
You can also use $# in the check_ rulesets. In this case
it would bypass remaining spam checks.
John Kelly
wrote:
>>If their record is not found in the generics table, or has the value
>>DISABLED, they get a "disabled" message. If their record is found but
>>does not match the email address they supply, then they get a "forged"
>>message.
>
>Ouch, that's nasty. The DISABLED, I understand. But if your users
>are running linux and sendmail, they might want to use ".forward"
>files, and might generate DSNs.
I offer shell accounts too. Users who are running linux will just
have to handle all .forwarding via their shell account at their ISP
(me), and not on their own linux box.
>So why will you reject their mail with a "forged" message?
Users can have more than one email address, but they have to request
each one. I associate each one with their account, and register it in
the generics table. Any email address not associated with an account
which belongs to them is considered a forgery. That way, they can't
even hijack an email address which belongs to some other valid user.
This will prevent spammers from opening accounts and sending mail with
a bogus address which is not registered as belonging to their account.
When spammers realize they cannot forge the sender address, they will
go somewhere else to send their mail. All ISPs should implement this
policy. Then the spammers will have nowhere to go!
This was the first piece of my local hack. Next, I plan to modify
srvrsmtp.c to count outbound emails. Each user will have a predefined
daily limit according to their account privileges. Upon reaching that
limit, their outbound SMTP will be disabled until the next day.
Once that's in place, then bye-bye spammers!
John
Neil W Rickert
>On 7 Apr 2001 19:28:39 -0500, Neil W Rickert <ricke...@cs.niu.edu>
>wrote:
>>>If their record is not found in the generics table, or has the value
>>>DISABLED, they get a "disabled" message. If their record is found but
>>>does not match the email address they supply, then they get a "forged"
>>>message.
>>Ouch, that's nasty. The DISABLED, I understand. But if your users
>>are running linux and sendmail, they might want to use ".forward"
>>files, and might generate DSNs.
>I offer shell accounts too. Users who are running linux will just
>have to handle all .forwarding via their shell account at their ISP
>(me), and not on their own linux box.
And how much is Bill Gates paying you to assist him in his diabolical
plan to rule the world :-)
>>So why will you reject their mail with a "forged" message?
>Users can have more than one email address, but they have to request
>each one. I associate each one with their account, and register it in
>the generics table. Any email address not associated with an account
>which belongs to them is considered a forgery. That way, they can't
>even hijack an email address which belongs to some other valid user.
But I like to be able to make up email address of the form user+xx on
a whim. I don't need a fascist dictator requiring that I register
each new variation. I would find your rules intolerable.
>This will prevent spammers from opening accounts and sending mail with
>a bogus address which is not registered as belonging to their account.
Sorry, that's a bad way of fighting spam. It should suffice for you
to keep log records, with the correct identity of the user. Then, if
any spam is brought to your attention, you can identify the culprit
from their logged authentication identity. This is more reliable than
depending on the given sender address.
>When spammers realize they cannot forge the sender address, they will
>go somewhere else to send their mail. All ISPs should implement this
>policy. Then the spammers will have nowhere to go!
When spammers realize that they will be caught from your recorded
logs, they will do the same. There is no need to be fascist about
it.
All ISPs that practice fascist policies should be driven out of
business.
>This was the first piece of my local hack. Next, I plan to modify
>srvrsmtp.c to count outbound emails. Each user will have a predefined
>daily limit according to their account privileges. Upon reaching that
>limit, their outbound SMTP will be disabled until the next day.
>Once that's in place, then bye-bye spammers!
It's the wrong way to control spam. If the only way we fight spam
has the effect of destroying the functionality and usefuless of
email, then the spammers will have won a huge victory. We ought not
allow that to happen.
John Kelly
wrote:
>When spammers realize that they will be caught from your recorded
>logs, they will do the same. There is no need to be fascist about
>it.
Fascist? I'm running a business, not a government. Businesses have
customers, not prisoners.
>All ISPs that practice fascist policies should be driven out of
>business.
I think market and economic forces will be more influential than
personal politics in determining which ISPs live or die.
>Sorry, that's a bad way of fighting spam. It should suffice for you
>to keep log records, with the correct identity of the user. Then, if
>any spam is brought to your attention, you can identify the culprit
>from their logged authentication identity.
If I'm running a business, why should I waste time chasing through the
logs to catch spammers, when I can just stop them at the door, so they
don't even get in?
>This is more reliable than depending on the given sender address.
Not in my case. Each sender address is cross referenced to a user
account.
>It's the wrong way to control spam. If the only way we fight spam
>has the effect of destroying the functionality and usefuless of
>email, then the spammers will have won a huge victory. We ought not
>allow that to happen.
Are you concerned about freedom? From a business perspective, I view
freedom in relative terms rather than absolute.
In that context, I don't forsee any significant downside to my policy,
and I believe it's an effective method of preventing SPAM. Better to
prevent SPAM than to punish it after the fact.
John