We've noticed that Trend Micro "mail-abuse.com" just "assumes" ips are
dynamic by default, adds them to their stupid list, and then expects US to
update -their- database -for them- for free to get them off their stupid
list again. (as ofcourse our customers bug us when their email doesn't
arrive on the other side, hell they even tell the customers to bug -us-
because they just assume that working, rfc compliant, reverse dns that
just-so-happens to be automatically generated would indicate dynamic ip
space.. (or actually because they think using customer-pressure is a good
way to get isps to maintain their product (their database) for them for
free).
we've basically told them to go to hell and we advise everyone who uses
their RBL lists to remove their RBLs from their configs, as what we have
here is a mismanaged list.
as ofcourse we neither intend to change our perfectly fine
"aXXX-XXX-XXX-XXX.cb3rob.net." reverse dns scheme, nor maintain their
database for free for them..
they've probably done the same with other isps that use simular schemes.
Which is it? By default or because it looks automatically generated?
By default would seem to be a problem. Automatically generated, not so much.
If you haven't made the effort to set up and secure a mail server then
you shouldn't be talking smtp to the hosts mail-abuse.com is used to
protect. If you haven't bothered to set the reverse DNS to match your
server's name then you haven't made the effort, at least not with a
modicum of competence.
Is there an RFC detailing that specific text strings must be used for static
v. dynamic addresses?
I can understanding keeping rDNS in sync, but that's not the issue here, is
it?
There is no RFC that I'm aware of, but I'd say it's pretty common for
PTR records that contain the IP address itself to be regarded as dynamic
or mass generated. Both of those qualities can indicate the source is
not serious about running a mail server. If one chooses this DNS scheme
for their mail servers they're playing with fire.
But really, the rdns should just clearly indicate the use of the IPs if you're going to do generic/script generated rDNS.
a84-22-96-117.cb3rob.net doesn't tell me anything except that this IP is part of a large block of generic rDNS. Something like a84-22-96-117.static.cb3rob.net at least indicates that the IPs are static, while a84-22-96-117.dynamic.cb3rob.net clearly indicates the space is dynamic. Doing this takes much of the guesswork out of it when others on the net need to decide "should we accept mail from this IP?" Keeping the indicator as close as possible to the domain helps out for things that do simple string matching. i.e. with a84-22-96-117.dynamic.cb3rob.net, it's a safe bet I don't want mail from *.dynamic.cb3rob.net. That's easier to block (with a single rule) than dynamic.a84-22-96-117.cb3rob.net.
Still, if you're serious about getting mail from that IP delivered, its far better to have the PTR = the domain or system name than some generic string roughly equivalent to all the neighboring IP PTRs.
perhaps his ISP does something dumb (like verizon does) and only
delegates to one server, which may/may-not be available at the time of
the incident? (or is blocked/down/something-else from the observation
point)
btw: why won't verizon (fios/dsl folk I mean) delegate to more than 1
customer DNS server??
we've basically told them to go to hell and we advise everyone who uses
their RBL lists to remove their RBLs from their configs, as what we have
here is a mismanaged list.
Same thing we told them (snippit of my response below).
Cheers,
Michael Holstein
Cleveland State University
[Trend] : But we will maintain our list as we see appropriate to
protect our customer from spam.
Suit yourself .. but you can't arbitrarily force the Internet as a whole
to adopt an unwritten standard just to make your lives easier. If we
encounter problems with our end-users and not being able to deliver
email reliably to one of your customers, we'll have them call you, since
we're complying with all the various SPAM prevention standards that
presently exist.
We hate SPAM as much as the next guy, but we're not going to install
"Bob's SPAM module" anymore than we're going to do some custom DNS
foolishness for Trend.
Suit yourself .. but you can't arbitrarily force the Internet as a whole
to adopt an unwritten standard just to make your lives easier. If we
encounter problems with our end-users and not being able to deliver
email reliably to one of your customers, we'll have them call you, since
we're complying with all the various SPAM prevention standards that
presently exist.
One could argue that you are *not* complying by using a generic PTR for a mail server. Some would say that a serious mail server should have proper DNS records, others will say that you should accept mail from any IP no matter what.
One could argue that you are *not* complying by using a generic PTR
for a mail server. Some would say that a serious mail server should
have proper DNS records, others will say that you should accept mail
from any IP no matter what.
No, we do have it correct .. they wanted us to fix all the *other* ones
(that can't even send mail because they're firewalled from doing so) ..
$ dig -t mx csuohio.edu
[..]
;; ANSWER SECTION:
csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu.
[..]
;; ADDITIONAL SECTION:
antispam5.csuohio.edu. 10800 IN A 137.148.19.13
antispam4.csuohio.edu. 10800 IN A 137.148.18.13
antispam3.csuohio.edu. 10800 IN A 137.148.18.21
antispam2.csuohio.edu. 10800 IN A 137.148.19.12
(and)
13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu.
13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu.
21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu.
12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu.
No, we do have it correct .. they wanted us to fix all the *other* ones
(that can't even send mail because they're firewalled from doing so) ..
$ dig -t mx csuohio.edu
[..]
;; ANSWER SECTION:
csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu.
[..]
;; ADDITIONAL SECTION:
antispam5.csuohio.edu. 10800 IN A 137.148.19.13
antispam4.csuohio.edu. 10800 IN A 137.148.18.13
antispam3.csuohio.edu. 10800 IN A 137.148.18.21
antispam2.csuohio.edu. 10800 IN A 137.148.19.12
(and)
13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu.
13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu.
21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu.
12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu.
Ah, I must have misread. Yeah that's pretty much the accepted way to do DNS for mail servers.
To be clear: because the legitimate mailserver with a proper non-generic
reverse was in a block with other generic reverses, they blacklisted you?
That's egregiously harsh.
SORBS was blocking a customer for a generic reverse entry, I gave them a legit
looking reverse (that fwds properly too), solved, if a bit irritating. To
require the whole BLOCK be totally legit is too much.
Especially if they think the "block" is a /24 and you think it's a /27 and
somebody else entirely has the /27 either side of you. I've seen *that*
sort of brain damage far too often even in recent years. RFC1519 was 16
frikking years ago, and some people *still* aren't on board.
;; ANSWER SECTION:
csuohio.edu. 10800 IN MX 10 antispam5.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam4.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam3.csuohio.edu.
csuohio.edu. 10800 IN MX 10 antispam2.csuohio.edu.
(and)
13.19.148.137.in-addr.arpa domain name pointer antispam5.csuohio.edu.
13.18.148.137.in-addr.arpa domain name pointer antispam4.csuohio.edu.
21.18.148.137.in-addr.arpa domain name pointer antispam3.csuohio.edu.
12.19.148.137.in-addr.arpa domain name pointer antispam2.csuohio.edu.
All of the DNSBLs I know are about outbound mail hosts, not inbound
ones. What are your sending hosts called?
All of the DNSBLs I know are about outbound mail hosts, not inbound
ones. What are your sending hosts called?
Outbound goes through the same 4 boxes. We used to split it up (2 at
MX10, 2 at MX20 .. reversed for outbound) but for capital
(licensing/hardware) reasons we decided to do in/out through the same
system. This is just "first touch" on the way in and "last touch" on the
way out.
We also have spfv1 records defined (albeit a rather permissive "ptr
~all") .. but as I mentioned, the firewall disallows smtp to anywhere
but appropriate hosts. We do still allow smtps and submission to
accommodate folks that travel, as we haven't (yet) had a problem with
bots using either of those services.
My beef with Trend was that they were in essence telling us to re-do DNS
on our /16 because they didn't like the way we did it .. despite the
mail part (the one that matters) being technically correct by most
everyone else's standards. Personally, I think this is just so they can
have a "big list" when they sell it (.. our DNSBL has $x million more
entries than $competitor..).
To be clear: because the legitimate mailserver with a proper non-generic
reverse was in a block with other generic reverses, they blacklisted you?
Their initial email said :
[snip]
Trend Micro Notification: 137.148.0.0/16 added to DUL
[snip]
and then went on to say :
[snip]
To work with us, please generate the following three lists:
1) TOTAL ALLOCATED SPACE – in CIDR format
Please include all information for the space you announce.
The total of Static and Dynamic space must equal the
Total Allocated Space.
2) DYNAMIC SPACE LIST - in CIDR format
3) STATIC SPACE LIST - in CIDR Format
[snip]
Which was, of course, impossible .. since trunking a VLAN across the
core just to have all the printers in the same /22 would be silly.
After some arguing back-and-forth .. they (Trend) said :
[snip]
Also we don't see the IP address as static as we see the generic naming convention of
*csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static.
[snip]
Seriously .. we're a college campus, not a colo. Org-Abuse roles is defined (and valid) and real people read the RFC2142 required addresses. What more do these people want?
(Note: they did eventually say "okay, we see the MXs as static so those aren't listed" .. but not without some discussion).
[snip]
Trend Micro Notification: 137.148.0.0/16 added to DUL
[snip]
That's just lazy/sloppy. A quick survey of your /16 suggests that the majority of it has PTRs in the format of csu-137-148-36-160.csuohio.edu, which looks like generic rDNS...but assuming that a university has a /16 of dynamic space is just dumb...and in that quick survey of your /16, there are obvious pockets of non-generic rDNS.
To work with us, please generate the following three lists:
1) TOTAL ALLOCATED SPACE in CIDR format
Please include all information for the space you announce.
The total of Static and Dynamic space must equal the
Total Allocated Space.
2) DYNAMIC SPACE LIST - in CIDR format
3) STATIC SPACE LIST - in CIDR Format
[snip]
Which was, of course, impossible .. since trunking a VLAN across the
core just to have all the printers in the same /22 would be silly.
Maybe you misunderstood them? What's trunking a VLAN across the core for a printers subnet have to do with anything? They were asking you to tell them which of your subnets are dynamic and which are static, presumably so they could remove your /16 and list just the bits of it that really are dynamic or otherwise appropriate for their list.
Also we don't see the IP address as static as we see the generic naming convention of *csuohio.edu* as dynamic and the WHOIS information doesn't indicate that the space is static. [snip]
It really sounds like you were dealing with an idiot and would have done well to see if there was any other individual at Trend/MAPS with maintenance access to their DUL.
1) TOTAL ALLOCATED SPACE � in CIDR format
Please include all information for the space you announce.
The total of Static and Dynamic space must equal the
Total Allocated Space.
2) DYNAMIC SPACE LIST - in CIDR format
3) STATIC SPACE LIST - in CIDR Format
[snip]
Which was, of course, impossible .. since trunking a VLAN across the
core just to have all the printers in the same /22 would be silly.
Is your network setup so chaotic that you don't know what address
chunks are allocated by DHCP or PPP? They're not asking you to
aggregate your printers, they're just asking which ranges are dynamic,
since mail directly from dynamic ranges is about 99.999% bot spam.
If you really don't know what's dynamic, I can't say I blame them
for assuming the worst.
Each network can decide how they want to run their network, and Trend Micro
can make any list they like, but if cb3rob.net wants to send e-mail to other
networks that use Trend Micro's list for spam control, cb3rob.net will have
to decide whether to comply with the other network's rules, even if those
rules seem unreasonable.
Two sides of an SP's coin: I want to maximize my e-mail servers'
deliverability, so I make sure those have appropriately named PTRs and make
sure that outbound messages aren't spammy; I also want to restrict
deliverability of e-mail from my dynamic space, so I have appropriately
named PTRs so that others don't have to guess what kind of host it is.
Perhaps I forgot those customers with static hosts and that want to send
e-mail -- I make sure those PTRs are well-named, too.
