| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Everything seems to be working now. On to the remote tests ;).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Even though I convert to ascii in send_pgp_mime.Mail.__init__(), it's
still good to be consistent inside each module ;).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Although I'm not catching stdout/stderr yet, so the replies aren't
very useful ;). Still it the send_pgp_mime.py interface is working :).
I've added rudimentary logging (via LOGFILE) to keep track of what
be-handle-mail is up to. There's also BE_DIR, which sets the
directory that BE lives in (important ;).
The author handling got more consistent, thanks to
send_pgp_mime.source_email (using the new return_realname option) and
email.utils.formataddr(). Now author_addr should look the same
regardless of which phrasing you use to set it (e.g. "NAME <ADDR>" vs
"ADDR (NAME)", and possibly others.)
|
| |
|
|
| |
You might want to keep the output to read later ;).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also:
Switched
email.message_from_string()
to
email.parser.Parser().parsestr()
for parsing the header, for access to the headersonly option.
Adjusted module import order to alphebetize non-mime email modules.
Added return_realname to source_email(), which makes it more useful to
be-handle-mail (currently uncommitted).
Added a doctest for the plain() output and removed redundant
Content-Type line from the doctests (which we'd removed from the
output with the last commit).
Note that many doctests _will_fail_ unless me@big.edu and you@big.edu
are in your gpg keyring. At some point I should make those addresses
options to --test...
|
| |
|
|
|
| |
* No reason to set maxheaderlen to something other than the default.
* MIMEText sets content-type and charset automatically.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also a few more tweaks to get things working. I think be-handle-mail
is parsing the incoming messages correctly now, but I'm not getting
replies back for some reason. Some of the adjustments:
* Moved send_pgp_mime -> send_pgp_mime.py, otherwise Python doesn't
recognize it as an importable module.
* I use postfix now instead of msmtp, so send_pgp_mime.sendmail now
points to postfix's sendmail-compatable frontend.
* Added "--mode=plain" option to send_pgp_mime.py, so I can test
my procmail rules and send_pgp_mime itself without worrying about
be-handle-mail.
* Fixed some typos in be-handle-mail.
|
| | |
|
| | |
|
| |
|
|
|
| |
Todo: generate a real response email to replace the current dummy
email.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is a bit of a shameless plug, since there's not much motivation
for encrypting bug emails. However, I've already written it, and it
does send emails, so I'm using it ;). Perhaps some company will want
to keep the bug submitter's contact information securely in a BE
database. Anyhow, there's very little reason to _not_ use PGP, and
the module certainly doesn't force you to encrypt anything. ;)
|
| |
|
|
|
|
| |
So far, it parses the emails and executes the specified task.
Todo: email the sender back with the output/errors/exit-status/etc.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The beginnings of an interactive email interface to BE.
With a working procmail setup, copying _procmailrc to ~/.procmailrc
should sort through incoming email to that user, passing all messages
with subjects starting with [be-mail] on to the script be-handle-mail
and deleting the rest.
Now I just need to write be-handle-mail ;).
|
|
|
one place and make things clearer to the uninitiated. Here's my
current understanding:
.
|-- libbe (the guts of BE)
|-- becommands (plugins for all "be *" commands)
|-- doc (documentation, currently just the man page)
|-- interfaces (non-commandline interface implementations)
| |-- web
| | |-- Bugs-Everywhere-Web (in Turbogears)
| |-- gui
| | |-- beg (in Tkinter)
| | `-- wxbe (in WX)
| |-- email
| `-- xml (xml <-> whatever conversion)
`-- misc (random odds and ends)
`-- completion (shell completion scripts)
Note that I haven't attempted to use the web or gui interfaces in a
while, so I'm not sure how well they're holding vs the core
development.
|
