Thanks for the feedback and of course for the software! What I like most with spamdyke is the "set it and forget it" feeling, which is a bit disturbed by knowing about the (rare) false positive cases with rdns answers larger than 512 byte.
The whitelist will do it's job with the known cases of course. Due to haggybear's plesk pluging, having a look at what spamdyke is doing is fun anyway, since you can see how great it's working! Roland -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Sam Clippinger Gesendet: Donnerstag, 5. März 2009 04:44 An: spamdyke users Betreff: Re: [spamdyke-users] also getting DENIED_RDNS_MISSING with valid rDNS I'm really sorry for the late reply on this, a couple of projects have been occupying all of my free time lately... I think your description of the symptom actually identifies the problem. In its current form, spamdyke doesn't fall back to TCP for DNS queries if the packets are too large. I think I read somewhere that DNS over TCP was only used for domain transfers anyway, so I never followed up to figure out how to implement it. Now that I have a test case, I'll look into it. For the moment, however, whitelisting the IP address is probably the only workaround. Sorry. -- Sam Clippinger Roland Moelle wrote: > I'm running Spamdyke 4.0.8 at my Ubuntu-Server: > > Distributor ID: Ubuntu > Description: Ubuntu 6.06.2 LTS > Release: 6.06 > Codename: dapper > Everything worked fine so far and it's doing a good job, but lately I > saw that some Mails I was waiting for were rejected as > "DENIED_RDNS_MISSING", although the sender is supposed to know how to > configure his mail server. > > The rejected mail came from IP 62.175.163.179. Manually testing the > reverse DNS entries at the server console showed proper entries: > > **************************************************************** > dig -t ptr 179.163.157.62.in-addr.arpa > ;; Warning: Message parser reports malformed message packet. > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.3.2 <<>> -t ptr 179.163.157.62.in-addr.arpa > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54169 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;179.163.157.62.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachmedien.it. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachmedien.biz. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachinformation.biz. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachinformation.net. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachwerbung.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.info-at-click.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.vu-abo.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR > mail.fachpresseklimaindex.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR > mail.fachpresse-klimaindex.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.mediaskop.net. > 179.163.157.62.in-addr.arpa. 172800 IN PTR > mail.rheingauer-verlegertag.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.vertriebsunion.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachmedien.net. > 179.163.157.62.in-addr.arpa. 172800 IN PTR > mail.ja-zur-fachzeitschrift.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR > mail.mediaservice-plauen.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.vushop.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.vuabo.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.vu-shop.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.info-at-klick.de. > 179.163.157.62.in-addr.arpa. 172800 IN PTR mail.fachmedien.eu. > > ;; Query time: 71 msec > ;; SERVER: 80.237.128.144#53(80.237.128.144) > ;; WHEN: Sat Feb 21 12:38:42 2009 > ;; MSG SIZE rcvd: 715 > **************************************************************** > > The syslog entries while the mail was blocked are as follows: > > **************************************************************** > Feb 16 16:00:01 lvpsMyServerIpHere /USR/SBIN/CRON[12119]: (www-data) > CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf > -a -r /var/log/apache/access.log ] && /usr/lib/cgi-bin/awstats.pl > -config=awstats -update >/dev/null) > Feb 16 16:00:34 lvpsMyServerIpHere relaylock: > /var/qmail/bin/relaylock: mail from 62.157.163.179:45408 > (mail.rheingauer-verlegertag.de) > Feb 16 16:01:04 lvpsMyServerIpHere spamdyke[15764]: > DENIED_RDNS_MISSING from: [email protected] > <mailto:[email protected]> to: [email protected] > <mailto:[email protected]>_ origin_ip: 62.157.163.179 origin_rdns: (unknown) > auth: (unknown) > > **************************************************************** > > So as far as I can see at 16:00:34 the server is able to resolve the > rDNS entry, but 30 seconds later spamdykes claims that there wasn't a > correct rDNS entry for the same IP. The only thing that looks special > to me is that there are 20 domains hosted at the source server and > therefore the answer section is rather long (too long for UDP mode, > but in TCP mode everything is fine). > I was forced to add the sender to the white list in order to receive > its mail. > Any help to solve the problem is strongly appreciated. > > Roland > ---------------------------------------------------------------------- > -- > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
