Am 03.10.2016 um 00:08 schrieb David Ford:
On 2016-10-02 21:22, Reindl Harald wrote:
Am 02.10.2016 um 22:42 schrieb David Ford:
On 2016-10-02 12:59, Reindl Harald wrote:
IOW, can a given *IP* appear in more than one A record? I realize
that this does have the problem that the reverses would resolve to
hostX not
test
on IP should only have on PTR - period
avoid anything else than PTR/A-matching if the machine is supposed to
send outbound mail
it is very helpful to have multiple PTR records for an IP on a mail
server so anti-spam engines can accurately make fully verified forward
and reverse lookups not just for DNS but also certificate verification.
which is *exactly* what you break with *multiple* PTR records for a
single IP - seems you don't understand what
https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS really means
no, it exactly doesn't break. it exactly applies to -every- domain
served by that mail server with each domain serviced having fully
verified forward and backward reachable chain regardless of how many A
or PTR (and even CNAME) records exist in RR answers, each having their
own domain set in their MX record.
no - a mailserver needs exactly *one* IP address with *one* matching PTR
record since it's not a webserver serving different document roots and
hence you need only *one* certificate for TLS while without DANE TLS in
case of smtp is opportunistic anyways
besides that receiveing mail has nothing to do with the senders MX at
all, really nothing except sender-verifciation in very rare justified
cases to not make side attacks to the victims of sender-forging
but it's off-topic here
mail servers that can't correctly emit the right EHLO for outbound email
should remain in the 1990s.
yes, and your EHLO matches the A record of your IP
which of the multiple PTR's should the receiving server use?
guess what: it uses a random one
one time it matches your EHLO, the next time not
PTR lookup of 1.2.3.4 returns all RR for a.foo.com, b.zee.com,
c.lark.com, where each of these also resolves to 1.2.3.4. it is your
-client- that determines what to do with each RR after it has received
the answer. if your MTA or milter software cannot iterate all the RR
records to find the matching hostname, you should get a better MTA or
milter.
congratulations: you are playing lottery
you're only playing the lottery with MTAs and anti-spam services that
are too naive to understand that multiple records can exist in a single
RR answer and it should utilize all the records.
nonsense - when i reject highly suspect
dynamic-xx.xx.xx.xx.some-isp.example.com and "mail.example.net" is
another PTR of this IP the sender is a fool, that's it
go ahead, subscribe on the postfix mailing list abnd explain Wietse that
his implementation is naive because you know better - i am curious how
far you get....
and yes i had cases where we blocked email because
check_reverse_client_hostname_access when the mailadmin did request a
PTR and the ISP was too dumb to remove the generic one which ended in
some mails hit rules and others not
the notion of a 1-to-1 relationship between A and PTR is a relic of
history. the internet is always evolving and sharing of IPs to host
multiple domains has been around for a long time and increasing
considerably as people try to stretch IPv4 further while waiting for
their upstream to provide IPv6. there are a considerable number of
existing servers that use a many-to-many relationship of A and PTR
records and it's only going to increase as more customers request their
IPs resolve to all of their hosted domains.
nonsense
the cat and mouse game of spam is always ratcheting upward. as mail
providers get better at blocking half-assed setups due to spam, sending
providers improve their configuration to rise above the spammers. with
the simple fully verified FR of IP/PTR/EHLO, i block more than 87% of
incoming spam right at the edge. i have very very few false positives.
87% is not very impressive
many-to-many works, and i support it's use. i also support the adoption
of MTAs and milters capable of handling modern many-to-many instead of
breaking because they expect a legacy 1-to-1 or 1-to-many RR
so you are happy to play troublemaker - fine yor *your* setups but don't
recommend not following best practices to others
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
