Accepts email addresses without validation

[John Goerzen <jgoerzen@…>]

trac accepts email addresses without validation several different places — on the New Ticket screen, on the settings screen, etc. This is bad for several reasons.

For starters, it can be abused by cybercriminals (such as spammers). For example, they can put the email address of a victim in the "Your email" box on the New Ticket screen, and submit a ticket to any Trac instance configured to send a copy of each new ticket to its submitter.

It could also be used by a miscreant to subscribe an unwitting victim to notifications, for harassment.

It also prevents catching errors, such as typos, causing notifications to be lost.

Trac should only send emails that:

1. are verification emails
2. are destined to a verified address
3. or are entered by a trusted user (although this does not prevent errors).

Besides missed notifications, the current situation:

1. facilitates cybercriminality
2. threatens owners of Trac instances, by:
   • endangering their email address/domain reputation
   • endangering the performance of their instance and servers
   • increasing resource usage
   • possibly creating legal risks.

Solutions

TracDev/Proposals/EmailValidation

[Emmanuel Blot]

Sure. On the other side, do spammers really need a proxy such as Trac to relay their spam emails?

I'd rather see this feature as an enhancement than a defect.

[John Goerzen <jgoerzen@…>]

Yes, it really does happen in the wild, and in fact, has been:

​http://www.salted.com/unsalted/contact-form-spam

​http://www.google.com/search?q=email+form+spam&ie=utf-8&oe=utf-8&rls=org.debian:en-US:unofficial&client=firefox-a

Please set the type to whatever you like; you know better how your process fits this than I do.

thanks,

— John

[Pedro Algarvio, aka, s0undt3ch <ufs@…>]

Perhaps until this is implemented have a bad_email_addresses setting for [notification] allowing the admin to have a space delimited list of know bad email addresses which would serve to filter the addresses to be notified of changes?

[Christian Boos]

Milestone 1.0 deleted

[Thijs Triemstra <lists@…>]

Replying to Pedro Algarvio, aka, s0undt3ch <ufs@…>:

Perhaps until this is implemented have a bad_email_addresses setting for [notification] allowing the admin to have a space delimited list of know bad email addresses which would serve to filter the addresses to be notified of changes?

This sounds like a lot more work than a simple regexp that checks for a valid address (which is probably already available in stdlib somewhere?).

Any reason why this hasn't been implemented other than time etc? What would a good patch have to do..

[Thijs Triemstra]

#9900 was closed as a duplicate.

[Carsten Klein <carsten.klein@…>]

cf. TracDev/Proposals/EmailValidation

[Carsten Klein <carsten.klein@…>]

An initial prototype of the e-mail address validation facility, for now a direct part of the notification subsystem, is available for review and comment.

See TracDev/Proposals/EmailValidation#CurrentDevelopmentStatus for some information on its state and also TracDev/Proposals/EmailValidation#Repository for information on how to access the repository.

Feel free to comment on the prototype by either putting the information here or in the TracDev/Proposals/EmailValidation#Discussion section of that page.

[Remy Blank]

I'd like to take a look at it. It may take a bit of time, though, as I will have to learn git first :)

[Carsten Klein <carsten.klein@…>]

Replying to rblank:

I'd like to take a look at it. It may take a bit of time, though, as I will have to learn git first :)

see EmailValidation#UsingtheRepository for a quick guide on how to use it…

[Carsten Klein <carsten.klein@…>]

here is the correct link: TracDev/Proposals/EmailValidation

[Philippe Cloutier <chealer@…>]

Thank you very much for reporting John

Thank you for your proposal Carsten

Replying to Emmanuel Blot:

Sure. On the other side, do spammers really need a proxy such as Trac to relay their spam emails?

Spammers rarely need to send spam. They choose to turn vulnerabilities into money. If Trac offers them abusing its instances to multiply their bandwidth and steal reputation from more scrupulous people, they won’t say no to extra profits.

I'd rather see this feature as an enhancement than a defect.

I wish, but I have to agree with John. If Trac warned sysadmins upon installation that it may effectively turn their server into an open email relay, that may be a mere issue, but I'm afraid users have no idea what they are getting into.

Unfortunately, this is 2026:

1. There are many more cybercriminals than spammers. This can facilitate phishing and many forms of fraud and theft.
2. Email is no longer a novelty, and many laws in the domain may already have made this a legal issue. Speaking for my own country, section 9 of Canada’s anti-spam legislation (CASL) may be problematic (see Compliance and Enforcement Information Bulletin CRTC 2018-415).

If this is to persist for more decades, I would sadly recommend to include this in a list of issues admins are asked to acknowledge before install.

---

While John focused on the issue of recipient addresses, letting users (registered or not) author content using unverified addresses also facilitates impersonation. Although this only applies to instances which already allow unverified users to author content, attributing them email addresses without displaying an indication that they are unverified increases the risk of successful impersonation.

---

This comment is from Philippe "Chealer" Cloutier. I am subscribing to this ticket, but notifications seem to be broken, and I struggle to display my full email address or link to my contact information from this comment. My email address is available on Kune ni povos’s contact page. All of my comments and contributions in this ticket are offered under the terms of CC0 1.0 (unless otherwise noted).