Re: [Exim] sender_verify_*callback rocks!

On Wed, 7 Feb 2001, Marc MERLIN wrote:

> I'm going through the exim 3.22 docs to find new goodies and stumbled on
> this:
> sender_verify_hosts_callback = *:!10.0.0.0/8
> sender_verify_callback_domains = *:!valinux.com
>
> This totally rocks!
>
> Yet, I may not be able to leave this on because having it on for 10mn showed
> that it unfortunately rejects legimitate mail:
> - web servers that send Email to subscriber lists but do not even have an
> smtp daemon to receive bounces
> - people who do not know about header sender masquerading and send mail with
> header sender addresses that resolve in DNS, but do not point to an smtp
> server.

Ugh. Both of these are invalid conditions, and would mean that a
non-delivery report would itself be undeliverable.

I have this on on my personal server, and I don't care to permit
reception of mail from web servers or people that send email with
nonreturnable envelope sender addresses as I do not consider either of
these cases legitimate. (Even if the mail is not UCE/SPAM, it is still
'broken' and the operator of the website or the person needs to learn
ho to do it right if they want to send mail to my server - I don't care
to receive mail from clueless sites)


>
> I'm already getting quite a bit of pressure from users because I have:
> sender_verify = true
> sender_verify_reject = true
> headers_check_syntax = true
> headers_sender_verify = true
> headers_checks_fail = true
>
> However, I'm not the only one to have those on, so there is less legitimate
> mail that's being refused by this.
>
> Now comes the $10,000 question:
> Is there any way to do verifies depending on who the receipient is.
> In other words, if some user says "I cannot afford to miss any mail, even if
> it means I get 3 times as much spam", is there a way to have the above
> checks only active if the rcpt to: user is in verify_user_list or something?

Hrm.. Now thats a good question. Probably would be rather difficlt,
becuase the check is done at MAIL FROM: time..


>
> Thanks
> Marc
>

--