Re: HELO checks give too high score together
At 23:16 21-02-2009, Benny Pedersen wrote: why does a smtp server have dynamic hostname alike in the first place ? What is a dynamic hostname? Regards, -sm
Re: HELO checks give too high score together
On Sat, February 21, 2009 19:11, Matt Kettler wrote: Very well, but you're also using a RBL with a known high risk of blocking nonspam email. http://rfc-ignorant.org/tools/lookup.php?domain=verizon.net your small isp should really have power enough to solve the above listning very easely, dont blame others using rfc-i for that please dont CC me, i read the maillist every day anyway -- http://localhost/ 100% uptime and 100% mirrored :)
Re: NO_RELAYS FP on relayed mail via IPv6
On Sun, February 22, 2009 01:11, Greg Troxel wrote: X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0.1 (fnord.ir.bbn.com [0.0.0.0]); Sat, 21 Feb 2009 18:44:45 -0500 (EST) greylist on remote ip 0.0.0.0 ? :) -- http://localhost/ 100% uptime and 100% mirrored :)
Re: HELO checks give too high score together
On Sun, February 22, 2009 09:15, SM wrote: What is a dynamic hostname? you dont know it either ? -- http://localhost/ 100% uptime and 100% mirrored :)
Re: HELO checks give too high score together
Benny Pedersen a écrit : On Sat, February 21, 2009 02:38, mouss wrote: Matt Kettler a écrit : Since you're bouncing any off-list emails because you reject my entire ISP, I'm going to drop out of aiding on this matter. probably a rule that considers vms173007pub.verizon.net as a dynamic name... why does a smtp server have dynamic hostname alike in the first place ? you mean generic? well, if you have a /16 network, will you select names one by one? some providers play games here and use a dictionary: $ host 93.74.0.105 105.0.74.93.in-addr.arpa domain name pointer latheness-pair.volia.net. $ host 93.74.0.106 106.0.74.93.in-addr.arpa domain name pointer practical-sheriff.volia.net. ... I find this practice worst. BTW, what will all these rdns checks become with IPv6? and why did the recipient not test spf ? my bet was wrong. he was rejecting based on rfc-ignorant listing. http://old.openspf.org/wizard.html?mydomain=verizon.netsubmit=Go! Fix your own domain's over-zealous behaviors first. 42
Re: HELO checks give too high score together
Benny Pedersen a écrit : On Sat, February 21, 2009 12:32, mouss wrote: rejecting because HELO does not match violates RFC. case open. I said invalid. a bare IP is invalid in helo, and has been since 822. just use all helo rules that postfix can do pr default is better gives the answer on this one I do reject these in postfix, but I don't reject them if they are in Received headers. rejecting based on headers should be avoided. if i remember postfix right: helo 127.0.0.1 is invalid helo [127.0.0.1] is valid it's not postfix, it's SMTP. the thing is that a lot of people read literal IP without checking the syntax definition. The RFC authors were too optimistic! maybe i am wroung again :)))
Re: HELO checks give too high score together
Benny Pedersen a écrit : On Sat, February 21, 2009 19:11, Matt Kettler wrote: Very well, but you're also using a RBL with a known high risk of blocking nonspam email. http://rfc-ignorant.org/tools/lookup.php?domain=verizon.net your small isp should really have power enough to solve the above listning very easely, dont blame others using rfc-i for that they will do, as son as these ones do: yahoo.com hotmail.com gmail.com aol.com de :) [snip]
Re: KnujOn - Registrars
On Tuesday, February 17, 2009, 10:47:00 PM, Lindsay Haisley wrote: I'm alarmed at some of the stuff GoDaddy did, completely on their own without orders from ICANN. See http://www.nodaddy.com. I don't want the domain name registration system turned into a nanny-state tool. It would be, if it were the government doing it. GoDaddy is a business, and a business has a right not to do business with abusers of the Internet, including cybercriminals. Cybercriminals can and apparently do take their business elsewhere, so it's pretty difficult to meaningfully compare GoDaddy to government censorship. Really the problem is with the apparently irresponsible domain registrars at the top of the Knujon list who seem perfectly happy to sell hundreds of thousands of domains to apparent criminals. The proper forum through which to lodge complaints against registrars is the ICANN, and ICANN needs to be held accountable for a _lot_ of strange stuff. It's a zoo out there! As much as I would like ICANN to do much more to fight abuse, ICANN really can't police the Internet. They don't route the networks, host the sites, pass the traffic, host the domain zone files, run everyone's mail servers, etc. It would be a bit like asking the registrar of voters to stop political corruption. The outright criminal ISPs and registrars (like Estdomains, Intercage, McColo, etc.) need to be kicked off the Internet, and the non-criminal ISPs and registrars need to do much more to stop abuse of their services and networks. Jeff C. -- Jeff Chan mailto:je...@surbl.org http://www.surbl.org/
Re: HELO checks give too high score together
At 01:20 22-02-2009, Benny Pedersen wrote: you dont know it either ? The term dynamic hostname is used in intermediate system routing. Regards, -sm
Re: HELO checks give too high score together
Benny Pedersen wrote: On Sat, February 21, 2009 19:11, Matt Kettler wrote: Very well, but you're also using a RBL with a known high risk of blocking nonspam email. http://rfc-ignorant.org/tools/lookup.php?domain=verizon.net your small isp should really have power enough to solve the above listning very easely, dont blame others using rfc-i for that Well, let's be clear here. I don't have a problem with people using RFCI, however they do need to realize the implications of doing so. RFCI has a *VERY* high rate of nonspam hits, because they, correctly, list many major ISPs. If you are sensitive to loosing mail, you should not use it as a SMTP layer reject, and score it very low, if at all, in a SA config. If you're fine with the implications, by all means use it. But do so knowing what it means. I was concerned about Matus, as he was complaining about a rare false positive from malformed HELOs causing loss of email. If he's concerned about such things, he should definitely NOT be using RFCI. If he's fine with loosing mail that's malformed or from badly managed domains, then the HELO bit should be acceptable to him as well. Matus is also free to do whatever he wants on his own servers. I do not particularly care if he will or will not accept email from verizon or other RFCI listed domains. That said, personally, I will not provide assistance to anyone I can't email directly for off-list issues. Hence my post withdrawing myself from offering support. If Matus doesn't want email from RFCI domains, that's fine. However, to me this also means he does not want assistance from anyone subscribed to those domains. Since I am a verzion subscriber out of necessity, I'm simply following that. Nothing more. There's plenty of other members of the SA team who may choose to help on this issue, I've just withdrawn myself. please dont CC me, i read the maillist every day anyway OK, I'll send you 50 copies as To instead of CC :-) (Kidding!!)
Re: false positive on X-Mailer: Microsoft Outlook
On Sat, 21 Feb 2009 16:51:29 +0100, Karsten Bräckelmann wrote: Sounds like bug 5962 and it's friends. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5962 Yeah, I read that one. The fix that was pushed for that bug however does not include the __HOTMAIL_BAYDAV_MSGID pattern as an exclusion for __FORGED_OUTLOOK_DOLLARS. Hmm, that fix also landed in the 3.2 branch, and even has been pushed out to the updates. So it isn't that one? No. That fix still does not use the __HOTMAIL_BAYDAV_MSGID pattern to validate the __FORGED_OUTLOOK_DOLLARS test. Brian, can you please check bugzilla for similar reports [1], That was a pretty vague search, hence all the hits. closed or still open, and file a new bug, if none of them is your issue? Yeah, I don't see anything better than bug 5692. So file a new bug. ~sigh~ Yet another bugzilla account I have to create/manage. I just get so tired of every website wanting me to register/log-in. No openid support either. Oh. Seems there is already an account with my e-mail id. I guess I already have one, but lord knows what the password is. So now for the password recovery rigmarole. Did I already express my displeasure with having to manage so many login accounts? I guess that's what openid is supposed to deal with. The plethora of accounts is out of hand now. Anyway, when I get the password change token, I will file a new bug. Sorry for the whine. Cheers, b.
Re: cpan question
Gene Heskett a écrit : On Saturday 21 February 2009, Bill Landry wrote: Gene Heskett wrote: [snip] Warning (usually harmless): 'YAML' not installed, will not store persistent state Running make install make test had returned bad status, won't install without force Failed during this command: JPC/Net-Ident-1.20.tar.gz: make_test NO This YAML does not appear to be available via yum if that's important Suggestions please? Many thanks too, I forgot to add that to the other message I sent a few minutes ago. My apologies. Try cpan install YAML (yes, in all caps). Bill 2 questions then. 1) what is it? http://en.wikipedia.org/wiki/YAML and 2) do I need it for SA? it's needed by perl Module::Build (Build and install Perl modules).
Re: cpan question
Since you don't need Net::Ident for SA, I'm going to say no. :) On Sat, Feb 21, 2009 at 10:28 PM, Gene Heskett gene.hesk...@verizon.net wrote: On Saturday 21 February 2009, Bill Landry wrote: Gene Heskett wrote: Using cpan, trying to install Net::Ident (the other bits except razor were nominal from the same source) Checking for Apache.pm... not found Writing Makefile for Net::Ident cp Ident.pm blib/lib/Net/Ident.pm Manifying blib/man3/Net::Ident.3pm JPC/Net-Ident-1.20.tar.gz /usr/bin/make -- OK Warning (usually harmless): 'YAML' not installed, will not store persistent state Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/0use.t Net::Ident::_export_hooks() called too early to check prototype at /root/.cpan/build/Net-Ident-1.20-FRTCAm/blib/lib/Net/Ident.pm line 29. t/0use.t ok t/apache.t .. Net::Ident::_export_hooks() called too early to check prototype at /root/.cpan/build/Net-Ident-1.20-FRTCAm/blib/lib/Net/Ident.pm line 29. t/apache.t .. skipped: (no reason given) t/compat.t .. Net::Ident::_export_hooks() called too early to check prototype at /root/.cpan/build/Net-Ident-1.20-FRTCAm/blib/lib/Net/Ident.pm line 29. t/compat.t .. skipped: (no reason given) t/Ident.t ... Net::Ident::_export_hooks() called too early to check prototype at /root/.cpan/build/Net-Ident-1.20-FRTCAm/blib/lib/Net/Ident.pm line 29. t/Ident.t ... Failed 3/8 subtests Test Summary Report --- t/Ident.t (Wstat: 0 Tests: 8 Failed: 3) Failed tests: 1-3 Files=4, Tests=9, 112 wallclock secs ( 0.04 usr 0.01 sys + 1.61 cusr 0.42 csys = 2.08 CPU) Result: FAIL Failed 1/4 test programs. 3/9 subtests failed. make: *** [test_dynamic] Error 255 JPC/Net-Ident-1.20.tar.gz /usr/bin/make test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports JPC/Net-Ident-1.20.tar.gz Warning (usually harmless): 'YAML' not installed, will not store persistent state Running make install make test had returned bad status, won't install without force Failed during this command: JPC/Net-Ident-1.20.tar.gz: make_test NO This YAML does not appear to be available via yum if that's important Suggestions please? Many thanks too, I forgot to add that to the other message I sent a few minutes ago. My apologies. Try cpan install YAML (yes, in all caps). Bill 2 questions then. 1) what is it? and 2) do I need it for SA? Thanks. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) ... relaxed in the manner of a man who has no need to put up a front of any kind. -- John Ball, Mark One: the Dummy
