Ticket #2246 (new task)
Install and configure Trac <-> email gateway
| Reported by: | zaytsev | Owned by: | zaytsev |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | adm | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Branch state: | no branch | Votes for changeset: |
Description
Points to consider:
1) https://subtrac.sara.nl/oss/email2trac/wiki/Email2tracInstallation
2) We don't really need attachments, have to disable it
3) Mailing list subscribed to Trac notifications -> replies go directly into Trac
4) Problem with code review: another mailing list subscribed to all branches commits?
Comments welcome.
Change History
comment:2 Changed 14 years ago by zaytsev
Well, there's not much of initiative to it yet. I didn't discuss it with others yet, one of the reasons being that I'm at a conference right know and they are blocking all IM, while circumventing this with my SSH hosts is too much of a PITA. But I definitively think that having a working Trac <-> email gateway is a worthwhile goal and it will be accepted as such.
The reason why I wouldn't want to allow attachments at least in the initial implementation is that it's a huge security risk if not properly implemented, and it seems that it's quite challenging to get it right with the Trac plugin that is available right now.
In what concerns the SPAM, I think as a first step we can just stick to filtering by the sender email which has to be one of a registered Trac user. More sophisticated filtering can be added later.
I don't think that we should direct all the commits from non-master branches to mc-devel. This is a huge influx of junk. I'd rather have a separate list for it as we have it for Trac notifications, but with reply-to set to mc-devel.
IMO.
comment:3 Changed 14 years ago by andrew_b
- Type changed from enhancement to task
- Milestone Future Releases deleted
comment:4 Changed 13 years ago by andrew_b
- Version version not selected deleted
- Branch state set to no branch
cool initiative. :)
i wouldn't worry about disabling attachments. it would be an effort without much use. and the feature might actually be useful in a yet unforeseen scenario.
to block *all* spam, the receiving MTA should have a filter configured which accepts only signed mails (any valid signature is ok). when using gpg-agent or dedicated low-value password-less keys, the overhead for the developers would be (almost) zero.
it needs to be verified whether the plugin deals well with the "[Midnight Commander]" prefix from the list. if not, the MTA could just rewrite the subject.
regarding the list for code reviews, i think the notifications for the "preliminary" commits should just go to mc-devel@. it's the right place to discuss development matters, irrespective of the tools around it.