It's fascinating to see how the mail server logs for the perl.org list server has changed over the years. Mostly because of all the new greylisting and rate limiting software. We don't mind the extra noise and server load on our side, qmail deals with it very efficiently. It's sad though to see all the broken software blocking our mail knowing there's someone on the other side who (presumably) wanted to get it but can't.
Greylisting software that gives us a temporary failure on the same mail for almost 2 weeks? A few other examples from the last hours of log files.
gmx.net / gmx.de's SPF checker is broken. Does anyone know a clueful admin there? If so, please tell them to fix their mail server if they want mail from the perl.org lists.
delivery 1875690: failure: 213.165.64.100 does not > like recipient. Remote host said: 553 5.7.1 {mx002} The recipient does > not accept mails from 'perl.org' over foreign mailservers. 553_5.7.1 According to the domain's SPF record your host > '63.251.223.186' is not a designated sender. Giving up on 213.165.64.100.
The SPF checker says our records are OK ...
Other domains / services that are blocking us includes gawab.biz, bpsc.com.pl, I think those are because our new IP block from internap is in some blacklist.
There are also some exceptionally stupid mailers that are blocking mail from us because the mail server says "HELO $somename" where $somename isn't the same name as the PTR record for the IP address gives.
Mostly I don't care, but it nags me that some people can't get the list mail or gets it slowly because of their mail administrators or server vendors. (I want to say because they use clueless mail admins or vendors, but maybe that's too harsh).
I'll bet there's a logic error in the SPF processor (although I'm not sure which one, the web interface, or the MTA's)
You've got:
I wonder if the include logic is saying "OK, I'll also add 'mx', 'ptr', and '~all' to my perl.org entry.
IOW, it isn't saying "does the PTR map to develooper.com", it's saying "does the PTR map to perl.org"
An interesting dilemma is that I haven't read the SPF spec in a couple months, but I'm not entirely sure that decision tree is actually clear.
Does the include logic imply that you change your "root" domain to the included domain, when doing the SPF checks against the included domain?
Does what I'm saying make any sense to you (not saying you agree with me, but just that I'm making it clear what I'm saying).
but I'm not entirely sure that decision tree is actually clear.
It's quite clear. The perl.org records are correct.
If you think about it for a minute then you'll realize that not changing the domain when evaluating the include will make a lot of the rules useless, hard to use or misleading.
:-)
- ask
I use their service, and I've noticed a while ago that I've not been receiving perl.org list mail anymore. That explains it, I guess. I just sent them a notice using their support form — I can only hope that it will help.
I just got this mail from their support:
> Liebes GMX-Mitglied,
>
> Die Technik hat angezeigt, da� das Problem der Auswertungen für die Blacklist, durch eine Anpassung der Software behoben wird.
> Wir bitten so lange um Geduld und bedanken uns herzlich für Ihren gewichtigen Hinweis.
In English:
> Dear GMX customer,
>
> The tech dept have signaled that the backlist interpretation problem will be corrected by a software adjustment.
> Please be patient in the meantime, and thank you sincerely for your grave notice.
It took them a while, but they got around to it. :-)
Aristotle, that's great! I'm glad I helped, even if just a little bit, to get them to fix it. :-)
- ask
Regarding perl.org mail servers, you are using the five-ten RBL, which seems to be very aggressive.
I run a Perl Mongers group (Lisbon.pm.org) and I'm setting up our new server (co-located at a big portuguese ISP). Unfortanly five-ten is currently blacklisting the network where my single IP address is located.
I'm setting up SPF for my server. Is it possible to make perl.org check SPF before five-ten and let the mail go in if SPF is ok?
This would solve the problems where a big network is blocked and other clients on the same network get blocked.
BTW, I know the mail admin for that ISP. They have been trying to solve the block for quite some time, but the five-ten people are really unresponsive. I cannot force the issue because this is a sponsored co-location, I don't pay them for bandwith and stuff. I do know that this ISP is active against spam originated in their network (the policy is to block port 25 outbound for any client that sends spam), and they even register their blocks of dialup space, so you can filter those. Dialups are also restricted from sending mail directly, as are residential ADSL. So they have a decent anti-spam policy.
Hope to clear this issue,
PS: I could have sent you a mail message, but it might get blocked :)
Melo, we probably use it a little in spamassassin, but we don't use that list on the SMTP level.
- ask
hmms.. It seems to be at the MTA level:
Yes, I contected spam@netcetera.dk, without responde :)
Best regards,