Postmaster information

Most likely you are visiting this page due to issues with our mail systems. Please refer to the information below for help, and contact postmaster@ipfire.org only if your question was not answered.

Mail servers


IP address	FQDN and PTR	Location
`81.3.27.42`	`mail01.ipfire.org`	Hanover, DE
`2001:678:b28::25`	`mail01.ipfire.org`	Hanover, DE

Message size limit

Our mail infrastructure processes up to 100 MiB per message. Please consider alternate submission channels (mirror, rsync, ...) for bigger files.

Transport encryption

Our mail servers support transport encryption via STARTTLS using TLSv1.2 to TLSv1.3 (preferred) with opportunistic DANE support enabled. RSA and ECDSA (preferred) certificates are provided in both SMTP server and client scenario, and can be validated by using DANE. ipfire.org and most other domains served by the project's mail infrastructure are DNSSEC-signed.

We enforce TLSv1.2 or better and Forward Secrecy for inbound and outbound SMTP traffic. Fallback to plaintext is possible unless the destination announces DANE support; please ensure your mail systems are capable of modern transport encryption.

For security reasons, TLSv1.0 and TLSv1.1 are not supported.

Acceptable Use Policy

Our mail infrastructure applies the following criteria on both incoming and outgoing messages (except for the first one for obvious technical reasons) and refuses to deliver mails that violate one of these:

A message must not be delivered from an IP address listed at common RBLs, such as Spamhaus ZEN (includes IP ranges used for dial-up purposes), NiX Spam or blocklist.de. Choice of RBLs was made based on eco e.V. recommendations.
A message must not contain URLs whose FQDN is listed at common URIBLs, e.g. for hosting malware or phishing sites. This includes the FQDNs used in the Reply-To header, DKIM signatures, the HELO/EHLO banner of the submitting server and the PTR of its IP address.
A message must not contain URLs whose FQDN resolves to IP addresses with poor reputation.
A message must not have attachments with double file extensions such as document.pdf.exe.
A message must not have nested archive attachments, which are often abused for bypassing AV scanners. Compress the stuff you want to send once, and consider changing compression algorithm if the size does not fit afterwards.
A message must not have encrypted archive attachments. Use GPG or S/MIME instead.
A message must not have attachments (or archives containing items) with file extensions as follows:
- ade (Microsoft Access Project Extension)
- adp (Microsoft Access Project)
- asx (Windows Media Audio/Video)
- bas (Microsoft Visual Basic class module)
- bat (batch file)
- cmd (Microsoft Windows NT Command Script)
- com (MS-DOS executable file)
- cpl (system control file)
- exe (executable file)
- hlp (Microsoft Help file)
- hta (HTML program)
- inf (setup information)
- ins (Internet Naming Service)
- iso (ISO images)
- isp (Internet Communication Settings)
- jnlp (Java Network Launching Protocol)
- js (JavaScript file)
- jse (JavaScript encoded file)
- msc (Microsoft Console Program)
- msi (Microsoft Installation Package)
- msp (Microsoft Installation Patch)
- mst (Microsoft Installation Program or Visual Test Source file)
- pcd (Photo CD file or Visual compiled script)
- pif (MS-DOS Shortcut)
- prf (Microsoft Outlook Profile file)
- rpmsg (restricted-permission message)
- scf (Windows Explorer file)
- scr (Microsoft Screensaver program)
- sct (Windows Script File)
- sfx (self-extracting Zip-archive)
- shb (Shell Scrap File)
- shs (Shell Scrap Object)
- vb (VBScript file)
- vbe (encoded VBScript file)
- vbs (VBScript file)
- vsmacros (Visual Studio .NET binary-based macro project)
- vss (Visio Stencil)
- vst (Visio Template)
- vsw (Visio Workspace file)
- ws (Windows Script file)
- wsc (Windows Script component)
- wsf (Windows Script file)
- wsh (Windows Scripting Host settings)
- xll (Excel add-in file)
Delivering IP address must have a PTR set which resolves back to the IP address itself.
Messages violating a senders' DMARC reject policy will be rejected, with some exceptions for popular mailing lists breaking both SPF and DKIM.

DMARC

As mentioned above, we generally honour DMARC reject policies unless this causes automated unsubscribing due to excessive bounces. ipfire.org and other domains handled by our mail infrastructure are either announcing a DMARC quarantine or reject policy, depending on the mail characteristics for the domain in question.

Selective greylisting

Suspicious and potentially dangerous messages will be greylisted to give our content scanners more time to classify them. If your MTA has a slightest clue of RFCs, there is no need to ask us for being "whitelisted" from greylisting.

Proactive whitelisting

Our mail servers are covered by ID 58468 at DNSWL.org. We strive for a good reputation of these, and honor DNSWL listings of SMTP clients as well in order to reduce false positives.

Escalation blacklistings

Repeated user complaints will lead to appropriate escalation blacklistings of the senders' IP networks and domains. Should this affect you, please do not contact us; if you don't want to be treated as a spammer, don't behave like one.