Document SMTP FromHeader manual usage in package godoc#219
Merged
Conversation
Agent-Logs-Url: https://github.com/amalgamated-tools/goauth/sessions/99ea3150-fa82-4f5c-886b-44f45e694f18 Co-authored-by: veverkap <22348+veverkap@users.noreply.github.com>
Copilot created this pull request from a session on behalf of
veverkap
May 7, 2026 21:29
View session
Contributor
There was a problem hiding this comment.
Pull request overview
This PR clarifies the smtp package contract around sender identity by documenting that Send only uses Params.From for the SMTP envelope sender (MAIL FROM) and does not construct or apply RFC 5322 headers like From:.
Changes:
- Add a package-level warning explaining the envelope-vs-header split (
Params.FromvsParams.FromHeader). - Expand
Params.FromHeadergodoc to warn that callers must add theFrom:header themselves. - Update
Sendgodoc to explicitly state it does not add/rewrite RFC 5322 headers.
Show a summary per file
| File | Description |
|---|---|
| smtp/smtp.go | Adds/updates godoc warnings to prevent misuse of Params.FromHeader and clarify Send header responsibilities. |
Copilot's findings
Tip
Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comments suppressed due to low confidence (1)
smtp/smtp.go:124
- Similar to the package warning: "embed Params.FromHeader in msg" is ambiguous because FromHeader does not include the
From:field name. Reword this godoc to explicitly say callers must include aFrom:header line (typically"From: "+params.FromHeader+"\r\n") in msg themselves.
// Send uses Params.From only for the SMTP envelope sender (MAIL FROM). It does
// not add or rewrite RFC 5322 message headers, including From, so callers must
// embed Params.FromHeader in msg themselves.
- Files reviewed: 1/1 changed files
- Comments generated: 1
…mples Apply Go 1.19+ doc-link syntax ([Params.From], [Params.FromHeader], [Send]) so pkg.go.dev renders clickable cross-references. Also clarify all three warning comments to show the full header line with "\r\n" terminator, making it unambiguous that callers must write "From: "+Params.FromHeader+"\r\n".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
smtp.Params.FromHeaderis easy to misread as somethingsmtp.Sendwill apply automatically. In practice,Sendonly usesParams.Fromfor the SMTP envelope; callers must embed the RFC 5322From:header themselves inmsg.Clarify package contract
Senddoes not construct or rewrite message headers.Params.From) and RFC 5322 header sender (Params.FromHeader).Make
Params.FromHeaderharder to misuseValidate()formatsFromHeader, butSenddoes not copy it into the message.From:+Params.FromHeaderintomsg.Document
Sendbehavior where callers will look firstSendgodoc to state that it usesParams.Fromonly forMAIL FROM.From, and any other RFC 5322 headers, remain the caller’s responsibility.Example:
Greptile Summary
This is a documentation-only PR that clarifies the contract between
smtp.SendandParams.FromHeader. The existing code is unchanged; only godoc comments are updated to prevent callers from assumingSendwrites RFC 5322 headers automatically.WARNINGexplaining thatSendonly sets the SMTP envelope sender viaMAIL FROMand does not inject any RFC 5322 headers intomsg.Params.FromHeaderfield doc and theSendfunction doc to repeat the same contract and show the explicit string concatenation callers must perform.Confidence Score: 5/5
Documentation-only change with no modifications to runtime behavior — safe to merge.
No executable code was changed. The three updated godoc blocks accurately describe the existing behavior: Send uses only Params.From for MAIL FROM and passes msg to the server verbatim, exactly as the implementation shows. The added guidance is consistent across the package doc, field doc, and function doc.
No files require special attention.
Important Files Changed
Sequence Diagram
sequenceDiagram participant Caller participant Validate as cfg.Validate() participant Send as smtp.Send() participant SMTP as SMTP Server Caller->>Validate: "Config{Host, Port, From, ...}" Validate-->>Caller: "Params{From (bare email), FromHeader (RFC 5322), ...}" Note over Caller: Caller must build msg with<br/>"From: "+params.FromHeader+"\r\n"<br/>and all other RFC 5322 headers Caller->>Send: Send(ctx, params, to, msg) Send->>SMTP: MAIL FROM: params.From (envelope only) Send->>SMTP: RCPT TO: to Send->>SMTP: DATA: msg (as-is, headers untouched) SMTP-->>Send: 250 OK Send-->>Caller: nil / errorReviews (2): Last reviewed commit: "docs(smtp): use Go doc-link syntax and i..." | Re-trigger Greptile