Sent email can be assigned a "stagger type", for which he system will
maintain a "last sent" information. When the email is sent, it will be
delayed to be at least "stagger" time after the last one sent of the
same type. If no email of this type has been sent before, the email is
of course sent immediately.
The python libraries will *append* a header if it's just added again,
which would cause the news to go out with two date headers. Oops. So
instead check if each header is present and in that case replace it
rather than appending.
If a HTML body is specified, the plaintext and html bodies will be sent
as a multipart/alternative MIME object.
Also teach it to add attachments with Content-ID and overriding the
Content-Disposition, to make it possible to reference images attached
using cid: type URLs.
Most of our auto-generated emails should not ask for auto replies (like
out of office messages or in particular, "held for moderation" notices
from our own list server), so set this header by default, and also the
header indicating if it's an auto submitted/auto replied message.
Specifically allow auto replies on moderation notices, since that's a
case where it might be really interesting for the moderator to see for
example an out of office message. At least for now that seems like a
good idea.
Sending from the submitters address runs afoul to DMARC and other
restrictions. Instead, send the email from a defined noreply address.
Instead, add the original submitter to both the Cc and the Reply-To
header, to make sure they receive followups.
Patch by Stephen, minor changes by Magnus
This gives the submitter a chance to respond to their own message even
if it's not delivered through the list (for example, because they are
not subscribed, or because it's caught in moderation for other reasons).
Per discussion at the developer meeting.
Imported from pgeu. Do simple decoding of emails in the queue instead of
just showing the b64-encoded version in the admin interface. Intended to
help with debugging only.
The previous code, which was submitting locally, apparently didn't
need to provide a Message-Id header. However, now that we're
directly submitting to a remote system, we need to make sure that
a Message-Id header exists or the emails will get bounced.
In addition, the Python docs for this module state that Message-Id
is really one of the required fields anyway. It's unclear how many
real bugs we lost because of this, but I got involved when there
was complaining on IRC that a bug submitted didn't show up on the
-bugs list.
In case folks are wondering why I'm committing/pushing this (or how),
I've already fixed this on wrigleys (thanks to Andrew Gierth for
helping me debug and test the changes) and subsequently gave myself
access to this repo, to get this commit in, before anyone else
commits and overwrites my local hacks and breaks the bugs form again.
Basically, user generated email (bug report form) will be sent to the mail
frontends for antispam. Any errors generated there will be ignored and
the mails "dropped on the floor". Other emails keep entering the system
through localhost and delivered there.
Import the code from the PostgreSQL Europe website to handle this, since it's
well proven by now.
Any points that send email now just write them to the database using the
functions in queuedmail.util. This means we can now submit notification
emails and such things within transactions and have them properly roll bcak
if something goes wrong (so no more incorrect notifications when there is
a database error).
These emails are picked up by a cronjob that runs frequently (typically
once per minute or once every 2 minutes) that submits them to the local
mailserver. By doing it out of line, this gives us a much better way of
dealing with cases where mail delivery is really slow.
The submission from the cronjob is now done with smtp to localhost instead
of opening a pipe to the sendmail command - though this should have no
major effects on anything.
This also removes the setting SUPPRESS_NOTIFICATIONS, as no notifications
are actually ever sent unless the cronjob is run. On development systems
they will just go into the queuedmail table, and can be deleted from there.
