[dajiaohuang]

Changes proposed in this pull request

Text attachments currently enter the body-alternative group solely because their MIME type is text/plain or text/html. For a message with plain and HTML bodies plus notes.txt, the rendered root becomes multipart/alternative, and Python's standard email consumer exposes no attachment through iter_attachments().

Exclude parts with attachment or inline disposition from the body group using the existing Mail.Message.is_attachment?/2 predicate. This preserves the renderer's existing mixed/related/alternative layout: regular text attachments sit outside body alternatives, and inline text parts remain related to them. This follows the distinction between alternative representations and independent parts in RFC 2046 §5.1.4.

Add three render/parse regressions covering .txt, .html, and inline text attachments, including MIME structure and recovered attachment payloads.

Validation on Elixir 1.14.0 / Erlang OTP 25:

• New regressions: all 3 fail before the fix; all 3 pass after it.
• mix test: 39 doctests and 266 tests pass.
• mix format --check-formatted lib/mail/renderers/rfc_2822.ex test/mail/renderers/text_attachment_test.exs passes.
• Independent Python standard-library email parsing of actual rendered messages: text and HTML attachments are now exposed; binary-attachment and body-only controls still pass.
• Supported API checks pass for Unicode bodies, body replacement, path/tuple attachments, binary round trips, headers, parser/renderer hooks, and transfer encoding.

No SMTP delivery or real mail-client acceptance was performed; other runtime versions and hosted CI were not run locally.

[bcardarella]

@andrewtimberlake thoughts?