Most likely you are visiting this page due to issues with our mail systems. Please refer to the information below for help, and contact firstname.lastname@example.org only if your question was not answered.
|IP address||FQDN and PTR||Location|
Our mail infrastructure processes up to 100 MiB per message. Please consider alternate submission channels (mirror, rsync, ...) for bigger files.
Our mail servers support transport encryption via
TLSv1.3 (preferred) with opportunistic DANE support enabled. Certificate is provided in both SMTP server and client scenario, and can be validated by using DANE.
ipfire.org is DNSSEC-signed.
For interoperability reasons, a relaxed cipher suite is currently deployed for both SMTP server and client, as some mail servers lack support for modern cryptography. We enforce
TLSv1.2 or better and Forward Secrecy for destinations with DANE information available.
Our mail infrastructure applies the following criteria on both incoming and outgoing messages (except for the first one for obvious reasons) and refuses to deliver mails that violate one of these:
ade(Microsoft Access Project Extension)
adp(Microsoft Access Project)
asx(Windows Media Audio/Video)
bas(Microsoft Visual Basic class module)
cmd(Microsoft Windows NT Command Script)
com(MS-DOS executable file)
cpl(system control file)
hlp(Microsoft Help file)
ins(Internet Naming Service)
isp(Internet Communication Settings)
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)
prf(Microsoft Outlook Profile file)
scf(Windows Explorer file)
scr(Microsoft Screensaver program)
sct(Windows Script File)
shb(Shell Scrap File)
shs(Shell Scrap Object)
vbe(encoded VBScript file)
vsmacros(Visual Studio .NET binary-based macro project)
vsw(Visio Workspace file)
ws(Windows Script file)
wsc(Windows Script component)
wsf(Windows Script file)
wsh(Windows Scripting Host settings)
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.