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
  • edited June 25, 2014
    The check that the IronPort server is doing (Forward-confirmed reverse DNS, or FCrDNS) is somewhat controversial, and there are much better options it could be using. It's quite likely also blocking other legitimate email. To quote RFC 7001:
    There is some contention regarding the wisdom and reliability of this test. [...] Extensive discussion of reverse DNS mapping and its implications can be found in [DNSOP-REVERSE]. In particular, it recommends that applications avoid using this test as a means of authentication or security.
    Here's what's happening: Zotero currently sends mail through our two front-facing IP addresses, and both of those IP addresses have reverse DNS (PTR) records pointing back to zotero.org. The zotero.org domain alternates randomly between the two individual IP addresses (using single IP addresses rather than round-robin DNS), because that's how Amazon Route 53, Amazon's cloud DNS service, performs weighted DNS routing and DNS failover — it can adjust the ratio of the two responses as desired, and if a health check on the front-end servers fails, it can automatically stop sending the associated IP address. But this means that an FCrDNS check will fail exactly half the time: when the mail server gets back the other IP address for the resolved PTR name, zotero.org.

    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.
  • Hi Dan

    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
  • our IT department has set Zotero.org to the whitelist, problem solved :)
    Thanks for your support!

    Cheers
    JST
Sign In or Register to comment.