feat: updated blogs, added missing h1 tags
This commit is contained in:
parent
2f16c98a29
commit
39fd866ae0
9 changed files with 64 additions and 50 deletions
|
|
@ -1,41 +1,52 @@
|
|||
---
|
||||
title: "DDNS explained: Tutorial, usage, and importance for homelabs"
|
||||
subtitle: Understanding DDNS, CGNAT, and network accessibility for homelabbers
|
||||
description: Learn how DDNS helps homelab enthusiasts with external IPv4 addresses, why Carrier-Grade NAT blocks DDNS, and how to check your network setup and troubleshoot accessibility issues.
|
||||
description: Learn how DDNS helps with dynamic IPv4 addresses, why Carrier-Grade NAT blocks DDNS, and how to check your network and troubleshoot DNS issues.
|
||||
---
|
||||
|
||||
# Why Dynamic DNS is essential for homelab setups with a public IPv4
|
||||
|
||||
Homelabbers running self-hosted services like game servers, file shares, or mail often face the challenge of connecting reliably from outside their home network. This is where DDNS (Dynamic Domain Name System, or DynDNS) becomes a key tool - especially for those with public IPv4 addresses. However, DDNS does not work the same for everyone, and Carrier-Grade NATs (CGNAT) often create limitations.
|
||||
People running self-hosted services like game servers, file shares, or mail often face the challenge of connecting reliably from outside their home network. This is where DDNS (Dynamic Domain Name System, or DynDNS) becomes a key tool - especially for those with public IPv4 addresses. However, DDNS does not work the same for everyone, and Carrier-Grade NATs (CGNAT) often create limitations and get in the way.
|
||||
|
||||
## What is DDNS?
|
||||
|
||||
DDNS allows you to automatically update DNS records with your dynamic external IPv4 address, so you can access your services easily using a domain name instead of memorizing IPs. If your home ISP gives you a non-static (dynamic) IP and you want to access `server.example.hexname.com`, DDNS providers keep this domain pointed to your current public IP.
|
||||
DDNS allows you to automatically update DNS records with your dynamic external IPv4 address, so you can access your services easily using a domain name instead of memorizing IPs. If your home ISP gives you a non-static (dynamic) IP and you want to access your server at `server.example.hexname.com`, DDNS providers keep this domain pointed to your current public IP.
|
||||
|
||||
For example, by creating an A record for `home.example.hexname.com` at a service like <a href="https://hexname.com">HexName</a>, and by periodically running a simple script on your home network, anyone connecting to this hostname will reach your actual home server - even if your IP changes every day.
|
||||
|
||||
This script could look something like this:
|
||||
```
|
||||
#!/bin/bash
|
||||
IP=$(curl -s http://ipv4.icanhazip.com)
|
||||
curl -X PUT https://hexname.com/api/v1/ddns/ipv4/[YOUR_TOKEN_HERE]/$IP
|
||||
```
|
||||
|
||||
## How CGNATs prevents DDNS from working
|
||||
|
||||
Many ISPs now use Carrier-Grade NATs to conserve limited IPv4 space. Instead of assigning a unique public address to each customer, ISPs put many users behind a single external IP. Your router gets a local address (like `100.64.0.15`), and only the ISP’s shared gateway gets a publically routable IP address.
|
||||
|
||||
Because of this extra layer, DDNS updates the DNS record to point to your ISP’s shared IP. Connections from the outside will never reach your router directly, since the ISP's router won't know which host is meant by the packet. This is why DDNS is ineffective behind CGNAT, and cannot open inbound connections for you, no matter the DNS configuration.
|
||||
|
||||
If you want to learn more, check out this blog on <a href="https://lukadeka.com/blog/how-to-cope-with-losing-a-public-ip-as-a-homelabber/">details on why CGNATs were invented, and how they work</a>.
|
||||
|
||||
## How to check if you have a public IPv4
|
||||
|
||||
To confirm you’re not behind CGNAT:
|
||||
|
||||
1. Log in to your router’s web interface. This is usually at `192.168.1.1` or `192.168.0.1`.
|
||||
1. Log in to your router’s web interface in the browser. This is usually at `192.168.1.1` or `192.168.0.1`.
|
||||
2. Find the section labeled "Status," "Internet," or "WAN" (Wide Area Network).
|
||||
3. Look for your displayed "external IPv4 address".
|
||||
3. Look for your displayed "external IPv4 address" and note it down.
|
||||
|
||||
To verify, look up “What is my IP” online and compare it with the router’s external IPv4. If they match, you have a "real" publically routable IP and DDNS will work as expected.
|
||||
Next, look up “What is my IP” online and compare it with the router’s external IPv4. If they match, you have a "real" publically routable IP and DDNS will work as expected.
|
||||
|
||||
> Otherwise if the external IP in the router's interface is in the private range (e.g., `100.64.0.0/10`, `10.0.0.0/8`, `192.168.0.0/16`, or `172.16.0.0/12`), this also means that you're behind some sort of CGNAT.
|
||||
Otherwise, you're behind a CGNAT and will have to look for other options for exposing your services to the world.
|
||||
|
||||
> Some ISPs offer public IPs as a paid feature, so it’s worth asking them if you'd benefit from DDNS.
|
||||
> Alternatively you can tell if you're behind a CGNAT if the external IP in the router's interface is in the private range (e.g., `100.64.0.0/10`, `10.0.0.0/8`, `192.168.0.0/16`, or `172.16.0.0/12`).
|
||||
|
||||
> Some ISPs offer public IPs as a paid feature, so it's worth looking into if you'd benefit from DDNS.
|
||||
|
||||
## Example DDNS usage in a homelab
|
||||
|
||||
If you have a true public IPv4, register a subdomain like `example.hexname.com` on <a href="https://hexname.com">HexName</a>, and set up a DDNS script to keep your record updated. This makes it possible to access your homelab remotely, run services, or even share files with friends securely, without worrying about changing IPs, proxying, or complicated URL sharing.
|
||||
|
||||
Homelabbing is the backbone of private cloud, self-hosted apps, and learning real-world networking—knowing your IP setup is the first step to an accessible, flexible lab.
|
||||
Homelabbing is the backbone of private cloud, self-hosted apps, and can teach you a lot about real-world networking. Understanding the underlying technology is crucial for maintaining a secure deployment.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: "All mail protocols/ports explained: SMTP, IMAP, submission, STARTTLS, JMAP"
|
||||
title: "All mail protocols explained: SMTP, IMAP, STARTTLS, etc."
|
||||
subtitle: A practical guide to email server ports and their specific roles
|
||||
description: This article outlines the most important email ports and protocols, explaining the purposes of each, their security implications, and how they fit into today's email infrastructure. Get practical information for configuring mail services and understanding the underlying protocols.
|
||||
description: This article explains common email ports/protocols, and their usage today. Get practical examples for setting up and understanding the underlying technology.
|
||||
---
|
||||
|
||||
# Email protocols clarified: a modern look at SMTP, IMAP, and JMAP
|
||||
|
|
@ -1,47 +1,46 @@
|
|||
---
|
||||
title: What is MTA-STS and how to set it up effortlessly
|
||||
subtitle: Understanding MTA strict transport security and its full syntax
|
||||
description: Learn how MTA-STS works to secure email transfer. See full config syntax, real-world examples, and potential risks without it. Discover practical tips and insights for DNS and TLS reporting.
|
||||
description: Learn how MTA-STS works to secure email transfer, with real-world examples, and potential risks without it. Discover insights for DNS and TLS reporting.
|
||||
---
|
||||
|
||||
# What's MTA-STS, why it makes email routing safer, amd how to set it up
|
||||
|
||||
Modern email uses Transfer Layer Security (TLS) to keep messages safe from prying eyes as they move between mail servers. But did you know that, without additional safeguards, TLS can often be bypassed? This is where Mail Transfer Agent Strict Transport Security (MTA-STS) comes in.
|
||||
Modern email uses Transfer Layer Security (TLS) to keep messages safe from prying eyes as they move between mail servers. Without additional safeguards, TLS can often be bypassed. This is where Mail Transfer Agent Strict Transport Security (MTA-STS) comes in.
|
||||
|
||||
## What is MTA-STS?
|
||||
|
||||
MTA-STS is a standard designed to protect Simple Mail Transfer Protocol (SMTP) connections between mail servers from downgrade and Man-in-the-Middle (MitM) attacks. It enforces that inbound email for your domain is only accepted over authenticated TLS connections.
|
||||
|
||||
Even though SMTP with STARTTLS has been around for years, it’s not foolproof - attackers can trick servers into falling back to insecure connections unless you use like MTA-STS.
|
||||
Even though SMTP with STARTTLS has been around for years, it's not foolproof - attackers can trick servers into falling back to insecure connections unless you use MTA-STS.
|
||||
|
||||
## How does mail transfer between servers?
|
||||
|
||||
Email messages sent from one domain to another travel over the public internet. First, the sender's server looks up the recipient’s server using MX (Mail Exchange) records.
|
||||
|
||||
Then, optionally, both servers attempt to establish a TLS connection using STARTTLS. Without further protection, attackers can downgrade this connection, making email transfer vulnerable.
|
||||
Then, optionally, both servers attempt to establish a TLS connection using STARTTLS. Without further protection, attackers can downgrade this connection, making the process vulnerable.
|
||||
|
||||
## What are the risks without MTA-STS?
|
||||
|
||||
Without MTA-STS, email can be silently intercepted by attackers who force a connection downgrade or present fake certificates during a MitM attack. As a result your email can be read in clear text by third parties. MTA-STS ensures the sending server verifies it is using a secure, valid TLS connection, or the transition fails.
|
||||
|
||||
## Full syntax explained
|
||||
## Practical example
|
||||
|
||||
The MTA-STS policy is a plain text file published at a fixed location on your web server:
|
||||
|
||||
`https://mta-sts.example.com/.well-known/mta-sts.txt`
|
||||
|
||||
The minimum required fields:
|
||||
|
||||
The text file should look like this:
|
||||
```
|
||||
version: STSv1
|
||||
mode: enforce
|
||||
mx: mx1.example.com
|
||||
mx: mx.example.com
|
||||
max_age: 86400
|
||||
```
|
||||
|
||||
- `version`: Must be `STSv1`. As of now, there are no other versions.
|
||||
- `mode`: Supported values are `enforce`, `testing`, or `none`.
|
||||
- `mx`: One or more MX hostnames. Wildcards are also supported, like `*.hexname.com`.
|
||||
- `mx`: One or more MX hostnames. Wildcards are also supported, like `*.example.com`.
|
||||
- `max_age`: Time in seconds for which the policy is valid (86400 is one day).
|
||||
|
||||
You can check MTA-STS policies in the browser, e.g.: <a rel="nofollow noopener" target="_blank" href="https://mta-sts.gmail.com/.well-known/mta-sts.txt">https://mta-sts.gmail.com/.well-known/mta-sts.txt</a>
|
||||
|
|
@ -81,7 +80,7 @@ This means the specified email address receives reports about failed or downgrad
|
|||
|
||||
## Practical example
|
||||
|
||||
If you host your DNS with <a href=https://hexname.com>HexName</a> and your mail server is `mx.example.hexname.com`. You would:
|
||||
If you host your DNS with <a href=https://hexname.com>HexName</a>, and your mail server is `mx.example.hexname.com`, you would:
|
||||
|
||||
1. Publish your policy at `https://mta-sts.example.hexname.com/.well-known/mta-sts.txt`, e.g.:
|
||||
|
||||
|
|
@ -120,4 +119,4 @@ _smtp._tls.example.hexname.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@
|
|||
|
||||
## Summary
|
||||
|
||||
MTA-STS is straightforward to set up but adds much-needed security to your domain’s inbound email - so no one will be sniffing your emails.
|
||||
MTA-STS is straightforward to set up but adds much-needed security to your domain’s inbound email - so no one will be intercepting your emails.
|
||||
|
|
@ -1,29 +1,31 @@
|
|||
---
|
||||
title: Essential DNS records for mailservers explained
|
||||
subtitle: How to set up all essential DNS records for reliable mail delivery
|
||||
description: Learn which DNS records are required for a functional mailserver, how to configure them, and get best-practice tips for A, AAAA, MX, SPF, DKIM, and DMARC records.
|
||||
description: Learn which DNS records are required for a functional mailserver, what they do, and best-practices for A, AAAA, MX, SPF, DKIM, and DMARC records.
|
||||
---
|
||||
|
||||
# All DNS records needed for a functional mailserver
|
||||
|
||||
Setting up your own mailserver can sound intimidating, but ensuring the right Domain Name System (DNS) records are in place is essential for making sure emails are delivered and not rejected or flagged as spam.
|
||||
Setting up your own mailserver may sound intimidating, but it's not all that hard - given that the setup only has to be done once.
|
||||
|
||||
Here, we’ll walk through every DNS record type that’s necessary and relevant security records for a reliable and standards-compliant mail system.
|
||||
Here, we'll walk through every DNS record type that's necessary, and explain relevant security records for a reliable and standard-compliant mail system.
|
||||
|
||||
Ensuring the right DNS records are in place is essential for making sure emails are delivered and not rejected or flagged as spam.
|
||||
|
||||
## A and AAAA records: pointing to your mailserver
|
||||
|
||||
**A records** (Address records) map a domain or subdomain to an IPv4 address, while **AAAA records** do the same for IPv6 addresses. These are crucial, as the server where your mailserver runs must have its address resolvable.
|
||||
**A/AAAA records** (Address records) map a domain or a subdomain to an IPv4/IPv6 address. This is how you let the world know at which location your mailserver is located.
|
||||
|
||||
Example A record:
|
||||
```
|
||||
mx.example.hexname.com. A 198.51.100.42
|
||||
mx.example.com. A 198.51.100.42
|
||||
```
|
||||
Example AAAA record:
|
||||
```
|
||||
mx.example.hexname.com. AAAA 2001:db8:abcd:1234::42
|
||||
mx.example.com. AAAA 2001:db8:abcd:1234::42
|
||||
```
|
||||
Tips:
|
||||
- Use `mx.example.hexname.com` (not your root domain) to separate mailserver traffic.
|
||||
- Use `mx.example.com` (not your root domain) to host the mailserver.
|
||||
- For better compatability, use both A and AAAA records.
|
||||
|
||||
## MX records: announcing where to deliver email
|
||||
|
|
@ -32,9 +34,11 @@ Tips:
|
|||
|
||||
Example MX record:
|
||||
```
|
||||
example.hexname.com. MX 10 mx.example.hexname.com.
|
||||
example.com. MX 10 mx.example.com.
|
||||
```
|
||||
- Use only hostnames (like `mx.example.hexname.com`), never direct IPs, for the value.
|
||||
Explanation: `mx.example.com` receives mail on behalf of `example.com`.
|
||||
|
||||
- Use only hostnames (like `mx.example.com`), for the value.
|
||||
- You can set multiple MX records with varying priority for failover. This ensures that if your primary mailserver has downtime, the second one can take over.
|
||||
|
||||
> Having a backup mailserver is not *so* important since email implements retries with incremental backoffs. So if a delivery to your one and only mailserver fails, it will be retried over the course of the day and the week.
|
||||
|
|
@ -50,11 +54,11 @@ SPF specifies which mailservers are authorized to send for your domain. This is
|
|||
Its value is placed in a TXT record:
|
||||
|
||||
```
|
||||
example.hexname.com. TXT "v=spf1 a mx -all"
|
||||
example.com. TXT "v=spf1 a mx -all"
|
||||
```
|
||||
Meaning:
|
||||
- `a` allows the A/AAAA IPs of `example.hexname.com` to send emails
|
||||
- `mx` allows the MX servers for the domain (so, `mx.example.hexname.com`)
|
||||
- `a` allows the A/AAAA IPs of `example.com` to send emails
|
||||
- `mx` allows the MX servers for the domain (so, `mx.example.com`)
|
||||
- `-all` means "fail if the previous conditioned didn't match"
|
||||
|
||||
> A domain can only have one SPF TXT record. The rest will be ignored.
|
||||
|
|
@ -66,7 +70,7 @@ DKIM lets your server sign outgoing emails with a cryptographic key, which recip
|
|||
The exact steps for acquiring the record depend on your mail software, but here is a general example:
|
||||
|
||||
```
|
||||
default._domainkey.example.hexname.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
|
||||
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
|
||||
```
|
||||
- `default` is the selector and can be any word set by your mailserver config
|
||||
- The `p=` value is your public key
|
||||
|
|
@ -79,7 +83,7 @@ DMARC tells receiving mailservers how to handle mail that fails SPF, DKIM, or bo
|
|||
|
||||
An example of a strong DMARC policy is:
|
||||
```
|
||||
_dmarc.example.hexname.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.hexname.com"
|
||||
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
|
||||
```
|
||||
- `p=reject` can also be `none` (for testing) or `quarantine` (to send the failing emails into quarantine).
|
||||
- `rua=` specifies an email address for DMARC aggregate reports. The recipient is usually not a person, but rather an automated service that provides reports in a human-readable format.
|
||||
|
|
@ -88,20 +92,20 @@ _dmarc.example.hexname.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-report
|
|||
|
||||
## Filling your DNS records
|
||||
|
||||
If using a DNS service like <a href=https://hexname.com>HexName.com</a>, you can register a subdomain (like `example.hexname.com`), create an MX record (such as `mx.example.hexname.com`), and add the above A, AAAA, MX, and TXT records. Ensure each record is entered precisely.
|
||||
If you're using a DNS service like <a href=https://hexname.com>HexName.com</a>, you can register a subdomain (like `example.hexname.com`), create an MX record (such as `mx.example.hexname.com`), and add the above A, AAAA, MX, and TXT records. Ensure each record is entered precisely.
|
||||
|
||||
A complete (minimal) set for secure mail delivery:
|
||||
- A/AAAA records pointing to your mailserver's IP
|
||||
- MX record on `example.hexname.com` pointing to `mx.example.hexname.com`
|
||||
- MX record on `example.hexname.com` pointing to `mx.example.hexname.com` (where your mailserver is running)
|
||||
- SPF TXT on `example.hexname.com` with the contents `"v=spf1 a mx -all"`
|
||||
- DKIM TXT on `default._domainkey.example.hexname.com`
|
||||
- DMARC TXT on `_dmarc.example.hexname.com` with the contents `v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.hexname.com`
|
||||
|
||||
These records ensure your mail can both arrive and be accepted by most of the world.
|
||||
|
||||
Many free online "mailserver tester" tools exist, letting you double-check your mailserver configuration. Our recommendations are:
|
||||
Many free online "mailserver tester" tools exist, letting you verify your mailserver configuration is correct. We recommend checking out:
|
||||
- [MxToolBox's SMTP diagnostic tool](https://mxtoolbox.com/diagnostic.aspx)
|
||||
- [Mail Tester](https://www.mail-tester.com/) - to check the "spammyness" of your mailserver
|
||||
- And many others!
|
||||
|
||||
After you're done with the basics, you can look into MTA-STS, TLS reporting, SPF reporting as well as methods to help ensure decent deliverability.
|
||||
After you're done with the basics, you can look into MTA-STS, TLS and SPF reporting, TLSA, DANE, as well as methods to help ensure good deliverability.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Why VPS providers block outgoing email ports by default
|
||||
subtitle: Understanding default SMTP port restrictions on VPS hosting
|
||||
description: Many VPS providers block outgoing email ports to mitigate spam and prevent IP blacklisting. This article explains the technical reasons, real-world consequences, and industry best practices for managing email delivery on virtual servers.
|
||||
description: Many VPS providers block outgoing email ports to mitigate spam. We dive into how email spam has developed and best practices for avoiding landing in spam.
|
||||
---
|
||||
|
||||
# Why VPS providers block outgoing email ports by default due to spam
|
||||
|
|
@ -21,17 +21,17 @@ Ironically, the [first-ever email spam](https://www.templetons.com/brad/spam/spa
|
|||
|
||||
To fight junk mail, the industry relies on publicly available blocklists. If a mailserver's IP address is reported or detected as sending spam, it is added to these lists and may be denied by receiving servers. Some key features:
|
||||
|
||||
- **Reputation systems**: Large email providers (Gmail, Outlook, iCloud Mail, Yahoo, etc.) maintain internal tracking of sender reputation, making delivery difficult for servers with histories of abuse.
|
||||
- **Reputation systems**: Large email providers (Gmail, Outlook, iCloud Mail, Yahoo, etc.) maintain internal tracking of sender reputation, making delivery difficult for servers with histories of abuse. Metrics like how many emails sent by you are opened (called the Click Through Rate (CSR)) among others are taken in consideration.
|
||||
- **Blocklist checks**: Publically available spam blocklists maintain a list of IPs that send out unwanted emails in large amounts. You can use free online services to check if your server's IP is on these lists. They usually include options to appeal to the block.
|
||||
|
||||
For example, after obtaining an IP address from your hosting provider, you can check your mailserver's IP reputation with the popular lists such as [Spamhaus](https://www.spamhaus.org/ip-reputation/) or [MXToolBox's free tool](https://mxtoolbox.com/blacklists.aspx) and appeal to the blocklists directly.
|
||||
For example, after obtaining an IP address from your hosting provider, you can check your mailserver's IP reputation with the popular lists such as [Spamhaus](https://www.spamhaus.org/ip-reputation/) or [MXToolBox's free tool](https://mxtoolbox.com/blacklists.aspx) to do a lookup against major blocklists and appeal to them directly.
|
||||
|
||||
## VPS providers and port restrictions
|
||||
|
||||
Due to the ease of obtaining new IPs and cheap temrporary servers, spammers have historically used them to launch mass email campaigns. Nowadays, to limit abuse, most VPS providers block outgoing traffic on SMTP standard ports (such as `25`, `465`) by default.
|
||||
Due to the ease of obtaining new IPs and cheap temporary servers, spammers have historically used them to launch mass email campaigns. Nowadays, to limit abuse, most VPS providers block outgoing traffic on SMTP standard ports (such as `25`, `465`) by default.
|
||||
|
||||
If your server needs to send legitimate email, contact your VPS provider to request port unblocking.
|
||||
If your server needs to send legitimate email, you can contact your VPS provider to request port unblocking.
|
||||
|
||||
You can also use an SMTP relay service, which handles hosting the mailserver for you. This isn't really a viable option though if you're looking to self-host your mailserver, and learn about the intricacies of email.
|
||||
|
||||
For users needing to get a mailserver up and running simply and fast, free DNS hosting services like <a href="https://hexname.com">HexName</a> allow registration of subdomains (like `example.hexname.com`) and creation of necessary DNS entries such as MX records for mail handling, TXT for SPF/DKIM, SRV, and so on.
|
||||
For users needing to get a mailserver up and running simply and fast, free DNS hosting services like <a href="https://hexname.com">HexName</a> allow registration of subdomains (like `example.hexname.com`) and creation of necessary DNS entries such as MX records for mail handling, TXT for SPF/DKIM, SRV, and so on. Check out our blog on <a href="https://hexname.com/blog/setting-up-mailserver-dns">explaining how to set up a mailserver put simply</a>.
|
||||
|
|
@ -43,7 +43,7 @@
|
|||
<form
|
||||
class="formset bg-base-200 border-base-300 rounded-box w-xs border p-4 z-1 translate-y-2"
|
||||
onsubmit={handleSubmit}>
|
||||
<legend class="fieldset-legend">Are you sure you want to delete your account?</legend>
|
||||
<h1 class="fieldset-legend">Are you sure you want to delete your account?</h1>
|
||||
<button class="btn btn-error w-full mt-2 mb-3" type="submit">Delete my account</button>
|
||||
<div role="alert" class="alert p-0 mb-2 flex flex-column justify-center">
|
||||
<svg class="stroke-error h-4 w-4" fill="none" viewBox="0 0 24 24"><path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M13 16h-1v-4h-1m1-4h.01M21 12a9 9 0 11-18 0 9 9 0 0118 0z"></path></svg>
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@
|
|||
<form
|
||||
class="formset bg-base-200 border-base-300 rounded-box w-xs border p-4 z-1 translate-y-2"
|
||||
onsubmit={handleSubmit}>
|
||||
<legend class="fieldset-legend">Forgot your password?</legend>
|
||||
<h1 class="fieldset-legend">Forgot your password?</h1>
|
||||
<div class="mt-4">
|
||||
<label class="text-primary-content" for="email">Email</label>
|
||||
<input class="input validator" id="email" name="email" autocomplete="email" type="email" bind:value={email} placeholder="you@example.com" required/>
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@
|
|||
<form
|
||||
class="formset bg-base-200 border-base-300 rounded-box w-xs border p-4 z-1 translate-y-2"
|
||||
onsubmit={handleSubmit}>
|
||||
<legend class="fieldset-legend">Log in to your account</legend>
|
||||
<h1 class="fieldset-legend">Log in to your account</h1>
|
||||
<div class="mt-4 mb-2">
|
||||
<label class="text-base-content" for="email">Email</label>
|
||||
<input class="input validator" id="email" name="email" autocomplete="email" type="email" bind:value={email} placeholder="you@example.com" required/>
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@
|
|||
<form
|
||||
class="formset bg-base-200 border-base-300 rounded-box w-xs border p-4 z-1 translate-y-2"
|
||||
onsubmit={handleSubmit}>
|
||||
<legend class="fieldset-legend">Create your account</legend>
|
||||
<h1 class="fieldset-legend">Create your account</h1>
|
||||
<div class="mt-4 mb-2">
|
||||
<label class="text-primary-content" for="email">Email</label>
|
||||
<input class="input validator" id="email" name="email" autocomplete="email" type="email" bind:value={email} placeholder="you@example.com" required/>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue