| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
| |
Forwarding and storing are yet to be implemented, but this commit does
implement the handling of the DATA command.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
|
| |
Validation for the recipients' email addresses should be added later on.
This is not strictly necessary as the request at this point will already
have gone through another MTA, but it should be done just for good
measure in case someone decides to expose this software directly to the
internet.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
| |
Validation for the sender's email address should be added later on. This
is not strictly necessary as the request at this point will already have
gone through another MTA, but it should be done just for good measure in
case someone decides to expose this software directly to the internet.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
| |
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
| |
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
| |
EHLO most likely won't be implemented as this software is meant to be
ran in a containerized environment, where only the main MTA is supposed
to be able to reach the container of this software.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
| |
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
| |
Having both the callback and the high level API be called execute() is
confusing. Rename for clarity.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The various Query enums limit themselves to checking which variant they
are before choosing a which function to call to process the request.
Because they are enums with multiple variants, to unpack we have to
check again which variant they are.
Unpack before the call and modify function signatures to receive the
already unpacked values.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
| |
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
|
| |
We need to track which user subscribed to which list. Unlike User and
List, we don't need to make a Subscription model, this is because this
is a relationship and not an entity of its own.
Implement database interaction with subscription.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
|
| |
We ideally want to be able to handle multiple mailing lists without
having to run a new instance for each one. To do this we need to be able
to create new lists.
Add List model with its DB interactions.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
| |
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
| |
The mailing list will need to save the data of the subscribers for them
to receive the emails.
Add User model with its DB interactions.
Signed-off-by: Mroik <mroik@delayed.space>
|
| |
|
|
|
|
|
|
|
| |
The mailing list will need to save various data to operate for things
such as the subscriber's email.
Add database interaction machanism.
Signed-off-by: Mroik <mroik@delayed.space>
|
|
|
A mailing list implementation by POuL for POuL that aims to be minimal
but use SMTP to deliver receiving emails instead of LMTP. This is
because mailing list software that use LMTP as their delivery mechanism
make achieving modularized container environments harder. This is due to
the fact that mailing lists that use LMTP require it and the main MTA to
live on the same machine.
This implementation aims to be good enough to be used as the mailing
list for POuL in its kubernetes infrastructure (and frankly, it was
about time that someone implemented a mailing list that could be
"standalone" in containers).
Signed-off-by: Mroik <mroik@delayed.space>
|
