> > IIRC, exim does an rDNS lookup then does another DNS lookup on that
> > name.
> > If the IP of the connecting host isn't listed in the 2nd lookup, the
> > rDNS is
> > assumed to be spoofed and not used. So this would be a non-issue.
> > (Unless
> > I misunderstood what you wrote)
>
> Are you talking about Exim's "verify = helo" mechanism (or behaviour in
> the case of "helo_verify_hosts = true")? If so, this has no bearing on
> this discussion - this was about allow relaying based on the sender's
> domain (how this domain would be deducted, was a topic of discussion).
Nope, I'm not.
> If on the other hand you are saying that the variable $sender_host_name
> (which, as you know, is deducted by way of resolving the peer's IP
> address) is empty unless the host name can be verified in the forward
> direction, then you have a point. However, according to
> 'spec.txt.gz', this does not seem to be the case.
This is what I was refering to. I don't know of any IPs off hand that have
rDNS but incorrect DNS to test this.
> >> - when a lookup of the remote IP address (correctly) yields
> >> "spammer.biz", but the owner of "spammer.biz" adds an MX record to his
> >> own domain pointing to "mx.rahul.com".
> >
> > Oooh =)
>
> There is another potential problem associated with this, albeit a less
> likely one. Many installations (mostly Exim 3 installations) allow
> relaying to any domain for which the local host is an MX. So a
> spammer could add the following MX records to his zone:
>
> @ IN MX 1 mta.victim.domain.
> @ IN MX 2 mta.your.domain.
>
> If your MTA was configured to allow relaying to hosts for which you are
> an MX, you would happily forward mails to 'mta.victim.domain.'.
I knew about this and I decided it was not a good idea to do this.
--
Lab tests show that use of micro$oft causes cancer in lab animals
