On Wed, Mar 02, 2005 at 11:47:21PM -0500, Bob wrote:
> #rcpt_ok
>
> my $host = lc $recipient->host;
> $host = $self->qp->config("me")
>
> What? $host="calling_all_elvis"? Am I not seeing my $host's scope
> or was same $host assigned a value, then assigned a different value?
Look at the context and it becomes slightly clearer. The second one
is conditionally assigned if the first one resulted in "" (plus some
other checks). In perl, you may write either:
if (cond) { statements }
or
statement if cond;
It's mostly a matter of style and of which makes the intent clearer.
Multi-line statements would almost always be written in the first form,
but a single test is often clearer in the second form.
You can also express them as
cond && statement;
or
cond and statement;
These two different syntaxes have different effects in compound
conditionals, especially different orders of precedence (i.e. which
operations are done first). This sort of flexibility stems from the
way that Perl conditions are just another form of statement.
> Are we trapping an empty or non-existent "me" file, which is IP,
> rather than for a null sender to postmaster?
>
> if ($host eq "" && (lc $user eq "postmaster" || lc $user eq "abuse"));
We're trapping an empty host in the incoming address, and setting it to
"me" - i.e. empty hostname defaults to current host. But we only do
this for postmaster and abuse (stock qmail did this for any address, but
it was designed in a kindler gentler Internet).
>
> # Let's try this, I'm learning perl--
>
> #test
> $host="";
> $user="postmaster";
> if ($host eq "" && (lc $user eq "postmaster" || lc $user eq "abuse"));
> print &joe_ok( $recipient ) ;
> #syntax error at /tmp/levenshtein line 67, near ");"
> #Execution of /tmp/levenshtein aborted due to compilation errors.
The if(...) is unattached to any statement (preceding one is terminated
with ; and the if itself lacks a { ... } before its own semicolon ).
If you already know other languages, get hold of something like the Perl
Desktop Reference booklet, it has good summaries of the syntax.
> #denysoft_greylisting
> # Deny here (per-rcpt) unless this is a <> sender, for smtp probes
> return DENYSOFT, $msg if $sender->address;
>
> ...for all addresses when null sender, decline, but perhaps
> lurk about in alley near back door(lookup notes at data-post,
> unto the fourth generation). I can read that. rcpt_ok I don't
> get.
Yeah, all those poor spammy emails, just hanging around outside the
nightclub waiting for the bouncer to take pity on them and let them in ...
> Are all rfc-ignorant tests to postmaster@ and abuse@, all
> bounce tests, and all address tests, done from a null sender?
Don't know about rfc-ignorant, it's more a question of good practice.
It lets people contact you when they have trouble from your server,
even if they can't tell what domain it is officially handling.
> If the sender is not null, and user non-existent, would it
> be best to deny at rcpt, data, or data-post, as far as not
> feigning rfc-ignorance?
Don't think rfc-ignorant care about that either. You DENY the invalid
users at RCPT, and then DENY at DATA if there were no valid recipients.
Nick
