[GH-ISSUE #284] Rationale behind the UUID in logging messages? #46

Open
opened 2026-02-26 18:33:03 +03:00 by kerem · 8 comments
Owner

Originally created by @Necoro on GitHub (Dec 5, 2025).
Original GitHub issue: https://github.com/decke/smtprelay/issues/284

When relaying a mail, the code logs a message about it -- which includes a random UUID:
github.com/decke/smtprelay@ccb70f5cf6/main.go (L176-L180)

What is the rationale here?

  • The UUID is not connected to the mail itself (so it would print out a different UUID if it would come through here again for the same mail).
  • Thus, there is also nothing to link back from UUID to mail (for tracing, for instance)
  • This is the sole location where a UUID is used
  • A whole dependency (albeit small) has been added just for this line.
Originally created by @Necoro on GitHub (Dec 5, 2025). Original GitHub issue: https://github.com/decke/smtprelay/issues/284 When relaying a mail, the code logs a message about it -- which includes a random UUID: https://github.com/decke/smtprelay/blob/ccb70f5cf6698476e9cb07ca04db32428efa9e31/main.go#L176-L180 What is the rationale here? - The UUID is not connected to the mail itself (so it would print out a different UUID if it would come through here again for the same mail). - Thus, there is also nothing to link back from UUID to mail (for tracing, for instance) - This is the sole location where a UUID is used - A whole dependency (albeit small) has been added just for this line.
Author
Owner

@decke commented on GitHub (Dec 6, 2025):

The idea was to have a unique identifier for a request that can be traced. You can see the original code in commit 34cb47c364 but I probably broke it in the rewrite from logrus to zerolog.

<!-- gh-comment-id:3619686507 --> @decke commented on GitHub (Dec 6, 2025): The idea was to have a unique identifier for a request that can be traced. You can see the original code in commit 34cb47c36438ed4efe87c62dcdb64dc34d5e9e76 but I probably broke it in the rewrite from logrus to zerolog.
Author
Owner

@Necoro commented on GitHub (Dec 6, 2025):

Hmm, I think also in the original version the UUID is not globally assigned to the message so there is really no use (except I misunderstand the logging framework and they do this assignment under the hood).

Btw: mails already have the header "Message-Id". This allows for tracing because it is the same throughout the whole process.

<!-- gh-comment-id:3619712681 --> @Necoro commented on GitHub (Dec 6, 2025): Hmm, I think also in the original version the UUID is not globally assigned to the message so there is really no use (except I misunderstand the logging framework and they do this assignment under the hood). Btw: mails already have the header "Message-Id". This allows for tracing because it is the same throughout the whole process.
Author
Owner

@n3storm commented on GitHub (Dec 7, 2025):

Hmm, I think also in the original version the UUID is not globally assigned to the message so there is really no use (except I misunderstand the logging framework and they do this assignment under the hood).

Btw: mails already have the header "Message-Id". This allows for tracing because it is the same throughout the whole process.

From my experience you cannot trust all messages have a "Message-Id"

<!-- gh-comment-id:3623189952 --> @n3storm commented on GitHub (Dec 7, 2025): > Hmm, I think also in the original version the UUID is not globally assigned to the message so there is really no use (except I misunderstand the logging framework and they do this assignment under the hood). > > Btw: mails already have the header "Message-Id". This allows for tracing because it is the same throughout the whole process. From my experience you cannot trust all messages have a "Message-Id"
Author
Owner

@decke commented on GitHub (Dec 7, 2025):

Message-Id does not seem to be strictly required and can also be created by the smtp server. Format of the content seems to be better defined but handling is a bit imprecise.

msmtp has a config option for it and will create a Message-Id header per default. Don't know about dma and others yet.

<!-- gh-comment-id:3623504743 --> @decke commented on GitHub (Dec 7, 2025): Message-Id does not seem to be strictly required and can also be created by the smtp server. Format of the content seems to be better defined but handling is a bit imprecise. msmtp has a config option for it and will create a Message-Id header per default. Don't know about dma and others yet.
Author
Owner

@decke commented on GitHub (Dec 8, 2025):

DragonFly Mail Agent v0.13+
Message-Id: 69367eae.a763.27b982d6@host

Dma creates a proper message-id.

<!-- gh-comment-id:3625540327 --> @decke commented on GitHub (Dec 8, 2025): DragonFly Mail Agent v0.13+ Message-Id: <69367eae.a763.27b982d6@host> Dma creates a proper message-id.
Author
Owner

@Necoro commented on GitHub (Dec 8, 2025):

Message-Id does not seem to be strictly required and can also be created by the smtp server

My first intention was: Well, this is an SMTP server. On the other hand, and this is already true for just reading it, this would require to add mail content handling to the software. This might not be worth it.

@decke: Feel free to just close this issue. I stumbled upon this UUID creation and was just puzzled. If this is as intended there is no issue :)

<!-- gh-comment-id:3625599023 --> @Necoro commented on GitHub (Dec 8, 2025): > Message-Id does not seem to be strictly required and can also be created by the smtp server My first intention was: Well, this *is* an SMTP server. On the other hand, and this is already true for just reading it, this would require to add mail content handling to the software. This might not be worth it. @decke: Feel free to just close this issue. I stumbled upon this UUID creation and was just puzzled. If this is as intended there is no issue :)
Author
Owner

@decke commented on GitHub (Dec 8, 2025):

It's true that smtprelay is almost transparent and per design does not store and forward like regular SMTP Servers do. But we already fiddle with mail headers (Received) so it's not impossible.

<!-- gh-comment-id:3625628357 --> @decke commented on GitHub (Dec 8, 2025): It's true that smtprelay is almost transparent and per design does not store and forward like regular SMTP Servers do. But we already fiddle with mail headers (Received) so it's not impossible.
Author
Owner

@decke commented on GitHub (Dec 8, 2025):

Tested with a HP LaserJet PRO M281fdw (from 2018) and it does not send a Message-Id so my upstream smtp creates it instead.

Message-ID: 19afd0be6e7.5c39ada953244009.3969882385343288018@zoho.eu

<!-- gh-comment-id:3625650809 --> @decke commented on GitHub (Dec 8, 2025): Tested with a HP LaserJet PRO M281fdw (from 2018) and it does not send a Message-Id so my upstream smtp creates it instead. Message-ID: <19afd0be6e7.5c39ada953244009.3969882385343288018@zoho.eu>
Sign in to join this conversation.
No labels
bug
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/smtprelay#46
No description provided.