I know this is an old thread, but I'm having the same problem with MX's that
reject MAIL FROM: <> being blocked
Was there anything resolved regarding this issue - the callout verification
stops a LOT of spam, and I am unwilling to turn it off
Maintaining a whitelist is time consuming and not practical - our users are
getting very upset when legit mail is stopped because of this
The idea below is similar to the solution I am looking for - how can I
incorporate this?
>My idea would be to _first_ try "MAIL FROM:<>", and only if that was
>rejected try other values. Any site not accepting "MAIL FROM:<>" isn't
>very likely to be doing callbacks. Also, It has actually occured to me
>that the best value to use in the "MAIL FROM" (if <> is rejected) is the
>same address that you are trying to verify. It is VERY unlikely that a
>site will reject "MAIL FROM:<>", do callbacks, *AND* do callbacks on its
>OWN addresses.
Please help!!!
Ian Toogood
On Fri, 14 Jun 2002, Marc MERLIN wrote:
> On Mon, Jun 10, 2002 at 09:39:07AM +0100, Philip Hazel wrote:
> > On Fri, 7 Jun 2002, Dave C. wrote:
> >
> > > Basically a:
> > >
> > > "If the MX for the sending domain rejects MAIL FROM: <>, we wont
accept
> > > the mail at all"
> > >
> > > policy is a little bit too hard-line for our customers to accept (even
> > > if it is the RFC-compliant way), but I could get away with a policy
of:
> > >
> > > "If the MX for the sender domain rejects a RCPT TO: for the sending
> > > address, regardless of wether the MAIL FROM: was <>, or
> > > postmaster@ourdomain, we wont accept the mail"
> > >
> > > and still block lots of spam...
> >
> > I have added this idea added to the Wish List.
>
> Note that I coded that back in the exim 3 days, and then realized how
wrong
> it was, because
>
> 1) people who refuse null envelope do _not_ deserve to have their mail
> accepted
I was aware of that at the time you did it, and at the time agreed that
it was wrong. On my personal server, I run standard callbacks. Since my
only customers are myself and a family member or two, I can afford to do
this.
However, on the at the ISP I work for, we can't afford to piss off our
customers who expect to receive mail from their
associates/customers/etc. They don't want to hear about some RFC, they
want to get their mail.
> 2) More importantly, you now connect to me as callbackuser@yoursite.
> Great, I run he same option as you do, and guess what happens?
> I trigger a callback to you with callbackuser2@mysite.
> So what do you do? Well, you do a callback to me
> Get the idea... ?
My idea would be to _first_ try "MAIL FROM:<>", and only if that was
rejected try other values. Any site not accepting "MAIL FROM:<>" isn't
very likely to be doing callbacks. Also, It has actually occured to me
that the best value to use in the "MAIL FROM" (if <> is rejected) is the
same address that you are trying to verify. It is VERY unlikely that a
site will reject "MAIL FROM:<>", do callbacks, *AND* do callbacks on its
OWN addresses.
> If you really have to accept mail from a broken site, just stick them in
> your do not callback exclude list.
If it was the sending sites that were complaining, that would be fine.
But its OUR customers. We have way too much mail volume to continuously
monitor this, and if we wait until our customer is calling us, they are
already upset about the mail they were expecting not being accepted by
us.
> (after having suitably yelled at them, and pointed them to
> http://marc.merlins.org/netrants/nullenvelope.txt
> or equivalent)
My goal here is not necesarrily trying to enforce RFC-compliance on the
world, my goal is to try and block some percentage of the spam from
addreses that are completely forged, without blocking non-spammy email
from servers that might happen not to be 100% RFC compliant. (I *do*
agree that these servers are horribly broken, I just can't piss off our
customers in order to get the server admins to change their setup) Since
*I* dont accept RCPT TO: to addresses that I havent verifies are valid,
I dont expect to have too many (or any, really) stuck bounces as a
result.
Perhaps if there was a way of detecting that <> was rejected in a filter
or something, and being able to send a gripe to postmaster@thedomain
would be good.
My choices are:
1. Do callbacks, first trying <>, then another address in "MAIL FROM:"
Only block if we get to the RCPT, and *it* is rejected.
2. Not do callbacks at all.
At the moment I am doing 2, but I would really prefer 1.
Doing callbacks, blocking mail both from sites that accept <> and reject
the recipient, as well as all mail from sites that block <>, is *NOT* a
choice I can make.
At this point I will probably try to start from your patch, and modify
it to work as I described. If I do so, I will contribute it back just in
case anyone else is in a similar boat.
