Not getting E-Mail notification from Trac

[Yves]

I'm still not getting E-Mail notifications about changes in tickets. My account is currently configured to use my wildfiregames.com forwarder address. I'm using the same forwarder address in the forum without any problems. No mails are blocked in my spam filer.

Reviewing is difficult this way because I have to check the log on a daily basis or regularly go through the list of reviewed tickets manually.

[Yves]

The forwarder must be working (forum). So my own email account shouldn't have a problem either because it can receive mails from the forwarder. It's probably not a problem of the forwarder in combination with trac because entering my personal address directly didn't work either.

I would say the problem must be that the mails aren't even sent by trac. Because it works for other people, it's probably related to my account.

[Erik Johansson]

Not that it helps with this issue, but it can still be useful to: Go to the Timeline page: ​http://trac.wildfiregames.com/timeline Select what kind of updates you want to receive. And then get the RSS feed link from the bottom :) That way you'll get all the updates :)

Of course means you'll be reading through all the changes and not just on the tickets which you've participated, so obviously not optimal, but at least useful in its own right.

Sending emails in general does indeed work though, I received one just earlier today :P Or actually just as I'm writing this :P I really think it's something related to your email provider (in combination with the Trac email sending of course), even regardless of it working from the forum. I don't know the details, but the way Trac sends emails is relatively basic. Not all things are set as good as they could be (afaik, at least last time I saw something written by Philip about it), so presumably something is set differently to the forum emails. That combined with e.g. anti-spam measures of some email providers seems to me to be the cause of something like this. I have no idea how to fix it though.

[Jonas Platte]

I'm having a similar problem, but even more annoying: I don't get the verification mail of trac that I need to get normal permissions on two of my three email addresses.

The weird thing is that the mail address that I used before gets mails without problem. It is an address at myopera.com, which will be shut down in some months, which is why I wanted to change it.

But no matter how often I try to make trac send me a verification email when I change the address to my gmail.com address or some email at my own domain, I never get any mails.

I already sent a mail to someone through the contact form at play0ad.com because I thought even my old address wouldn't get mails because my mail program took some time to receive the mail.

[Philip Taylor]

I've tried to fix the server configuration a bit (so that it sends a FQDN in the HELO message, I think) - hopefully that will make fewer mail servers reject mails from Trac.

Messages to @wildfiregames.com still fail, with a message from mail.wildfiregames.com saying 550-Verification failed for <noreply@wildfiregames.com>\n550 Sender verify failed. I suspect that since mail.wildfiregames.com thinks it owns all @wildfiregames.com accounts, it won't accept messages claiming to be from @wildfiregames.com that are sent by another server (the Trac server), but I'm not at all certain about that.

[Jonas Platte]

Thanks! I can use my email address at my own domain now :)

[fabio]

Replying to Philip:

Messages to @wildfiregames.com still fail, with a message from mail.wildfiregames.com saying 550-Verification failed for <noreply@wildfiregames.com>\n550 Sender verify failed. I suspect that since mail.wildfiregames.com thinks it owns all @wildfiregames.com accounts, it won't accept messages claiming to be from @wildfiregames.com that are sent by another server (the Trac server), but I'm not at all certain about that.

SPF record for wildfiregames.com is broken. Double quotes must only be at the start and end of the TXT record. Remove the others.

wildfiregames.com.	300	IN	TXT	"v=spf1" "a" "mx" "ip4:69.65.43.109" "ip4:92.243.18.55" "~all"

[Philip Taylor]

Fixed DNS (thanks!)

[historic_bruno]

Is this resolved now?

[Philip Taylor]

Noticed gmail was complaining that the sending server's IPv6 address was not listed in the domain's SPF record. Added that now, so hopefully it will be happier.

[historic_bruno]

Is this resolved now?

[fabio]

This is still not fixed.

The spf TXT DNS record should be changed from:

v=spf1 a mx ptr ~all

to:

v=spf1 a a:trac.wildfiregames.com mx ptr ~all

The SPF record should be deleted, since it's obsolete (just leave the TXT spf record).

[Jan Middelkoop]

I have changed the DNS records. Please close ticket if this resolves the problem.

[fabio]

Thanks, but it's still not working. Apparently trac can sends mail using ipv6 address, and that ipv6 is not matched by either of the current mechanisms.

To fix this an AAAA dns record should be added to trac.wildfiregames.com, pointing to 2001:4b98:dc0:43:216:3eff:fe64:f120 .

Alternatively the TXT spf record should be changed to:

v=spf1 a a:trac.wildfiregames.com ip6:2001:4b98:dc0:43:216:3eff:fe64:f120 mx ptr ~all

[fabio]

Yesterday, as discussed on ​IRC, implodedok added both the AAAA record and ip6: mechanism to spf records, it appears now the spf test pass. However, before closing this issue, configuration should be properly cleaned to ease debugging eventual problems and avoiding potential issues in the future, specifically:

• the SPF record should be removed, since it's useless and unused, leaving just the proper, standardized TXT one;
• the ip6: mechanism should be removed from the spf record, as I specified in previous post, that is just an (less smart) alternative to adding the AAAA record.

When both are done and if spf test still succeed this issue can be closed.

[Jan Middelkoop]

fabio, you cannot keep the bug open until I resolve this the way you want. The originally reported matter is resolved. The bug can be closed. If you are dissatisfied with the solution, you can open a different bug.

I will explain my reasoning for resolving this the way I have below. To conclude this matter, not to start an argument.

I have both SPF and TXT records, because there are cases where it's beneficial to have both. In fact, several RFC's recommend having both for backwards compatibility. If you search Google, you'll find there is a lot of debate on the subject. Technically, you are right. Practically, you'll find a lot of mailservers are running very old software, which may not always do what you (or the current specifications) expect it to do.

The reason there are both AAAA record and ip6: is redundancy. One of the two, or both, should work. Again, I have no control over which records the receiving mailserver looks at, or even which A or AAAA record the sending mailserver chooses, so I'd rather be safe than sorry.

[fabio]

Replying to implodedok:

fabio, you cannot keep the bug open until I resolve this the way you want. The originally reported matter is resolved. The bug can be closed. If you are dissatisfied with the solution, you can open a different bug.

I will explain my reasoning for resolving this the way I have below. To conclude this matter, not to start an argument.

I have both SPF and TXT records, because there are cases where it's beneficial to have both. In fact, several RFC's recommend having both for backwards compatibility.

The ​RFC spec is clear:

   SPF records MUST be published as a DNS TXT (type 16) Resource Record
   (RR) [RFC1035] only.

   Use of alternative DNS RR types was supported in
   SPF's experimental phase but has been discontinued.

   In its review of [RFC4408], the SPFbis working group concluded that
   its dual RR type transition model was fundamentally flawed...

   ...the best solution for resolving this
   interoperability issue was to drop support for the SPF RR type...

If you search Google, you'll find there is a lot of debate on the subject. Technically, you are right. Practically, you'll find a lot of mailservers are running very old software, which may not always do what you (or the current specifications) expect it to do.

I don't know of any software checking SPF only but not TXT. If it exists it is just badly broken (no spec ever only required SPF) and useless. Just check gmail.com, yahoo.com, microsoft.com, or whatever properly designed domains: they only properly publish TXT and not SPF records.

The reason there are both AAAA record and ip6: is redundancy.

This is not redundancy at all, it's just useless and confusing design. Nowhere is documented to implement redundancy this way (and anyway, why would you apply this "redundancy" only to the ipv6 and not to the ipv4 address?).

One of the two, or both, should work. Again, I have no control over which records the receiving mailserver looks at, or even which A or AAAA record the sending mailserver chooses, so I'd rather be safe than sorry.

You have control through the a:trac.wildfiregames.com statement and with properly A and AAAA records. The ​RFC spec is clear also on this case:

   When any mechanism fetches host addresses to compare with <ip>, when
   <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6
   address, "AAAA" records are fetched.