E-posti filtreerimistoimingute järjekord

Open

Order of email filtering operations

Open

Rämpsposti filtri mõjutamine

Rämpsposti filtri tööd on võimalik mõjutada, kui väärpositiivsete- ja negatiivsete filtreerimistulemuste kohta saata e-posti teenusepakkujale tagasisidet.

Vastav juhendmaterjal on leitav siin: Õngitsuskirjadest ja rämpspostist teavitamine

Affecting the spam filter

It is possible to influence the work of the spam filter by sending feedback to the e-mail service provider about false positive and negative filtering results.

The relevant guidance material can be found here: Phishing emails and spam reporting

Blokeeritud faililaiendid

Turvakaalutlustel on blokeeritud järgnevad faililaiendid e-kirja manustes. Rakendub antiviiruse filter ning saatjale edastakse sellekohane teavitus e-kirja kohaletoimetamata jätmisest.

Blocked file extensions

For security reasons, the following file extensions are blocked in e-mail attachments. An antivirus filter is applied, and the sender is notified of the non-delivery of the e-mail.

E-kirju saatvate teenuste ülesseadmine

Sissejuhatus

Tallinna Tehnikaülikooli mainekao ärahoidmiseks ning e-posti eesmärgil kasutatavate domeenide (nagu näiteks ttu.ee või taltech.ee) kaitsmiseks rakendame tehnoloogiaid, mis raskendavad kolmandatel osapooltel nende domeenidega e-posti aadressidelt kirjade saatmist.

Eelkõige on selle tegevuse eesmärk hoida ära Tallinna Tehnikaülikooli ning selle personali-tudengite nimel pahaloomuliste kirjade (pahavara, õngitsus, rämpspost) levitamist.

Käesolev artikkel puudutab erinevaid e-kirju saatvaid teenuseid nagu näiteks seiresüsteemid, automaatraportid, e-kaartide saatmiskeskkonnad, e-posti loendid ja muud taolised teenused.

E-posti klientide puhul (Microsoft Outlook, Mozilla Thunderbird), tuleb seadistada artiklis E-post ja listid / Email and lists nimetatud väljuv (SMTP) e-posti server.

Office365 veebipostkasti (mail.ttu.ee / mail.taltech.ee) ning domeeniarvutites ülesseatud Microsoft Outlooki see artikkel ei puuduta, nende puhul on vaikimisi seadistus korrektne.

Setting up email services

Introduction

To prevent loss of reputation of Tallinn University of Technology and to protect domains used for e-mail purposes (such as ttu.ee or taltech.ee ), we apply technologies that make it difficult for third parties to send emails from e-mail addresses with these domains.

Above all, the purpose of this activity is to prevent the distribution of malicious letters (malware, phishing, spam) on behalf of Tallinn University of Technology and its staff-students.

This article concerns various e-mail sending services such as monitoring systems, automatic reports, e-card sending environments, e-mail lists and other such services.

In the case of e-mail clients (Microsoft Outlook, Mozilla Thunderbird), the outgoing (SMTP) e-mail server mentioned in the article E-post and lists / Email and lists must be configured.

This article does not apply to the Office365 web mailbox (mail.ttu.ee / mail.taltech.ee) and Microsoft Outlook set up on domain computers, in their case the default setting is correct.

E-kirju saatvate teenuste ülesseadmise protsess

Uue e-kirju väljasaatva teenuse ülesseadmisel tuleb kontakteeruda IT osakonnaga (e-posti aadressil helpdesk@taltech.ee), et tagada e-kirjade korrektne laekumine adressaadini.

Kontakteerumisel tuleb edastada järgnev teave:

1. E-kirju saatev e-posti aadress (näiteks joulukaardid@taltech.ee).

2. E-kirju saatva teenuse nimi (näiteks SendSmaily).

3. E-kirju saatva serveri domeeninimi või IP aadress (näiteks onyx.ttu.ee / 193.40.242.230).

4. DKIM selectori nimi ja avalik võti (näiteks onyx  ja v=DKIM1; h=sha256; k=rsa; p=...).

Sisseostetud teenuste (Zone veebimajutus, SendSmaily, AmazonSES jmt) puhul võivad punktides 2 ja 3 nimetatud tehnilised parameetrid olla kas toodud välja teenuse dokumentatsioonis või kasutajakonto-spetsiifilised ning leitavad teenuse haldusliides. Kui teabe leidmisel tekib probleeme, on IT osakond valmis abistama.

Kuna ttu.ee ja taltech.ee SPF kannete suurus on tehnilisele piirmäärale lähedal ning DKIM selectorid võivad olla samanimelised, võib olla tarvilik e-kirjade saatmiseks kasutada alamdomeeni e-posti aadressi. Näiteks joulukaart@taltech.ee asemel joulukaart@turundus.taltech.ee.

Vajadusel saab kasutada e-kirjade saatmiseks IT osakonna poolt hallatavat e-posti serverit onyx.ttu.ee, mille puhul on võimalik vähese vaevaga rakendada SPF-i ning DKIM-i.

Process of setting up email services

When setting up a new e-mail sending service, you must contact the IT department (e-mail address helpdesk@taltech.ee) to ensure that e-mails are received correctly by the addressee.

When contacting, the following information must be provided:

Email address sending emails (for example joulukaardid@taltech.ee). The name of the email service (for example, SendSmaily). Domain name or IP address of the server sending e-mails (for example, onyx.ttu.ee / 193.40.242.230). DKIM selector name and public key (for example, onyx and v=DKIM1; h=sha256; k=rsa; p=...).

In case of purchased services (Zone web hosting, SendSmaily, AmazonSES, etc.), the technical parameters mentioned in points 2 and 3 can either be specified in the service documentation or user account-specific and can be found in the service management interface. If you have problems finding information, the IT department is ready to help.

Since the size of the SPF entries of ttu.ee and taltech.ee is close to the technical limit and the DKIM selectors may have the same name, it may be necessary to use a subdomain e-mail address to send e-mails. For example, joulukaart@turundus.taltech.ee instead of joulukaart@taltech.ee.

If necessary, you can use the onyx.ttu.ee e-mail server managed by the IT department to send e-mails, in which case it is possible to apply SPF and DKIM with little effort.

Tehnilised selgitused

Kirja adressaadi e-posti süsteemidel on võimalik tuvastada, kas meie domeenidelt laekunud kiri on tõesti pärit Tallinna Tehnikaülikoolilt või on tegemist saatja e-posti aadressi võltsimisega.

Selle tarbeks on meie poolt seadistatud-seadistamisel järgnevad tehnoloogiad:

1. Sender Policy Framework (SPF)

2. DomainKeys Identified Mail (DKIM)

3. Domain-based Message Authentication, Reporting, and Conformance (DMARC)

SPF on volitus, mis loetleb serverid, mis tohivad konkreetse domeeninimega (näiteks ttu.ee või taltech.ee ) e-kirju saata. SPF kontrollib MAIL FROM ehk RFC 5321 saatja aadressi. SPF kontroll ebaõnnestub edasisuunamise (fowarding) korral, kuid õnnestub e-kirja muutmise korral.

DKIM lisab allkirja tuvastamaks, kas transiidis olles on e-kirja muudetud ning kas kiri pärineb e-kirja saatja infrastruktuurist. DKIM kontrollib DATA FROM ehk RFC 5322 saatja aadressi. DKIM kontroll ebaõnnestub e-kirja muutmise korral (nt e-postiloendite poolt jaluse lisamisel), kuid õnnestub edasisuunatud (fowarded) kirjade puhul.

DMARC liidab eelnevad tehnoloogiad kokku, sätestab kontrollide ebaõnnestumisel tehtava toimingu ning ühtlasi annab IT osakonnale võimaluse saada taltech.ee või ttu.ee domeeni nimel saadetavate kirjade kohta raporteid.
Lisaks DMARC toob joondumise (alignment) kontsepti:

1. SPF kontrolli õnnestumiseks peavad olema MAIL FROM ja DATA FROM domeenid samad.

2. DKIM kontrolli õnnestumiseks peavad olema DATA FROM domeen ja kirja allkirjastav domeen samad.

DMARC puhul tarvitame kolme erinevat toimingut, sõltuvalt konkreetselt domeenilt saadetavate kirjade SPF ja DKIM kontrollide läbimise protsentuaalsusest:

1. p=none; - Kontrolle mitteläbivate kirjade puhul ei edastada soovitust konkreetsete toimingute tegemiseks. Taoline seadistus ei takista ka vääralt konfigureeritud seadistuse korral e-kirjade kohalejõudmist.

2. p=quarantine; - Kontrolle mitteläbivate kirjade puhul edastatakse soovitus need määrata rämpspostiks (junk).

3. p=reject; - Kontrolle mitteläbivate kirjade puhul edastatakse soovitus need lükata tagasi.

Tuleb arvestada, et p=quarantine; ja p=reject; toimingud on fail-deady - kui SPF või DKIM puudub või nende kontroll ei õnnestu, siis eeldatakse, et tegemist on võltsinguga. Senise praktilise kogemuse põhjal määratakse p=reject; puhul kontrolle mitteläbivatest kirjadest 80% rämpspostiks ja 20% lükatakse tagasi.

Olukorras, kus alamdomeenil puudub DMARC kanne, tarvitatakse organisatoorse domeeni (teise astme domeeni) DMARC kannet. Näiteks alamdomeen1.ttu.ee organisatoorne domeen on ttu.ee ; alamdomeen2.alamdomeen1.ttu.ee organisatoorne domeen on ttu.ee.

Käideldavusintsidendi-andmekao vältimiseks tuleb luua alamdomeenide SPF ja/või DKIM kanded või vajadusel luua alamdomeeni DMARC kanne eraldiseisva poliitikaga.

Technical explanations

The e-mail systems of the addressee of the letter can identify whether the letter received from our domains really comes from Tallinn University of Technology or whether the sender's e-mail address is forged.

For this purpose, the following technologies are set up by us:

1. Sender Policy Framework (SPF)

2. DomainKeys Identified Mail (DKIM)

3. Domain-based Message Authentication, Reporting, and Conformance (DMARC)

SPF is an authorization that lists servers that are allowed to send e-mails with a specific domain name (for example ttu.ee or taltech.ee ). SPF checks the MAIL FROM or RFC 5321 sender address. SPF check fails for forwarding but succeeds for email modification.

DKIM adds a signature to identify whether the e-mail has been modified in transit and whether the e-mail originated from the e-mail sender's infrastructure. DKIM verifies the DATA FROM or RFC 5322 sender address. The DKIM check fails when the e-mail is changed (e.g. when the footer is added by e-mail lists), but it succeeds for forwarded e-mails.

DMARC combines previous technologies, stipulates the action to be taken in the event of failed checks, and also gives the IT department the opportunity to receive reports on letters sent on behalf of the ttu.ee or taltech.ee domain.

In addition, DMARC introduces the concept of alignment:

1. For the SPF check to succeed, the MAIL FROM and DATA FROM domains must be the same.

2. For DKIM verification to succeed, the DATA FROM domain and the email signing domain must be the same.

For DMARC, we use three different actions, depending on the percentage of passing SPF and DKIM checks of messages sent from a specific domain:

1. p=none; - In the case of letters that do not pass inspection, a recommendation for specific actions is not forwarded. Such a setting does not prevent e-mails from being delivered even if the setting is incorrectly configured.

2. p=quarantine; - In the case of messages that do not pass the check, a recommendation to set them as spam (junk) is sent.

3. p=reject; - In the case of letters that do not pass inspection, a recommendation to reject them is sent.

It should be taken into account that p=quarantine; and p=reject; actions are fail-dead - if SPF or DKIM is missing or their verification fails, it is assumed that it is a fake. Based on practical experience so far, p=reject is set; 80% of the messages that do not pass the checks are spam and 20% are rejected.

In a situation where the subdomain does not have a DMARC entry, the DMARC entry of the organizational domain (second-level domain) is used. For example, the organizational domain of subdomain1.ttu.ee is ttu.ee ; the organizational domain of subdomain2.subdomain1.ttu.ee is ttu.ee.

SPF and/or DKIM records for subdomains must be created to prevent data loss from an availability incident or, if necessary, a DMARC record for a subdomain with a separate policy must be created.

Parimad praktikad; eesmärgid

1. Uute muudatuste sisseviimisel on soovitatav kasutada kannete puhul pigem lühikest eluiga (TTL), et võimalike eksimuste korral oleks muudatuse negatiivne mõju lühiajaline.

2. Igal kirju saatval (alam)domeenil peaks olema korrektne SPF-kirje. Eelistatud on kvalifikaator FAIL (-), kuid vajadusel on võimalik tarvitada kvalifikaatorit SOFTFAIL (~).

3. Postiserver peaks rakendama DKIMi, ehk allkirjastama e-kirju.

4. Domeenile rakendatakse DMARC kolmes etapis:

   1. p=none; - raportite hankimiseks, et nende põhjal teostada SPF ja DKIM seadistuses korrektuure. 

   2. p=quarantine; - domeeni osaliseks kaitsmiseks, üleminekuperiood seninägematute seadistusvigade kõrvaldamiseks.

   3. p=reject; - domeeni lõplikuks kaitsmiseks.

5. DMARC puhul kogutakse agregaatraporteid ja forensic raporteid. Agregaatraportite töötlemiseks kasutatakse sobilikke keskkondi. Forensic raportid kogutakse spetsiaalselt selleks otstarbeks loodud e-posti aadressile.

Best practices; goals

1. When introducing new changes, it is recommended to use a short lifetime (TTL) for entries, so that in case of possible mistakes, the negative impact of the change is short-lived.

2. Every mail-sending (sub)domain should have a correct SPF record. The qualifier FAIL (-) is preferred, but the qualifier SOFTFAIL (~) can be used if necessary.

3. The mail server should implement DKIM, i.e. sign e-mails.

4. DMARC is applied to a domain in three steps:

   1. p=none; - to get reports to make corrections in the SPF and DKIM settings based on them. 

   2. p=quarantine; - to partially protect the domain, a transition period to eliminate previously unseen configuration errors.

   3. p=reject; - to permanently protect the domain.

5. For DMARC, aggregate reports and forensic reports are collected. Suitable environments are used to process aggregate reports. Forensic reports are collected to an e-mail address specially created for this purpose.

Seadistuste teostamine

SPF, DKIM ja DMARC rakendamine käib läbi domeeninimede süsteemi (DNS) TXT- ja vajadusel CNAME kannete loomise. Seda teostatakse pädevate (authoritative) nimeserverite kaudu.

Tallinna Tehnikaülikoolis on ttu.ee ja taltech.ee DNS tsoonide pädevate nimeserverite halduriks IT osakond.

Erinevad struktuuriüksused võivad omada kolmandate domeenide või mõne ttu.ee / taltech.ee alamdomeeni pädevaid nimeservereid. Sellisel juhul toimub alamdomeeni SPF, DKIM (ja soovi korral DMARC) rakendamine struktuuriüksuse poolt.

Olukorras, kus alamdomeenil puudub DMARC kanne, rakendub organisatoorse domeeni (eelkõige ttu.ee või taltech.ee ) DMARC kanne.

Execution of settings

SPF, DKIM and DMARC are applied through the creation of TXT and, if necessary, CNAME entries in the Domain Name System (DNS). This is done through authoritative name servers.

At Tallinn University of Technology, the competent name servers of the ttu.ee and taltech.ee DNS zones are managed by the IT department.

Different structural units may have competent name servers of third domains or some subdomains of ttu.ee / taltech.ee . In this case, SPF, DKIM (and, if desired, DMARC) of the subdomain will be implemented by the structural unit.

In a situation where the subdomain does not have a DMARC entry, the DMARC entry of the organizational domain (especially ttu.ee or taltech.ee ) applies.

Zone veebimajutuse probleem

Zone virtuaalserveri pakett I puhul ei allkirjastata veebiserveri poolt (näiteks WordPressi uuendusteavitused või veebilehel asuvad tagasisidevormid) saadetavaid kirju DKIM-ga.
Allkirjastatakse üksnes veebipostkasti või e-posti kliendi vahendusel saadetud e-kirju.

Kuna veebiserverist saadetud e-kirjade saatjate aadressid ei joondu (Return path: virtXXXXX@vserver.zonevs.eu ning Sender: John.Smith@taltech.ee), ei ole taolisi kirju võimalik DMARC mõistes SPF-abiga valideerida.

Korrektseim lahendus oleks tarvitada virtuaalserveri paketti II või III. Alternatiividena võib olla lahenduseks  veebiserveri saatja aadressiks seada zonevs.eu domeen, kuid hetkeseisuga on taoline lahendus testimata.

https://www.zone.ee/et/virtuaalserver/vordlus/

Zone web hosting problem

In the case of Zone virtual server package I, emails sent by the web server (for example, WordPress update notifications or feedback forms located on the website) are not signed with DKIM.

Only e-mails sent via an online mailbox or e-mail client are signed.

Since the addresses of the senders of e-mails sent from the web server do not align (Return path: virtXXXXX@vserver.zonevs.eu and Sender: John.Smith@taltech.ee), it is not possible to validate such e-mails with SPF in terms of DMARC.

The most correct solution would be to use the virtual server package II or III. Alternatively, the solution may be to set the zonevs.eu domain as the sender address of the web server, but at the moment such a solution is untested.

Compare Web Hosting plans - (zone.ee)

E-posti loendite seadistamine

E-posti loendite puhul tuleb arvestada asjaoluga, et teatud seadistuste korral eksisteerib oluline risk, et loendid oma tegevustega põhjustavad SPF- ning DKIM kontrollide ebaõnnestumise.

Ebaõnnestumine tuleneb eelkõige kahest asjaolust:

1. Postiloendid võivad muuta e-kirjade sisu, mis põhjustab DKIM signatuuri mittevalideerumise. Näiteks võidakse tarkvara poolt lisada e-kirja pealkirjale eesliide või e-kirja jalusesse teave postiloendi kohta.

2. Postiloendid võivad kasutada e-kirja väljasaatmiseks algse saatja domeeni poolt volitamata e-posti servereid, mis toob kaasa SPF kontrolli ebaõnnestumise.

Lihtsaim lahendus on seadistada e-posti loend kirjutama saatja aadressi ümber loendi enese aadressiks.
Näiteks MailMan (>= versioon 2.1.16) puhul on see teostatav kasutades parameetrit "from_is_list" (https://www.gnu.org/software/mailman/mailman-admin.pdf, Section 2.1 The General Options Category, lk 5).

Alternatiivina võib e-posti loendi tarkvara omada loendi liikmete DMARC poliitikaga ümberkäimise võimekust. Sellisel juhul võib tarkvara näiteks loendisse kirjutaja domeeni kohta teostada DNS päringu ning sõltuvalt tuvastatud poliitikast teha otsuse, kas jätta algse saatja e-posti aadress muutmata kujule (DMARC puudub või p=none;) või kirjutada aadress ümber (DMARC rakendatud, p=quarantine; või p=reject;).
Näiteks MailMan (>= versioon 2.1.18) puhul on see teostatav kasutades parameetrit "dmarc_moderation_action" (https://www.gnu.org/software/mailman/mailman-admin.pdf, Section 2.7 The Privacy Options Category, lk 14).

Täiendav teave MailMan on leitav veebilehel https://wiki.list.org/DEV/DMARC

Rohkete MailMan postiloendite olemasolu korral võib ümberseadistamisteks pakkuda inspiratsiooni järgnev skript skript: https://mail.python.org/pipermail/mailman-users/2018-February/083058.html

Setting up email lists

In the case of e-mail lists, it is necessary to take into account the fact that with certain settings there is a significant risk that the lists cause SPF and DKIM checks to fail with their actions.

The failure is primarily due to two circumstances:

1. Mailing lists can modify the content of email messages, causing the DKIM signature to not be validated. For example, the software may add a prefix to the header of an e-mail or information about a mailing list in the footer of an e-mail.

2. Mailing lists may use email servers not authorized by the original sender's domain to send email, causing the SPF check to fail.

The simplest solution is to configure the mailing list to rewrite the sender's address as the list's own address. For example, with MailMan (>= version 2.1.16), this is possible using the "from_is_list" parameter (https://www.gnu.org/software/mailman/mailman-admin.pdf, Section 2.1 The General Options Category, page 5).

Alternatively, email list software may have the ability to override DMARC policies for list members. In this case, the software can, for example, perform a DNS query about the domain of the person writing to the list and, depending on the detected policy, make a decision whether to leave the original sender's e-mail address unchanged (no DMARC or p=none;) or rewrite the address (DMARC applied, p=quarantine; or p=reject;).

For example, with MailMan (>= version 2.1.18) this is done using the "dmarc_moderation_action" parameter (https://www.gnu.org/software/mailman/mailman-admin.pdf, Section 2.7 The Privacy Options Category, page 14) .

Additional information on MailMan can be found on the website https://wiki.list.org/DEV/DMARC

If you have a lot of MailMan mailing lists, the following script can provide inspiration for the conversions:

https://mail.python.org/pipermail/mailman-users/2018-February/083058.html

Non-delivery report (NDR) e-kirjade autentimine

Sageli ei kipu e-posti serverid non-delivery report e-kirjadele MAIL FROM: ehk RFC 5321 aadressi seadma, mistõttu tavapärane SPF ei toimi tavapäraselt ning vaikimisi näiteks Postfix ja OpenDKIM kombinatsiooni puhul antud kirju ei allkirjastata.

Siiski on võimalik siiski kasutada SPF-i NDR e-kirjade autentimiseks, kui lisada SPF TXT kandesse e-posti serveri HELO/EHLO identiteet.
https://tools.ietf.org/html/rfc7208#section-2.4

Samuti on võimalik seadistada OpenDKIM allkirjastama NDR e-kirju, vastavad juhised on kirjeldatud järgnevatel viidetel:
https://wiki.debian.org/opendkim#Postfix_integration
http://www.postfix.org/MILTER_README.html#non-smtp-milters

Authentication of Non-delivery report (NDR) emails

Often, e-mail servers do not tend to set the MAIL FROM: or RFC 5321 address for non-delivery report e-mails, which is why conventional SPF does not work normally, and by default, for example, in the case of a combination of Postfix and OpenDKIM, the given e-mails are not signed.

However, it is still possible to use SPF to authenticate NDR emails by adding the email server's HELO/EHLO identity to the SPF TXT entry.
https://tools.ietf.org/html/rfc7208#section-2.4

It is also possible to configure OpenDKIM to sign NDR emails, the corresponding instructions are described in the following references:
https://wiki.debian.org/opendkim#Postfix_integration

http://www.postfix.org/MILTER_README.html#non-smtp-milters