It would appear that you are hosting an SMTP server that is attempting to perform delivery directly to Internet hosts. The IP you're hosting that server from, a Comcast client IP address, is on the Spamhaus Policy Block List (PBL). That's the root cause of your problem.
Comcast has registered their client IP addresses with Spamhaus because, as a matter of policy, Comcast doesn't want their Customers sending email directly to the Internet from servers they're hosting themselves. The Spamhaus link you provided in your posting directs:
If you are a Comcast Commercial
Services customer and need support,
please contact
[email protected]
Presumably, this means that some commerical Customers can be assigned IP addresses that aren't subject to the "no sending email directly to the Internet" policy. Their commerical IP address blocks probably aren't registered with the Spamhaus PBL.
I'd be curious to know where you got the "...way to bypass this filter is to enable SMTP-AUTH..." guidance. I think you may be having a conceptual issue, insofar as such guidance was probably "...use SMTP-AUTH and send your mail throguh Comcast's SMTP servers."
The issue re: D-Link bouncing the mail isn't related to whether you've authenticated to your SMTP server or not-- it's that your SMTP server is sending mail to D-Link from an IP address that, because D-Link chooses to use what Spamhaus says about the IP as trusted, and because Comcast listed the IP in the Spamhaus PBL, D-Link finds unacceptable.
Had you configured your email client or SMTP server to deliver your outbound mail to a Comcast SMTP server (likely requiring your SMTP client or SMTP server to perform SMTP-AUTH while communicating with the Comcast SMTP server to prove that you're authorized to perform such relaying), the eventual communication with D-Link's server would come from an IP address assigned to a Comcast email server, which wouldn't be listed on a Spamhaus black-list and, as such, wouldn't be bounced by D-Link. Basically, you give the email to Comcast's server, and it delivers it to the final destination. This is known, in SMTP parlance, as "relaying", and in 2009 (almost 2010), all SMTP relaying should require authentication.
To put this in terms of a real-world analogy: You'd like to deliver a piece of postal mail to D-Link. They're not going to let you just walk into their building and drop off a package, though. They only accept packages from authorized courier services, like FedEx. As such, even though you are physically capable of carrying your package right up to D-Link's front door yourself, they're not going to let you in. If you hand off your package to FedEx (proving, by way of paying them, that you're a legitimate user of their courier serivces), then D-Link will happily accept the package.
This article from Comcast describes configuring Outlook Express to receive email from a 3rd-party POP3 server, but to relay outgoing mail via Comcast's SMTP servers. This is, generally speaking, the configuration you'd be looking for w/ either your email client or your SMTP server.
If you don't want to relay messages through Comcast, you always have the option to contract with another party to accept and deliver your mail. (Analagously, you can use UPS or the local postal service if you don't want to use FedEx.) Services like Mailhop Outbound from Dynamic Network Services, allow you to submit email to their server computers via a variety of TCP ports (in case you're using a provider that won't allow you to communicate with the rest of the Internet using TCP port 25), and their servers will perform final delivery to the recipient server. Of course, this service costs money, since you're using their computing and bandwidth resources.
You're not going to have a lot of success hosting an SMTP server from a Comcast client IP like you've got. Looking into finding an SMTP server that you can relay messages through and you'll have a better time of email delivery.
Edit:
I see that riker.tchmachines.com resolves to 208.76.82.134. It's unclear to me, then, why D-Link's mail server is complaining about riker.tchmachines.com but showing the IP address that it looked-up in the PBL as being what is presumably the Comcast IP address (24.5.171.149) you've submitted the message to riker.tchmachines.com from.
For kicks, I sent a message to the same recipient at dlink.com through my hosted "Mailhop Outbound" service at Dynamic Network Services, and it bounced in the same way, claiming that the DNS name "mho-02-ewr.mailhop.org" is listed on the Spamhaus PBL, but listing the IP that I submitted the item to Mailhop Outbound from (which is PBL'd, because it's a Time Warner dynamic client IP) as the blacklisted IP.
I also received a similiar response relaying through an SMTP server at Time Warner, and found that I received the same type of reply, with the "550 Service unavailable; ..." referencing the DNS name of a Time Warner SMTP server, but the Spamhaus URL referencing the IP address of the Time Warner client IP I submitted the item to Time Warner's SMTP server from.
D-Link's mail server (which banners as "220 The Drawbridge"... Oooooh!) is clearly broken. It would appear that they're checking each host in the "Received" headers against the Spamhaus blacklist. Considering the point of the PBL is to get users to send mail through authorized SMTP servers this is clearly the wrong behaviour on D-Link's part.
Good luck getting word to anybody there that their configuration is wrong. >sigh<
