Current behavior
Mailer.validate(email) validates the supplied Email instance as-is. It does not apply the mailer's configured email defaults or overrides, convert the message to MIME, or enforce the maximum encoded message size.
The send path is different: it first produces the effective email with defaults and overrides, validates that result, converts it to a MimeMessage, and then performs the final encoded-size check.
This means, for example, that an email without a From address can fail a direct mailer.validate(email) call but still send successfully when the mailer supplies a default From address.
Design question
Should Mailer.validate(email) become a full rehearsal of the mailer's send-time preparation instead of validating the supplied object directly?
Questions to settle:
- Should defaults and overrides be applied before validation?
- Should a full rehearsal include MIME conversion and the final encoded-size check?
- Should the existing method change semantics, or should a separate API such as
validateForSending make the distinction explicit?
- How should this relate to direct address validation through
EmailValidator and the lower-level checks exposed by MailerHelper?
- What should happen when all client validation is disabled?
Changing the existing behavior may affect callers that intentionally validate the unmodified Email, while a separate method would expand the public API. No implementation is proposed yet; this issue is for reconsidering and defining the contract.
History
Issue #121 previously explored separating validation and sending responsibilities. It led to customizable address validation and CustomMailer, but did not decide whether Mailer.validate should reproduce the complete send preparation pipeline.
Current behavior
Mailer.validate(email)validates the suppliedEmailinstance as-is. It does not apply the mailer's configured email defaults or overrides, convert the message to MIME, or enforce the maximum encoded message size.The send path is different: it first produces the effective email with defaults and overrides, validates that result, converts it to a
MimeMessage, and then performs the final encoded-size check.This means, for example, that an email without a From address can fail a direct
mailer.validate(email)call but still send successfully when the mailer supplies a default From address.Design question
Should
Mailer.validate(email)become a full rehearsal of the mailer's send-time preparation instead of validating the supplied object directly?Questions to settle:
validateForSendingmake the distinction explicit?EmailValidatorand the lower-level checks exposed byMailerHelper?Changing the existing behavior may affect callers that intentionally validate the unmodified
Email, while a separate method would expand the public API. No implementation is proposed yet; this issue is for reconsidering and defining the contract.History
Issue #121 previously explored separating validation and sending responsibilities. It led to customizable address validation and
CustomMailer, but did not decide whetherMailer.validateshould reproduce the complete send preparation pipeline.