Problems with registration / confirm mails rejected by Ironport
We have tried to register a group of colleagues to use Zotero. About 50% did not recive the confirmation email and due to that they can not login and use it. Some have tried it 3-4 times without sucess.
As our IT department now found out, the DNS to IP resolution from zotero.org is changing from day to day, some days it is working, on some not and then all the mails are rejected by our Cisco Ironport server:
Example:
Fri Jun 20 14:50:54 2014 Info: New SMTP ICID 31230493 interface Data 1 (x.x.x.x) address 50.19.225.228 reverse dns host zotero.org verified yes
Jun 25 04:10:25 2014 Info: New SMTP ICID 23448348 interface Data 1 (x.x.x.x) address 50.19.225.228 reverse dns host zotero.org verified no
They say the problem is on the Zotero side.
We have already tried to get in contact on "registration@zotero.org" but no reaction (or blocked?)
Maybe someone of the IT.team can have a look into this topic.
We really would like to use Zotero in a big EU project, but to do so we need logins :)
Best wishes
JST
As our IT department now found out, the DNS to IP resolution from zotero.org is changing from day to day, some days it is working, on some not and then all the mails are rejected by our Cisco Ironport server:
Example:
Fri Jun 20 14:50:54 2014 Info: New SMTP ICID 31230493 interface Data 1 (x.x.x.x) address 50.19.225.228 reverse dns host zotero.org verified yes
Jun 25 04:10:25 2014 Info: New SMTP ICID 23448348 interface Data 1 (x.x.x.x) address 50.19.225.228 reverse dns host zotero.org verified no
They say the problem is on the Zotero side.
We have already tried to get in contact on "registration@zotero.org" but no reaction (or blocked?)
Maybe someone of the IT.team can have a look into this topic.
We really would like to use Zotero in a big EU project, but to do so we need logins :)
Best wishes
JST
However, the zotero.org domain has a Sender Policy Framework (SPF) record that declares both IP addresses as valid for outgoing @zotero.org email, which should remove all doubt that the front-facing servers are legitimate senders for that domain. That should override the much less reliable FCrDNS check. While what Amazon Route 53 does is fairly uncommon, there are all sorts of reasons that an FCrDNS check might fail for legitimate servers, so when a better option (e.g., SPF) is available, it doesn't make sense to reject based on FCrDNS alone.
We can consider making some changes so that this test will pass, but any solution would require additional resources on our end and/or reduced redundancy for really no good reason. I'd recommend pointing your IT department to this thread and seeing if they'll consider either disabling that check or overriding it when an SPF check passes.
thank you very much for your quick answer. I could understand what it is about, but I do not know to much about the details as I am not a server guy :) I have forwarded it to our IT people, lets see how we could solve this problem.
Best wishes from Germany
Joerg
Thanks for your support!
Cheers
JST