Does a REAL bounce, not an rfc-ignorant test, ever come from a null sender? Could I drop if sender is null, recipient not postmaster or abuse, at data hook, even if recipient is legit?
Nick Leverton wrote:
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
B> "second one" meaning the one from greylist, this one?--
return DENYSOFT, $msg if $sender->address;
which I find readable and prefer because it uses
less typing of (){} such as would be required the other way--if ( $sender->address ) { return DENYSOFT, $msg } ;but you don't mean by "second one" the following from rcpt_ok and that the second one only assigns if the first line of these two didn't work?--
my $host = lc $recipient->host;
$host = $self->qp->config("me")that to me just looks like the second one undoes the first, and uses $host with a different meaning __________________________
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 ).
That's what I thought, but that's the way it's currently written in rcpt_ok. Here it is, copy and pasted--
if ($host eq "" && (lc $user eq "postmaster" || lc $user eq "abuse"));
# Check if this recipient host is allowed
for my $allowed (@rcpt_hosts) {doesn't it look like that if ($host.......... ; goes nowhere i.e. is forgotten,
dead-end, not used? When I try running joe_ok in place of rcpt_ok
I'm going to re-write that conditional to make sure it OK's postmaster
and abuse@ with a null sender, or any sender if @rcpthost.
If you already know other languages, get hold of something like the Perl
Desktop Reference booklet, it has good summaries of the syntax.
I have that one and Learning Perl and some others. I had to read some hand-holding examples from Learning Perl, but now the reference would be useable since I know something.
#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
It was my impression that denying at data would be good, but rcpt_ok does not decline at rcpt and hook data and check its notes, and greylisting does or can decline at rcpt but then it hooks data-post instead of data to look at its notes and then deny(denysoft actually). So, data is the best place to deny in case of null sender and not postmaster or abuse, which ought to be the address check case.
It would be good to also look at whitelisting in the data hook, too, as greylisting does.
