Email Validation for AI Coding Assistants

Integrate email validation using the check-mail.org API into this project.

## API Details
- Endpoint: POST https://api.check-mail.org/v2/
- Authentication: Bearer token in the Authorization header
- Request body parameter: email (the email address to validate)
- Content-Type: application/x-www-form-urlencoded

## Setup
Store the API key in the project's environment variables file (e.g. .env) as CHECK_MAIL_API_KEY. If you don't know my API key, ask me for it.

## Making a Request
Send a POST request with the email parameter:

    POST https://api.check-mail.org/v2/
    Authorization: Bearer YOUR_API_KEY
    Accept: application/json
    Body: email=user@example.com

## Response Structure
The API returns JSON with these fields:

{
    "valid": true,              // Whether the email domain exists and can receive mail
    "block": true,              // PRIMARY FIELD: Whether this email should be blocked
    "domain": "example.com",
    "base_domain": "example.com",
    "text": "Should be blocked", // Human-readable explanation
    "reason": "Heuristics: BM1", // Technical reason for the decision
    "risk": 99,                 // Risk score 0 (safe) to 100 (dangerous)
    "is_disposable": false,     // Temporary/throwaway email service
    "is_email_forwarder": false, // Email forwarding service
    "is_public_free": false,    // Free provider (Gmail, Yahoo, etc.)
    "is_public_premium": false, // Premium tier of public provider
    "is_business_provider": false, // Business email hosting
    "is_isp_email": false,      // ISP-provided email
    "is_email_api": false,      // Transactional email service
    "is_web_hosting_email": false, // Web hosting provider email
    "is_self_hosted": false,    // Self-hosted mail server
    "is_parked": false,         // Parked/unused domain
    "is_role_based_email": false, // Role address (info@, support@)
    "mx_host": "example.com",   // Mail server hostname
    "mx_ip": "104.18.27.120",  // Mail server IP
    "mx_info": "...",           // MX record details
    "mx_fallback": true,        // Whether MX is a fallback
    "mx_hosts": ["example.com"],
    "mx_ips": ["104.18.27.120"],
    "mx_priorities": [],
    "email_provider": null,     // Identified provider name
    "disposable_provider": null, // Disposable service name
    "possible_typo": [],        // Suggested corrections for typos
    "domain_age_days": 11183,
    "domain_created_at": "1995-08-14T00:00:00+00:00",
    "block_status_changed_at": "2024-10-27T21:38:24+00:00"
}

## How to Use the Response
The "block" field is the primary decision field:
- block = true: Reject the email (disposable, risky, invalid, etc.)
- block = false: The email is acceptable

Use "text" and "reason" to show the user why an email was rejected.
Use "risk" (0-100) for a more granular risk assessment.
Use "possible_typo" to suggest corrections (e.g. "Did you mean gmail.com?").
Use "is_disposable", "is_public_free", "is_role_based_email" etc. for custom filtering beyond the block field.

## Error Handling
- 401: Invalid or missing API key
- Invalid or missing email returns HTTP 200 with "valid": false in the response body (not a 422)
- If the API is unreachable, allow the form submission to proceed (fail open)
- Handle network errors gracefully with a try/catch

## Implementation Guidelines
- Validate the email on form submission (server-side), not on every keystroke
- Show a user-friendly message when an email is blocked
- Cache results when appropriate to avoid redundant API calls
- Never expose the API key in client-side/frontend code

Documentation: https://docs.check-mail.org/
Sign up for a free API key (1,000 requests/month): https://app.check-mail.org/register