On Thu, Mar 03, 2005 at 07:39:18AM -0500, Bob wrote:
> 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?
No, all bounces always come from <>.
1. > >>my $host = lc $recipient->host;
2. > >>$host = $self->qp->config("me")
> B> "second one" meaning the one from greylist, this one?--
>
> return DENYSOFT, $msg if $sender->address;
No, meaning the second one of the two lines of code you wrote and asked
about in the paragraph I was responding to, which I've numbered above
to help make it clearer.
> 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 } ;
Like I said, it's down to style.
> 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?--
Yes I do mean exactly that.
> 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
Count the semicolons. The second (of the two lines of code that you
have just quoted) hasn't got one, that tells you it's not the end of the
statement. The "if" on the next line is part of that second statement.
> 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.
Forget the exact addresses, they're irrelevant. These are the rules:
You should not deny at MAIL FROM. You may deny at RCPT TO for any reason,
including a bad sender. What you do at DATA is up to you, but it makes
sense to deny there if you had either a bad sender, or no good recipients.
Most MTAs won't continue to DATA if you rejected all recipients, but
some do (especially spamware).
Accepting earlier then denying at DATA is possible I suppose, but I
can't think why you'd want to confuse the sending MTA like that.
If some plugins do things differently it's cos they're either suboptimal,
buggy or written to handle a special case.
> It would be good to also look at whitelisting in the data hook,
> too, as greylisting does.
Whitelisting needs adding in each plugin separately. Many of them deny
at either connection, HELO or RCPT.
Nick
--
http://www.leverton.org/ ... So express yourself
