[pfx] Implementing From: field heuristic when sending messages?
Dear Postfix users, A user had their password guessed/leaked, and the account was used to send spam/phishing messages – but only once an hour or so, so it wasn’t detected as abnormal traffic. One thing detectable thing would have been, that the sent unsolicited messages used a different name than the user in the From: field. Jennifer Wood To detect phishing messages on the receiving end, we already maintain a list in regexp-header for “important” people, so names used in From: have to match certain email addresses. The names are already present in the user name or comment field in `/etc/passwd` but also some LDAP database. Has somebody already experience with implementing such a heuristic, and is it useful¹? If it is useful, how could I do it? Probably an exact match would cause too much trouble, as some users want to put their academic title to the field too. Kind regards, Paul ¹ After a while the criminals are going to adapt, and just use the correct name for the account. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to reject messages on submission with typo in To address?
Dear Viktor,
Thank you for the quick reply with a solution.
Am 21.01.24 um 16:55 schrieb Viktor Dukhovni via Postfix-users:
On Sun, Jan 21, 2024 at 09:39:06AM +0100, Paul Menzel wrote:
pg.de is currently a parked domain, so our users will not going to
email there, and I would like to reject such messages submitted to us,
that the email client shows an error as it’s done, when, for example,
users submit a message to a colleague at our institute, and we now
that address does not exist, because the account was closed or it does
not exist.
Could you recommend a way how to best set this up, best with a custom error
message per domain? For example:
Reject: Address has a typo: Should .pg.de .mpg.de?
`master.cf` currently contains:
141.14.17.8:submission inetn - n - - smtpd
-o myhostname=mx.molgen.mpg.de
-o smtpd_recipient_restrictions=$mx_smtpd_recipient_restrictions
-o smtpd_client_recipient_rate_limit=50
main.cf:
indexed = ${default_database_type}:${config_directory}/
transport_maps = ${indexed}transport
transport:
.pg.de error:5.1.2 Typo domain .pg.de should be .mpg.de
Thank you. Indeed. I added it to our existing transport map:
# postconf transport_maps
transport_maps = hash:/project/mx/etc/transport
# grep -E ^.?pg\.de /project/mx/etc/transport
pg.de error:5.1.2 Typo in domain pg.de -- should
be mpg.de
.pg.de error:5.1.2 Typo in domain .pg.de -- should
be .mpg.de
Thank you again and kind regards,
Paul
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to reject messages on submission with typo in To address?
Dear Postfix users, The Max Planck Society consists of several institutes/organizations each running their own email infrastructure (which is good, as it’s decentralized. Most of them have the a subdomain under mpg.de, and sometimes we notice users from our institute sending emails to colleagues with a typo, for example, xy.pg.de with a missing *m*. pg.de is currently a parked domain, so our users will not going to email there, and I would like to reject such messages submitted to us, that the email client shows an error as it’s done, when, for example, users submit a message to a colleague at our institute, and we now that address does not exist, because the account was closed or it does not exist. Could you recommend a way how to best set this up, best with a custom error message per domain? For example: Reject: Address has a typo: Should .pg.de .mpg.de? `master.cf` currently contains: 141.14.17.8:submission inetn - n - - smtpd -o myhostname=mx.molgen.mpg.de -o smtpd_recipient_restrictions=$mx_smtpd_recipient_restrictions -o smtpd_client_recipient_rate_limit=50 Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: (Patch "half-dane" logging corner case) Untrusted TLS connections where email domain does not support DNSSEC but MX server has DNSSEC/DANE records
Dear Viktor, dear Wietse,
Am 25.11.22 um 17:25 schrieb Viktor Dukhovni:
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
Viktor Dukhovni:
However, in this case the issue is a minor oversight in the Postfix TLS
client code. The intended logging behaviour does not happen. Patch
below:
Is there an equivalent for the still supported Postfix version 3.5?
That would also fix Postfix version 3.4 which has the same code.
An alternative (equivalent) form of the patch for 3.6+ could be the
below, which is perhaps closer to the 3.5 logic:
--- src/tls/tls_client.c
+++ src/tls/tls_client.c
@@ -324,6 +324,7 @@ static void verify_extract_name(TLS_SESS_STATE *TLScontext,
X509 *peercert,
* checks are now performed internally in OpenSSL.
*/
if (SSL_get_verify_result(TLScontext->con) == X509_V_OK) {
+ TLScontext->peer_status |= TLS_CERT_FLAG_TRUSTED;
if (TLScontext->must_fail) {
msg_panic("%s: cert valid despite trust init failure",
TLScontext->namaddr);
@@ -352,8 +353,7 @@ static void verify_extract_name(TLS_SESS_STATE *TLScontext,
X509 *peercert,
TLScontext->namaddr, peername);
tls_dane_log(TLScontext);
}
- } else
- TLScontext->peer_status |= TLS_CERT_FLAG_TRUSTED;
+ }
}
/*
Just a late note, that this diff was applied in on 20221125. Thank you all.
Kind regards,
Paul
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: logging username in a failed smtp attemps
Dear Eric, Am 24.10.23 um 11:32 schrieb Eric Doutreleau via Postfix-users: i m using on my server postfix-3.5.8 and cyrus-sasl-2.1.27 I m using fail2ban too to prevent brute force attack. my problem is that when a connection failed because of wrong password i don't know what account is targeted the line is Oct 5 11:07:52 hermes postfix/smtpd[277411]: warning: unknown[122.179.129.110]: SASL LOGIN authentication failed: authentication failure There s no username logged. Is there a way to log this username? Jozsef Kadlecsik submitted a patch, and it was accepted and is going to be available in the 3.9 release [1]. 20231006 Cleanup: attempt to log the SASL username after authentication failure. This appends ", sasl_username=xxx" to SASL authentication failure logging. Based on code by Jozsef Kadlecsik. Files: xsasl/xsasl_server.c, xsasl/xsasl_cyrus_server.c, smtpd/smtpd_sasl_glue.c. Kind regards, Paul [1]: https://de.postfix.org/ftpmirror/experimental/postfix-3.9-20231012.HISTORY ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to hide Exim behind Postfix (Configuring Postfix as a proxy in front of Exim MTAs) (was: Possible (indirect) libspf2 security issues)
Dear Postfix, Am 30.09.23 um 22:47 schrieb Viktor Dukhovni via Postfix-users: Recent news of security issues in Exim appear to in part implicate libspf2. […] Off-topic for Postfix users, but Tobias Fiebig published the article *Configuring Postfix as a proxy in front of Exim MTAs* [1]. Kind regards, Paul [1]: https://doing-stupid-things.as59645.net/mail/2023/09/30/postfix-proxy-setup.html ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: email being flagged a spam for using localhost [127.0.0.1] as first hop
Dear Fourhundred, Am 09.08.23 um 07:34 schrieb Fourhundred Thecat via Postfix-users: my email was flagged as spam by Microsoft. I have the received email, together with all the headers that Microsoft added. Specifically the item: X-Microsoft-Antispam-Message-Info: I have found a tool on github, which attempts to decode this convoluted item (https://github.com/mgeeky/decode-spam-headers) And one of the decoded lines says: (5880045) - (GUESSING) Somehow related to First Hop server reputation, it's reverse-PTR resolution or domain impersonation I am using header rewrite to hide my own IP address, and use localhost [127.0.0.1] instead. So that the first hop looks like this: Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.xxx.yyy (Postfix) with ESMTPSA id 7E011B0 for ; Wed, 9 Aug 2023 07:04:42 +0200 (CEST) is this considered bad practice? Or why am I being penalized for this? All I am trying to achieve is not to disclose from where I am sending my emails Sounds like something spammers also would like to do, so it’s considered bad practice. But, it is also not feasible, as the accepting host often logs the IP address. So your strategy would only work, if you use a smarthost (SMTP relay server), deleting the `Received:` records from the header. So the receiver would only see the IP address of the smart host. As an example for your message to the list from GMX: Received: from [10.1.2.16] ([212.25.11.75]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3DJl-1qWda038fN-003eVr for ; Wed, 09 Aug 2023 07:34:49 +0200 mail.gmx.net is the smarthost, and would need to support to not add that Received entry (and remove possible other ones). Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] OT: Does the GPDR require mandatory/verified TLS encryption? (was: SMTP client: How to log reason for untrusted TLS connection to MX?)
Dear Jaroslow, Am 24.07.23 um 19:02 schrieb Jaroslaw Rafa via Postfix-users: Dnia 24.07.2023 o godz. 17:05:40 Paul Menzel via Postfix-users pisze: (Also from the legal perspective, without being a lawyer, I’d say, that actually all German (European) companies are required to only transmit messages over a verified TLS connection.) Never heard of such a requirement in any EU law. Article 32 of the GPDR [1] says: Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: a) the pseudonymisation and encryption of personal data; b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. (The German translation is “Stand der Technik“.) I claim, that using mandatory and verified TLS encryption is state of the art, and has basically no cost of implementation thanks to Let’s Encrypt, so is required especially for confidentiality. Kind regards, Paul [1]: https://gdpr-info.eu/art-32-gdpr/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: SMTP client: How to log reason for untrusted TLS connection to MX?
Dear Viktor, Thank you for your reply. Am 23.07.23 um 23:42 schrieb Viktor Dukhovni via Postfix-users: On Sun, Jul 23, 2023 at 11:22:26PM +0200, Paul Menzel wrote: Does it really matter why some site offering opportunistic STARTTLS does not have a validatable certificate? The connection can be trivially downgraded by an on-path attacker (stripping STARTTLS) to just be cleartext. Or the MX records could be forged (absent DNSSEC). As these are only a few, I’d take up the task of contacting these postmasters, so having the reason at hand would ease that task. Doing this manually, these steps would be done later, where the setup could change, and the result/behavior might be different. So having the reason at hand would also make it easier to clear up these situations. My point is that even the sites that are logged as "Trusted" are not fully validated (no hostname checkes are attempted or even entirely possible, given insecure MX indirection). With "Trusted" easily downgraded. What is the point of caring whether the MX host did or not present some random certificate from some random CA in your CA bundle? What actual problem are you solving? I don't see any value in certificate chain trust validation for its own sake, if no real security goals are met as a result. Ah, sorry for missing to clarify that. My goal is of course to set the level to *verify* in the future. With so few exceptions, that goal gets closer and closer. (Also from the legal perspective, without being a lawyer, I’d say, that actually all German (European) companies are required to only transmit messages over a verified TLS connection.) If you choose to use the unsupported (therefore not subject to Postfix stability guarantees) "smtp_tls_loglevel = certmatch, summary" setting, the additional lines are logged for every TLS handshake involving certificates, not just those that are "Untrusted". We build Postfix ourselves. If somebody has a (hackish) patch to achieve this, we could add it to our installation. I don't recommend attempting such a patch. If you *strongly* want the extra logging, just accept it even for valid connections. The "certmatch" logging becomes more succinct when raw public keys are supported and used by the peer. Line 1 shows the public key details, and line 2 the usual summary (signalling RPK use in a comment for the server signature). The "-x" flag would turn off mandatory X.509, enabling use of raw public keys. $ posttls-finger -x -F /etc/ssl/cert.pem -c -Lcertmatch,summary -lmay -o 'tls_medium_cipherlist = DEFAULT' dnssec-stats.ant.isi.edu 1 ->posttls-finger: dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: raw public key fingerprint=B1:E7:FA:AF:6E:48:2E:2A:FB:C6:53:C8:E3:B6:BE:F0:E3:35:24:24:AE:BD:24:D2:B4:80:09:29:51:BC:60:97 2 ->posttls-finger: Untrusted TLS connection established to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bit raw public key) server-digest SHA256 It sounds interesting, but unfortunately, I have no idea about raw public keys. I quickly read the introduction of the RFC 7250 [1], but do not understand yet, why it shows *Untrusted* in your example, and how it’d would solve my original problem. It does not solve your "original problem", this is just a caveat to let future readers know that the logging from "certmatch" may become a one-liner in some configurations that with cause don't care much about certificates, when they aren't used to ensure connection security. In fact, enabling raw public keys would take you further away from your puzzling goal of logging certificate trust chain validity issues (for certificates that may or may be legitimately for the host that you expect to connect to, which may or may not be the legitimate MX host of the destination domain). Perhaps for "opportunsitic" TLS connections we should stop routine and largely futile logging of whether the chain is "Trusted" or "Untrusted", to avoid encouraging users to try to read the tea-leaves? The summary log message for unauthenticated connections (may, encrypt or dane in the absense of TLSA records) might then take the form: TLS connection established to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bit raw public key) server-digest SHA256 And then, all temptation to fix "problems" with sites whose certificate trust chains are "invalid" go away. The trust status would then only be logged for destinations that require connection security (fingerprint, dane with TLSA, verify or secure). I see your point. No idea, how often these questions come up, but maybe changing the logging format is not warranted as it might cause other confusion. Just my two cents, I have no preference.
[pfx] Re: How to verify that DH key generation parameters from RFC 7919 are used?
Dear Ivan, Thank you very much for your reply. Am 12.07.23 um 10:16 schrieb Ivan Hadzhiev: You can copy from here: https://github.com/internetstandards/dhe_groups/blob/main/ffdhe4096.pem or you can create it openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 -out /etc/postfix/ffdhe4096.dh.param I downloaded the 3072 bit file and set it up: # wget -O /project/mx/etc/ffdhe3072.pem https://github.com/internetstandards/dhe_groups/blob/main/ffdhe3072.pem # postconf -n smtpd_tls_dh1024_param_file smtpd_tls_dh1024_param_file = /project/mx/etc/ffdhe3072.pem # postfix reload But the Internet.nl email test still says that DH 2048 is offered by mx3.molgen.mpg.de [1]. mx3.molgen.mpg.de. DH-2048 insufficient So I am still curious, how to verify that. Kind regards, Paul [1]: https://www.internet.nl/mail/recomb.org/972775/ ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] How to verify that DH key generation parameters from RFC 7919 are used?
Dear Postfix folks, The Internet.nl email test, reports for molgen.mpg.de [1]: Key exchange parameters Verdict: At least one of your mail servers supports insufficiently secure parameters for Diffie-Hellman key exchange. Technical details: c1241.mx.srv.dfn.de.DH-2048 insufficient b1241.mx.srv.dfn.de.DH-2048 insufficient a1241.mx.srv.dfn.de.DH-2048 insufficient DHE: The security of Diffie-Hellman Ephemeral (DHE) key exchange depends on the lengths of the public and secret keys used within the chosen finite field group. We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'. The test seems to follow Dutch recommendations: See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL [2], guideline B5-1 and table 9 for ECDHE, and guideline B6-1 and table 10 for DHE (in English). How can I check myself, what “DHE public key material“ is used to compare it with the ones specified in RFC 7919 [3]? Postfix’ *TLS Forward Secrecy in Postfix* [4] says: Postfix ≥ 3.1 supports 2048-bit-prime FFDHE out of the box, with no additional configuration. Where in the code would I find the key material? `tlsproxy/tlsproxy.c` calls `TLS_SERVER_INIT()`, and `tls_server_init()` in `tls/tls_server.c` contains: if (*props->dh1024_param_file != 0) tls_set_dh_from_file(props->dh1024_param_file); tls_tmp_dh(server_ctx, 1); That then seems to use the OpenSSL function d2i_DHparams? tls/tls_dh.c:if (d2i_DHparams(, , sizeof(builtin_der)) Kind regards, Paul PS: Is the “preferred” in the comment in `tls/tls_server.c` outdated? * Diffie-Hellman key generation parameters can either be loaded from * files (preferred) or taken from compiled in values. First, set the [1]: https://www.internet.nl/mail/molgen.mpg.de/968847/ [2]: https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1 [3]: https://www.rfc-editor.org/rfc/rfc7919.html [4]: https://www.postfix.org/FORWARD_SECRECY_README.html ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Detect/extract attachments in broken messages composed by Apple Mail
Dear Postfix folks, Apple Mail violates the standard [1], resulting in attachments only being shown in the HTML view. This behaviour is to be expected given the incorrect MIME structure of the message. It is: multipart/alternative text/plain multipart/mixed text/html attachment So when selecting the plain part, you don't see the attachment associated with the alternative part. The message structure should be: multipart/mixed multipart/alternative text/plain text/html attachment If we wanted to detect such messages, and add a notification or extract the attachment, what component would be the right part for such message alteration? A milter? (I am aware, that this will break with end-to-end encryption (GPG or S/MIME).) Kind regards, Paul [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1362539#c3 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] TLS client policy according to domain MTA-STS policy
Dear Postfix folks, Running the *Public Email & DNS Testbed* [1], I was reminded, that we have MTA-STS set up, but do not take the MTAT-STS policy of other domains into account. As a solution I found *postfix-mta-sts-resolver* [2], which warns about a “RFC violation” [3]: ### Warning: MTA-STS policy overrides DANE TLS authentication Due to Postfix's limitations, a resolved MTA-STS policy overrides DANE TLS authentication ([RFC 6698](https://www.rfc-editor.org/rfc/rfc6698)), because DANE is an internal feature of Postfix, and the postfix-mta-sts-resolver always responds with a ([`smtp_tls_policy_maps`](https://www.postfix.org/postconf.5.html#smtp_tls_policy_maps)) lookup result `secure` for [Secure server certificate verification](https://www.postfix.org/TLS_README.html#client_tls_secure). * The resulting behaviour is against [RFC 8461, 2](https://www.rfc-editor.org/rfc/rfc8461#section-2): > However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation. Domains implementing both MTA-STS and DANE probably want DANE to be preferred: * DANE allows strict binding of certificates; the policy can authorize only a certain certificate or certificates from a certain CA. With MTA-STS, a certificate from any trusted CA is automatically trusted; [RFC 8461, 10.1](https://www.rfc-editor.org/rfc/rfc8461#section-10.1): > SMTP MTA-STS relies on certificate validation via PKIX-based TLS identity checking [RFC6125]. Attackers who are able to obtain a valid certificate for the targeted recipient mail service (e.g., by compromising a CA) are thus able to circumvent STS authentication. * Based on DNSSEC, DANE not vulnerable to downgrade attack that could prevent policy discovery. MTA-STS security considerations acknowledges this weakness in [RFC 8461, 10.2](https://www.rfc-editor.org/rfc/rfc8461#section-10.2): > Since MTA-STS uses DNS TXT records for policy discovery, an attacker who is able to block DNS responses can suppress the discovery of an MTA-STS Policy, making the Policy Domain appear not to have an MTA-STS Policy. > Resistance to downgrade attacks of this nature -- due to the ability to authoritatively determine "lack of a record" even for non-participating recipients -- is a feature of DANE, due to its use of DNSSEC for policy discovery. * The postfix-mta-sts-resolver does not intent to implement policy lookups for DANE, and responses other than `secure` with `match=` would not verify the TLS certificate as required by [RFC 8461, 4,2](https://www.rfc-editor.org/rfc/rfc8461#section-4.2). If you wish to meet this requirement: * List a DANE policy resolver responding with `dane-only` (for [Mandatory DANE](https://www.postfix.org/TLS_README.html#client_tls_dane)) before postfix-mta-sts-resolver in `smtp_tls_policy_maps` lookup table list. * Alternatively, you could use a static lookup table for domains known to implement both MTA-STS & DANE, e.g., ``` smtp_tls_policy_maps = hash:/etc/postfix/tls_policy,socketmap:inet:127.0.0.1:8461:postfix ``` Do you know of other solutions? Kind regards, Paul [1]: https://www.email-security-scans.org/ [2]: https://github.com/Snawoot/postfix-mta-sts-resolver [3]: https://raw.githubusercontent.com/Snawoot/postfix-mta-sts-resolver/master/README.md ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: relocated: Allow custom message
Dear Matus, Thank you for your reply. Am 03.05.23 um 15:02 schrieb Matus UHLAR - fantomas via Postfix-users: On 03.05.23 14:53, Paul Menzel via Postfix-users wrote: Some of our users, that relocate, ask for a custom message over the current one: user has moved to new_location For example: This address is out of service. For business please contact funct...@company.example.net, or n...@private.example.net for private contact. I guess, it could be reworded to user has moved to n...@private.example.net, please contact funct...@company.example.net for business and use the current mechanism. Could a third column for a custom message be added to satisfy everybody? third column where? you can set up your mailserver to reject recipient address with e.g. by setting access map to: m...@example.com 551 moved to newm...@example.net Thank you for the hint. how do you currently implement the redirect mentioned above? # postconf -n relocated_maps relocated_maps = hash:/project/mx/etc/relocated relocated(5) [1] describes this mechanism [1]. Kind regards, Paul [1]: http://www.postfix.org/relocated.5.html ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] relocated: Allow custom message
Dear Postfix users, Some of our users, that relocate, ask for a custom message over the current one: user has moved to new_location For example: This address is out of service. For business please contact funct...@company.example.net, or n...@private.example.net for private contact. I guess, it could be reworded to user has moved to n...@private.example.net, please contact funct...@company.example.net for business and use the current mechanism. Could a third column for a custom message be added to satisfy everybody? Kind regards, Paul ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
