starred/mailpit

Fork 0

mirror of https://github.com/axllent/mailpit.git synced 2026-04-26 16:56:00 +03:00

[GH-ISSUE #512] Feature: Send API should be more flexible on fields from, to and others email or emails list fields #328

New issue

Closed

opened 2026-03-15 13:54:39 +03:00 by kerem · 6 comments

kerem commented

2026-03-15 13:54:39 +03:00

Owner

Originally created by @Dody56 on GitHub (Jun 5, 2025).
Original GitHub issue: https://github.com/axllent/mailpit/issues/512

In context of use mailpit for other project testing, I have adapt send API to support simple email string in complement of structured name, email dictionnary.

I send a PR for this but I don't expert on go so I take feedback.
Thanks

Originally created by @Dody56 on GitHub (Jun 5, 2025). Original GitHub issue: https://github.com/axllent/mailpit/issues/512 In context of use mailpit for other project testing, I have adapt send API to support simple email string in complement of structured name, email dictionnary. I send a PR for this but I don't expert on go so I take feedback. Thanks

kerem closed this issue

2026-03-15 13:54:44 +03:00

kerem commented

2026-03-15 13:54:50 +03:00

Author

Owner

@axllent commented on GitHub (Jun 5, 2025):

I see what you are trying to do here, but this will not work with swagger as it must be one way or the other. This would mean that one way (object) or the other (string) would be the documented way in swagger, and the other way would be a hidden "feature". This becomes messy.

What is wrong with using an object?

@axllent commented on GitHub (Jun 5, 2025): I see what you are trying to do here, but this will not work with swagger as it must be one way or the other. This would mean that one way (object) or the other (string) would be the documented way in swagger, and the other way would be a hidden "feature". This becomes messy. What is wrong with using an object?

kerem commented

2026-03-15 13:54:55 +03:00

Author

Owner

@Dody56 commented on GitHub (Jun 5, 2025):

In fact I would try a solution in testing mode (https://github.com/kanbn/kan) and this other solution could take a Send API and no SMTP and it use something like :

{
    "from": "noreply@example.com",
    "to": "mick@example.com",
    "subject": "Test",
    "text": "Hello world"
}

and mailpit response with Bad Request.
So I look and it seems easy to adjust and i think that this king of project have be flexible in usage ...

I try to ajust documentation comment ... I dont find a way to update doc ?

A other way could be to add /api/v1/send_alt or something like that but I don't think that it's better ...

@Dody56 commented on GitHub (Jun 5, 2025): In fact I would try a solution in testing mode (https://github.com/kanbn/kan) and this other solution could take a Send API and no SMTP and it use something like : ``` { "from": "noreply@example.com", "to": "mick@example.com", "subject": "Test", "text": "Hello world" } ``` and mailpit response with Bad Request. So I look and it seems easy to adjust and i think that this king of project have be flexible in usage ... I try to ajust documentation comment ... I dont find a way to update doc ? A other way could be to add `/api/v1/send_alt` or something like that but I don't think that it's better ...

kerem commented

2026-03-15 13:55:00 +03:00

Author

Owner

@axllent commented on GitHub (Jun 5, 2025):

I understand your desire for increased flexibility, but it's important to note that there are various SMTP APIs, each functioning differently. There isn't a universal standard, but I opted for this particular approach because it aligns with the address structure of many popular APIs, such as Mailgun and SendGrid, which are designed this way for a specific reason. They require those values to be formatted as objects to avoid errors and to clearly distinguish between names and email addresses. If you wish to use the send API, you'll need to submit your data according to the documented format.

What you are trying to do is to make it flexible, but this will also result in users trying something like:

{
    "from": "Sender <noreply@example.com>",
    "to": "Mick Surname <mick@example.com>, Another user <another@example.com>",
    "subject": "Test",
    "text": "Hello world"
}

This will result in errors, which is exactly what the object structure prevents. I do not want to change this.. The send API is clear and documented, which is why I do not understand why you cannot use the existing object format?

So to be clear, whilst I do appreciate your input, I do not see any reason to change this in Mailpit's API.

To answer your other question, I generate the swagger file like this:

docker run --rm -it -u $(shell id -u):$(shell id -g) -v "${PWD}:/source" axllent/go-swagger generate spec -m -i ./server/apiv1/swagger-config.yml -o ./server/ui/api/v1/swagger.json

@axllent commented on GitHub (Jun 5, 2025): I understand your desire for increased flexibility, but it's important to note that there are various SMTP APIs, each functioning differently. There isn't a universal standard, but I opted for this particular approach because it aligns with the address structure of many popular APIs, such as Mailgun and SendGrid, which are designed this way for a specific reason. They require those values to be formatted as objects to avoid errors and to clearly distinguish between names and email addresses. If you wish to use the send API, you'll need to submit your data according to the documented format. What you are trying to do is to make it flexible, but this will also result in users trying something like: ```json { "from": "Sender <noreply@example.com>", "to": "Mick Surname <mick@example.com>, Another user <another@example.com>", "subject": "Test", "text": "Hello world" } ``` This will result in errors, which is exactly what the object structure prevents. **I do not want to change this.**. The send API is clear and documented, which is why I do not understand why you cannot use the existing object format? So to be clear, whilst I do appreciate your input, I do not see any reason to change this in Mailpit's API. To answer your other question, I generate the swagger file like this: ``` docker run --rm -it -u $(shell id -u):$(shell id -g) -v "${PWD}:/source" axllent/go-swagger generate spec -m -i ./server/apiv1/swagger-config.yml -o ./server/ui/api/v1/swagger.json ```

kerem commented

2026-03-15 13:55:05 +03:00

Author

Owner

@Dody56 commented on GitHub (Jun 5, 2025):

Exact. I understand your point of vue ... my primary idea when I found this incompatibility is who (witch project) has to be patched ?

Kan has also send api interfaced client so ...

I think also that we can parse string to find if it is a simple e-mail or a "named" e-mail string ...

@Dody56 commented on GitHub (Jun 5, 2025): Exact. I understand your point of vue ... my primary idea when I found this incompatibility is who (witch project) has to be patched ? Kan has also send api interfaced client so ... I think also that we can parse string to find if it is a simple e-mail or a "named" e-mail string ...

kerem commented

2026-03-15 13:55:10 +03:00

Author

Owner

@axllent commented on GitHub (Jun 5, 2025):

That is my point though, there is no standard, they all differ from each other. I cannot, and will not, try to support multiple send APIs because it never ends (there are hundreds of different ones). If I started entertaining the idea of alternate APIs then there will always be requests for "can you also make the API the same as ".

Mailpit is an SMTP testing tool. For convenience it also has a basic HTTP API for sending messages too, which is very similar to several of the popular APIs, but that is as far as I will take it.

@axllent commented on GitHub (Jun 5, 2025): That is my point though, there is no standard, they all differ from each other. I cannot, and will not, try to support multiple send APIs because it never ends (there are hundreds of different ones). If I started entertaining the idea of alternate APIs then there will always be requests for "can you also make the API the same as <XYZ>". Mailpit is an SMTP testing tool. For convenience it also has a basic HTTP API for sending messages too, which is very similar to several of the popular APIs, but that is as far as I will take it.

kerem commented

2026-03-15 13:55:15 +03:00

Author

Owner

@Dody56 commented on GitHub (Jun 5, 2025):

Ok for me ;)

@Dody56 commented on GitHub (Jun 5, 2025): Ok for me ;)