WebbMotell - Det prisvärda alternativet för era hemsidor

Grymt Koncept! Vårt Premium webbhotellkonto är något utöver det vanliga. Ni får en helt egen server för er själv. Ni konkurrerar inte med någon annan om CPU och minne, allt är ert! Och detta till ett pris som motsvarar ett vanligt webbhotell. Vi erbjuder också två instegskonton, Start och Standard. Dessa är vanliga webbhotellkonton där ni delar resurser som CPU och minne/RAM med andra kunder.

Detta är vår supportportal för denna produktlinje. Webbmotell kommer som standard utan support, förutom då felanmälan. Många kunder klarar sig helt utan support och då vill vi ge dem möjlighet att inte heller behöva betala för andras support, bara för deras egen support.

Denna portal är tänkt att vara ett komplement till support som en självhjälp, men också med möjligheten att ställa frågor. Frågor ni ställer besvaras av andra hjälpfulla kunder eller i mån av tid av vårt supportteam. Här hjälper vi varandra. För att ställa frågor behöver ni skapa ett konto och logga in.

Vissa webbhotellplaner tillåter att man skapar egna cron-job. Det finns två varianter av cron jobb:

1. Med URL, dvs man anropar ett program med https://…
2. Med ett program, t.ex ett php program.

Enklast är att använda URL. Man kan då skapa ett skript på ens hemsida som körs regelbundet, t.ex. https://mindoman/cron.php. Kryssar ni för “Log output” kommer resultatet att skrivas i filen /private/cron_wget.log.

Vill ni inte köra skriptet via er hemsida, då kan köra det på “kommandoraden”. Vi rekommenderar att ni lägger era skript i /private katalogen. Motsvarande kommando skulle då se ut så här:

/usr/bin/php /private/cron.php

Kryssar ni för “Log output” kommer resultatet att skrivas i filen /private/cron.log.

Det behöver naturligtvis inte vara php skript, det kan också vara shell skript, t.ex.

/bin/sh /private/cron.sh

De kataloger ni bör komma ihåg är

/private
/web

Dessa kommer ni åt med ftp och kan då ladda upp filer där. Allt ni lägger i /web är synlig för alla genom er hemsida, man kommer åt det med http, medan det som ni lägger i /private är helt skyddat från åtk

När ni skapar en webbplats i ISPconfig då skapas bara denna på web-servern. För att webbplatsen också skall fungera på internet måste den också skapas i DNS. Det sker inte automatiskt, det är något ni måste göra som utöver skapandet av webbplatsen. Detta gäller också e-post. E-post börjar inte fungera per automatik för att ni skapar en webbplats.

När ni skapar webbplatser/aliasdomäner/underdomäner med den enkla kontrollpanelen i er kundportal, då skapas allting ni behöver för er hemsida automatiskt. Ni kan välja om ni vill skapa en e-postdomän eller inte. Alla DNS records som behövs skapas automatiskt med den enkla kontrollpanelen.

Om er webbhotellplan tillåter er att sätta upp flera webbplatser kan ni göra det. I regel tillåter emellertid våra webbhotellplaner endast en webbplats och till denna kan ni skapa under-/sub-domäner och/eller aliasdomäner. Det som skiljer en webbplatsdomän mot en aliasdomän är att webbplatsdomänen kan placeras på olika servrar medan aliasdomänen måste placeras på den servern som den överordnade webbplatsdomänen finns.

De flesta av våra webbhotellplaner inkluderar bara en webbplatsdomän och kan då också inkludera flera aliasdomäner (multidomän).

VARNING: Tag aldrig bort en webbplats om ni verkligen inte är helt säker på vad det är ni gör. Tar ni bort en webbplatsdomän då tas också alla underordnade aliasdomäner och underdomäner bort. Finns bara en webbplats i ISPConfig och ni tar bort den, då försvinner alla era hemsidor.

Vi rekommendera följande gång när ni skapar webbplatser.

Webbplats

1. Skapa DNS zon för domännamnet

Det första ni skall göra är att skapa domänen i DNS. Det är viktigt att detta görs först eftersom detta behövs för att sätta upp SSL på er webbplats.
Ni kommer att få flera förslag på IP adresser, ange den IP adress som ni har fått angiven i det kontobrev ni fått. När ni skapat denna, vänta 5 minuter innan ni fortsätter.

2. Skapa webbplats

Nästa steg är att skapa webbplatsen.

Det är många parametrar som skall anges när denna skapas.


Server och IP adress är oftast redan givna och går inte att ändra på. Samma IP adress som står här skall anges i DNS enligt punkt 1 ovan.

En viktig parameter är sedan "Kvot för hårddisk". Där skall ni ange hur mycket utrymme er webbplats får ta och detta utrymme måste rymmas inom er plan. Har ni totalt 5000 MB till ert förfogande i er webbhotellplan, då kan ni ange det här, men då har ni inte utrymme för att skapa ytterligare webbplatser (om er plan tillåter er det).

Övriga inställningar kan ni låta stå som anges av bilden. Dessa kan alltid ändras i efterhand om man vill det.

Skapa maildomän

För att domänen skall fungera med e-post behöver en maildomän skapas för det aktuella domännamnet. Gå till E-Post/Domän/Lägg till ny domän.

Fyll i formuläret enligt bilden. Vill ni också sätta upp DKIM för maildomänen, se då en annan artikel för det.

Nästa steg är att skapa ett MX record i DNS. Öppna zonen för den aktuella domänen och klicka på gröna MX knappen

och skapa ett MX record.

De avslutande punkterna är mycket viktiga.

Med dessa inställningar kommer ni igång med e-post för domännamnet, ni kan skapa e-postkonton, e-postalises och så vidare.

Aliasdomäner

Aliasdomän för webbplats är en parkerad webbplats, den visar samma webbplats som någon annan av era webbplatser, det man brukar kalla parkerad. Det går också att vidarebefodra denna till en helt annan domän.

Aliasdomän (vhost) har en helt egen oberoende hemsida.

1. Skapa DNS zon för domännamnet

Samma som för Webbplats ovan.

2. Skapa aliasdomän

Vad gäller aliasdomäner med vhost är det många parametrar som skall anges. Om det gäller en parkerad domän då är det betydligt färre som behöver anges. Följande bild visar hur man skapar en aliasdomän med egen hemsida.


Det viktiga här är Webbmapp. Denna anger vart filerna för hemsidan skall lagras. För de flesta spelar detta ingen roll, men den kan behövas anges om man installerar vissa applikationer som då behöver veta detta. Denna folder måste vara unik, den får inte existera sedan tidigare. Vi rekommenderar att ni anger samma som domännamnet här.

Trafik kan ni i regel ange som -1.

Övriga inställningar kan ni låta stå som anges av bilden. Dessa kan alltid ändras i efterhand om man vill det.

3. Skapa maildomän

Se ovan.

Underdomän

Underdomän för webbplats är an parkerad webbplats, den visar samma webbplats som någon annan av era webbplatser. Den kan också vidarebefodras till någon helt annan hemsida. 

Underdomän (vhost) har en helt egen hemsida.

1. Skapa DNS zon för domännamnet

Här skiljer det sig ordentligt från webbplatser och aliasdomäner. Ni skall här inte skapa en ny DNS zon, ni skall istället skapa records i en befintlig DNS zon.

Antag att er huvuddomän är kallekula.se och ni vill skapa underdomänen hemma.kallekula.se.

Steg 1 är att öppna DNS zonen för kallekula.se och lägga till ett för underdomänen hemma.kallekula.se. Enklast är att lägga till ett CNAME, men skall man använda underdomänen för e-post, då behöver man ange ett A record. Detta exempel kommer att visa hur man lägger till ett CNAME.

Klicka på DNS i övre menyn, sedan klickar ni på den befintliga zonen kallekula.se. Klicka sedan på den gröna knappen CNAME 

Fyll i enligt bilden och klicka på spara. Det är mycket viktigt att huvuddomänen anges med en avslutande punkt.

2. Skapa underdomän

Samma som för Aliasdomän, men med ett undantag, Automatisk underdomän skall anges som Ingen

3. Skapa maildomän

Det går att skapa maildomän för en underdomän, men instruktionerna som angivits här stödjer inte det. Skall ni använda underdomänen för e-post behöver ni sätta upp A record istället för CNAME och ni behöver också ange ett MX record och också helst ett SPF record i er DNS-zon.

I ett nötskal

Det finns tre olika typer av domäner i ISPConfig kontrollpanel

1. Huvuddomän: Den högsta nivån för webbhotellkontot, t.ex. domänen exempel.se. Till denna kan sedan subdomäner och tilläggsdomäner kopplas.
2. Subdomän: Underdomän till huvuddomänen, t.ex. hemma.exempel.se.
3. Tilläggsdomän: Utöver huvudomänen kan man sätta upp tilläggsdomäner, typ exempel.com, example.com.

De två sistnämnda kan implementeras på 3 olika sätt:

1. Parkering: Det innebär att domänen i fråga visar exakt den webbplats som den parkeras på. T.ex. kan man parkera exempel.com på exempel.se, varvid https://exempel.se https://exempel.com kommer att visa exakt samma webbplats.
2. Omdirigering: Här skickas besökaren vidare till till en annan webbplats. T.ex kan https://foo.exempel.se skickas vidare till https://foo.se. 
3. Vhost: Här skapar man en helt egen webbplats för den aktuella domänen. Det kan vara typ foo.exempel.se, exempelnorge.se, exempel2.se och så vidare.

Tilläggsdomäner och subdomäner är kopplade till en huvuddomän och ligger alla under samma username. Deras disk-kvot ingår i den som angivits för huvuddomänen.

Alla typer kan dock ha olika versioner av php.

Parkerade domäner

Dessa har ingen egen webbplats utan de visar samma webbplats som någon annan webbplats.

Parkerade domäner kan man använda på två olika sätt:

1. Som parkerad domän på en annan domän
2. Som vidarebefodring till annan webbplats

En parkerad domän visar exakt samma webbplats som en annan webbplats, utan någon vidarebefodring. Antag att ni er ordinarie webbplats ligger på foo.se och att ni också vill att er domän foo.com skall visa exakt samma webbplats. Då parkerar ni domänen foo.com på domänen foo.se. Exakt samma webbplats kommer då att visas för https://foo.com som för https://foo.se. 

Omdirigerade domäner

Antag nu att ni har domänen foo.com och ni vill att den skall visa en helt annan webbplats, som ni inte har på ert webbhotellkonto, eller som ni kanske inte ens äger. Anta att denna webbplats är https://bar.se. Ni kan då sätta upp vidarebefodring till denna adress. Dvs går någon till https://foo.com då vidarbefodras man automatiskt till https://bar.se i sin webbläsare.

Vidarebefodring har ett antal nackdelar. Framförallt gillar inte sökmotorer det. Det går aldrig att få en bra ranking hos sökmotorer som använder vidarbefodring. Parkerade domäner emellertid, de fungerar alldeles utmärkt med sökmotorer. Det är till och med så att parkerade domäner är mycket vanligt för SEO.

En annan nackdel med vidarebefodring är att det bara går att vidarebefodra huvuddomänen, dvs https://foo.com. Skulle någan ange https://foo.com/contact/ så fungerar det inte med vidarebefodring, men med parkering fungerar det utmärkt.

Samma nomenklatur och funktioner gäller underdomäner.

Vhost domäner

Dessa är helt fristående webbplatser, med egna filer.

Det är ftp-konton som används för Installatron. Ta inte bort dessa.

Ja, under Spamfilter finns alternativ för svart- resp. vitlistning av inkommande e-post. Ni kan sätta upp filter som gäller för alla era e-postkonton eller för enskilda.

Notera att ni måsta ha aktiverat "Spamfilter" för respektive e-post-domän för att detta skall fungera. Som standard är det ofta inte satt. Vi rekommenderar att ni sätter det till "Normal".

Skapa Spamfilter:

• Användare: Här kan du välja mottagarens e-postkonto eller till och med hela mottagardomänen för vilken den här vitlisteposten kommer att vara giltig - den här vitlisteposten kommer inte att användas för andra mottagares e-postkonton eller domäner.

• E-post: Ange den e-postadress vars e-postmeddelanden ska vit/svartlistas. Du kan till och med vit/svartlista en hel domän genom att lämna den lokala delen av e-postadressen - det vill säga om du vill lista e-postmeddelanden från domänen spammer.com, skriv @spammer.com i det här fältet.

• Prioritet: Om flera poster för vitlista/svartlista tillämpas anger det här fältet vilken regel som ska användas först (10 = högsta prioritet, 1 = lägsta prioritet). Om du till exempel svartlistar @example.com med prioriteten 5 kan du vitlista user@example.com med prioriteten 6 så att user@example.com e-post kommer igenom medan @example.com är svartlistad.

• Aktiv: Detta definierar om den här listningen är aktiv eller inte.

Ni kan blocka utgående och/eller inkommande e-post till/från era egna e-postadresser.

Ja, i Installatron går det att ange vilka mail man vill få från Installatron.

Logga först in till Installatron från den enkla kontrollpanelen.

Gå till "Mina Applikationer" och klicka på det lilla verktyget för den aktuella applikationen.

Gå sedan sedan till "E-postmeddelanden" och där kan ni ange vilka meddelanden ni vill få från Installatron.

DKIM aktiveras via kontrollpanelen ISPConfig. Har ni inte tillgång till denna behöver ni kontakta Kundtjänst.

Stegen är

1. Logga in till ISPConfig
2. Gå till "E-Post/E-postkonton/Domän" och klicka på er domän
3. Klicka på "DomainKeys Identified Mail"
4. Kryssa för "enable DKIM"
5. Ange "mail1" som DKIM-Selector
6. Klicka på "Generate DKIM Private-key"
7. Klicka på Spara

DKIM aktiveras då för er domän och er DNS zon uppdateras med korrekta DNS records. 

Er Maildomän

I ISPconfig, gå till maildomänen för vilken ni vill aktivera DKIM:

Notera namnet för er mailserver. Ni skall använda er av detta namn när ni senare anger "DKIM-selector". Ni kan iofs använda godtycklig "DKIM-selector" så länge krockar inte uppstår. Vi rekommenderar att ni använder första delen i mailservernamnet, dvs "mail1" i detta fall. "DKIM-selector" får under inga omständigheter innehålla en punkt (".").

Konfigurera DKIM

Klicka som nästa steg på er maildomän och följande kommer upp:

Klicka på "DomainKeys Identified Mail" för att öppna inställningarna för DKIM.

Följ sedan bara instruktionerna bara instruktionerna i bilden ovan. Notera att ni i detta fall anger "mail1", som är den första delen i mailservernamnet, som DKIM-Selector.

Vi stödjer DNSSEC med vår DNS-tjänst som ingår mer WebbMotell. Vår DNS tjänst skapar nycklar som ni sedan ger till er registrar för ert domännamn. För att nycklarna skall propagera ut på internet ordentligt, avvakta en dag innan ni kontaktar er registrar.

Ni kan läsa mer om DNSSEC här.

Logga in till ISPconfig och gå till DNS administration för er domän:

Ni klickar på "Zone settings" för inställningarna för er DNS-zon. Längs ned på sidan visas då inställningarna för DNSSEC.

Eftersom SHA-1 inte längre stöds av de flesta registries skall ni bara anmäla det nedre recordet, det inramade "Digest Type"=2, record.

Efter att ni klickat på "Spara" skapas records enligt bilden ovan. Det kan ta upp till 10 minuter innan records skapas och visas enligt bilden ovan.

OBS: Notera att det ibland finns ett mellanrum i "digest", i detta fall mellan "A6B 9777". Detta mellanrum måste ni ta bort när ni registrera detta record till registriet. Kontrollera noga att alla eventuell mellanrum i ert "digest" tas bort.

När ni skall lägga till detta record hos er domännamnleverantör "kan" det se ut så här:

Ni kan se i detta exempel hur det record ni skapat i ISPconfig mappar mot det som ni skall ange till er domännamnsleverantör/registry.

Ni kan kontrollera era DNSSEC inställningar på https://dnsviz.net.

Problemet är sannolikt att ni inte har fått något SSL certifikat till er hemsida. Normalt sett skapas det när ert webbhotellkonto skapas, men om ert domännamn inte redan pekar på sätt namnservrar när ert webbhotellkonto skapas, då finns en risk för att något SSL certifikat inte skapas.

Vi använder oss av SSL certifikat från Let's Encrypt. Ni kan enkelt skapa ett certifikat för er hemsida via ISPConfig kontrollpanel. En förutsättning är dock att ert domännamn pekar på rätt namnservrar.

Innan ni laddar upp något innehåll till er webbsida bör ni först se till att SSL certifikatet är installerat. Kontrollera att typ

http://mindoman.se

fungerar och visar den standardsida som visas när konton installeras, observera "http:" här. När denna visas korrekt i er webbläsare, då kan ni fortsätta med att installera SSL certifikat för er hemsida.

Logga in till ISPConfig. Gå till "Webbplatser" och klicka på er domän:

Kryssa för "SSL" och "Let's Encrypt SSL" och klicka sedan på Spara. Efter ca 10 minuter kommer er hemsida att ha ett giltligt certifikat.

Är dessa redan ikryssade, kryssa då bort dem och klicka på spara. Vänta några minuter och kryssa i dem igen och klicka på Spara.

Redis cache ingår i våra Premium planer.

Aktivera Redis Cache för WordPress

Innan Redis installeras,  installera och aktivera Query Monitor-plugin.

Genom att lägga till Query Monitor kan databasfrågor, PHP etc felsökas. Det hjälper också till att visa totala antalet databasfrågor grupperade efter akutell plugin som gjort förfrågan.

Inloggad som admin, gå till förstasidan på er WordPress hemsida, alltså inte admin sidan utan den vanliga hemsidan. Högst upp på sidan visas nedanstående rad (om ni är inloggad som admin). Klicka på Query Monitor.

Detta startar en Query Monitor panelen.

Just detta exempel är en ganska enkel sida, och här kan man se totalt 23 databasanrop som tar 0,0013 millisekunder att köra.

Lägg nu till ett Redis Object Cache plugin. Sök på Redis och välj det här specifika plugin-programmet Redis Object Cache.

Installera och aktivera det här plugin-programmet. Gå sedan över till Redis-inställningar (på instrumentpanelsmenyn). Nu bör du aktivera Objektcache.

Detta ställer in Redis med standardinställningarna.

Kontrollera om Redis fungerar

Om du går till din webbplats och öppnar en blogg, låt oss säga standard hello world WordPress-bloggen, kommer resultaten av denna begäran att sparas på Redis.

Uppdatera nu startsidan som du laddade Query Monitor.

Och du kan se att sidan nu laddas med endast 3 databasfrågor som tar 0,0003 millisekunder. Vår totala databasfrågatid är nu betydligt lättare än där den var. Alla dessa frågor sparas nu i minnet, vilket minskar de samtal du måste göra direkt till MySQL-databasen. Detta gör backend snabbare för att returnera förfrågningar.

Slutsats

Om du har en omfattande webbplats som woo-commerce kommer detta att spela en stor roll för att göra din webbplats snabbare. Detta cachelagrar också databasintensiva uppgifter som gör webbplatsen mer motståndskraftig.

Även när du har många användare som gör beställningar drar de information från cachen. Du kommer att använda färre resurser och få en snabbare backend-upplevelse.

Redis cachelagrar bara databasfrågor och objekt. Detta innebär att du fortfarande kan fortsätta använda andra cache-plugins som Cache Enabler och WP Cloudflare för att cachelagra dina sidor och göra din webbplats ännu snabbare.

För att minimera risken för att den e-post ni skickar inte kommer fram för att kategoriseras som spam av mottagaren behöver ni göra följande:

1. Sätta SPF för domänen
2. Aktivera DKIM för domänen
3. Sätta DMARC för domänen
4. Lägg till domänen till Google "Postmaster Tools"

SPF är redan satt som standard för e-postdomäner som skapas med den enkla kontrollpanelen. För e-postdomäner som skapas i ISPConfig måste SPF sättas manuellt i domänens DNS zon. Följande SPF skall sättas för apex/root domänen:

v=spf1 mx a +include:_spf.ewn.se ~all

Det går också att sätta -all, men detta kan skapa problem för er när ni skickar e-post till någon som vidarebefodrar sin e-post till någon annan e-postadress. Vår rekommendation är att använda ~all.

För att sätta DKIM, se artikeln Hur aktiverar jag DKIM?

För att sätta DMARC rekommenderar vi Postmark som erbjuder en gratis-tjänst för detta.

Dessa steg skall man alltid göra. Man kan också gå med i Googles "Postmaster Tools" program för att förbättra sina möjligheter att skicka e-post till Gmail. Lite instruktioner går att hitta i deras forum.

Denna Google artikel ger också bra råd för hur man undviker att bli blockad av Gmail.

I ISPConfig finns ett alternativ för att ladda ned säkerhetskopior till sin egna dator. Detta är också något vi rekommenderar att det görs regelbundet.

Gå till Webbplatser/Webbplats och klicka på aktuell webbplats. Klicka sedan på fliken Backup.

Efter en stund har säkerhetskopiorna skapats i katalogen /backup. Ni kan då ladda ned dessa till er lokala dator med ftp.

Antagligen använder ni localhost för att ansluta till MySQL. 

Av säkerhetsskäl lever alla websiter i ett eget fängelse (jail), de kan inte se något från andra websiter som inte ägs av samma konto. Det går inte att se filer från andra websiter, inte eller går det att se systemfiler. Till systemfiler hör den socket som man kopplar sig till MySQL om man använder localhost. 

Eftersom denna socket inte är synlig behöver man koppla sig till MySQL på ett annat sätt, och det är över nätet, fast lokalt på servern.

Istället för localhost skall därför 127.0.0.1 användas som databasserver.

Är ni Admin och ni har skapat e-postkonton åt andra personer, då kan dessa personer själva ändra på inställningar för sitt e-postkonto utan att behöva fråga er som admin.

Som ägare till ett e-postkonto kan de själv göra följande:

• Ändra lösenord för e-postkontot
• Aktivera auto-svar
• Skicka kopia på alla inkommande mail
• Sätta skräppostfilter
• Sätta filter för inkommande e-post.

Att skicka kopia på alla inkommande mail skall endast göras till samma domän. Till exempel att brev till kalle@doman.se kan skickas till anna@doman.se. Sätter man upp vidarebefodring till andra domäner kommer dessa att tas bort av systemet.

Först loggar ni som e-postanvändare in till kontrollpanelen ISPConfig, https://ic.etableraweb.com:8080. Ni anger er e-postadress som användarnamn och som lösenord anger ni e-postadressens lösenord.

När ni väl loggat in möts ni av denna bild:

Inledning

Detta kan hända om ni inte har en fungerande SSL, dvs fungerande https, för er webbplats. Då kommer https://minwebplats.se att visa någon annans webbplats. http://minwebbplats.se kommer dock att visa er webbplats, OM INTE ni har satt automatiskt vidarebefodring till https.

Har ni bara den Enkla kontrollpanelen, då behöver ni kontakta Kundtjänst.

Steg 1 - Tag bort vidarebefodring

Tag bort automatiskt vidarebefodring gör https:

Klicka på "Spara" och vänta några minuter och se om er hemsida nu fungerar med http, dvs http://minwebplats.se. Gör den inte det, då behöver ni kontakta Kundtjänst.

Steg 2 - Tag bort SSL

Nästa steg är att ta bort SSL från webbplatsen, om den är satt. 

Se till att SSL och Let's Encrypt är avmarkerade och klicka sedan på "Spara". Vänta några minuter och kontrollera om er webbplats fungerar med http. Om den inte gör det, kontakta Kundtjänst.

Steg 3- Aktivera SSL med Let's Encrypt

SIsta steget är nu att aktivera SSL med Let's Encrypt. Kryssa nu för rutorna SSL och Let's Encrypt:

och klicka på "Spara", vänta några minuter, typ 5, och prova nu er webbplats med https. Om det inte fungerar nu, kontakta Kundtjänst.

1. Skapa record i DNS, antingen som A eller AAAA (typ hemma.foo.com). Ange godtycklige IP Adress
   
2. Skapa en hemlig DynDNS token för namnet hemma.foo.com. Ni behöver inte ange Begränsningar, det är mest till för säkerhet. Det anger ni bara om ni vill använda olika URLer/credentials för olika subdomäner. I regel kan ni lämna den tom.
   
3. Klicka på länk knappen så visas de URL'er ni skall använda för att uppdatera er IP Adress

Den URL ni skall använda ser ut enligt följande:

https://ic.etableraweb.com:8080/ddns/update.php?zone=ikasp.com.&type=A&record=hostname&data=YOUR_IP_ADDRESS&token=*****

Variabler:

zone: Er huvuddomän skall anges här.
type: Typ av record. Kan vara A eller AAAA.
record: Den subdomän av huvuddomänen som skall sättas. I exemplet ovan kontor.
data: Den IP adress som ni vill sätta hostnamnet till. Ni kan utesluta denna, så kommer den IP adress från den datorn som anropet kommer ifrån att användas.
token: unik och hemlig sträng som genereras av ISPConfig

Enklast att använda denna funktion är att ange typ följande adress i er webbläsare:

https://ic.etableraweb.com:8080/ddns/update.php?zone=ikasp.com.&type=A&record=kontor&token=*****

IP adressen för kontor.ikasp.com kommer i detta exempel då att sättas till samma IP-adress som anropet kommer från.

Det går naturligtvis att automatisera detta med t.ex. cron:

curl -q 'https://ic.etableraweb.com:8080/ddns/update.php?zone=ikasp.com.&type=A&record=kontor&token=*****'

Anropa inte uppdateringar för ofta. I regel räcker det att göra det någon gång per dag. Oftare än per timme är inte meningsfullt då TTL för DNS records är satta till minst 1 timme.

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

php miljön ser lika ut i er cron och inloggning med ssh som er webbsida.

Vi erbjuder php 5.6, 7.4 och 8.x.

För installerade moduler och konfig för senaste php-version, se

https://phpinfo.webbmotell.se/

Som standard använder varje app som installeras med Installatron sin egen databas. Installerar ni många appar då krävs också många databaser. Ni har i regel ett begänsat antal databaser till ert förfogande.

Har ni inte tillgång till ISPConfig kontrollpanelen, då behöver ni uppgradera ert konto så att ni får det.

Ni kan annars göra något av följande:

1. Kontrollera om alla era databaser verkligen används till något. Ta bort dem som ni inte använder. Var mycket noga här med att verkligen inte ta bort sådana som ni använder.
2. Uppgradera er webbhotellplan med fler databaser.
3. Använd en databas för flera appar. Detta är möjligt i Installatron.

Använd en databas för flera appar

När ni installerar en app med Installatron, välj då att den skall använda en befintlig databas. Ni behöver då veta vilket databasnamn, databas-användarnamn och lösenordet till denna. I regel hittar ni detta i någon redan installerad app.

Till exempel om ni har WordPress installerad och vill använda den databasen, då hittar ni databasinformation i filen wp-config.php:

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'X68i22989999' );

/** Database username */
define( 'DB_USER', 'X68i2298' );

/** Database password */
define( 'DB_PASSWORD', 'a1609Q79d816!ba18ASb64a_64b613f3Bb' );

/** Database hostname */
define( 'DB_HOST', '127.0.0.1' );

När ni installerar en ny app i Installatron, gå då till section Utökad längst ned på sidan.

Fyll då in databasuppgifterna manuellt. Det är Tabellprefix som kommer att skilja de olika apparna från varandra i databasen. Ändra inte denna.

För att använda Microsoft 365 e-post måste ett antal DNS records sättas. Dessa records anger Microsoft för er, de är unika för varje användare.

Dessa records måste ni sätta manuellt i er DNS. Enklast är att göra det i den Enkla Kontrollpanelen.

1. Tag bort alla "AUTOMAIL records" genom att klicka på den knappen.
2. Tag bort alla MX records.
3. Tag bort ert autodiscover record.
4. Tag bort ert SPF record.

Nu kan ni lägga in de records som Microsoft angivit. I den enkla kontrollpanelen brukar det se ut så här:

Notera de avslutande punkterna. Dessa är mycket viktiga.

Där ett TXT record som är unikt för er satts, ett MX record som pekar mot Microsofts e-postserver, ett CNAME record som pekar på Microsofts autodiscovertjänst och slutligen ett SPF record som är anpassat för Microsoft 365 e-post. Ni behöver dock lägga till include:_spf.ewn.se till denna om ni också skickar e-post via er hemsida. Vi rekommenderar också att ni använder ~a istället för -a.

Inledning

Inloggning med ssh måste ske med ett ssh nyckelpar. Det går inte att logga in med lösenord. Gången är

1. Skapa ett ssh nyckelpar på er lokala klient
2. Lägg in den publika nyckeln för er shell-användare i ISPConfig.
3. Ange nyckelparet i er ssh-klient när ni loggar in.

Skapa ssh nyckelpar

Ett nyckelpar som består av en privat och en publik nycket måste först skapas på er lokala klient. Denna skapas i regel med ssh-keygen. På MacOS och Linux finns i regel denna redan installerad och skapas enkelt via kommandoraden.

Googla/Duckducka/Binga efter "How to Generate SSH key on Windows/MacOS/Linux" för att hitta lämpliga artiklar.

En lämplig artikel för Windows är https://www.howtogeek.com/762863/how-to-generate-ssh-keys-in-windows-10-and-windows-11/ (Bild).

Lägg in den publika nyckeln för shell-användaren

Logga in till er ISPConfig kontrollpanel och gå till Shell-användare. Ni kan här också skapa nya shell-användare. Välj ut den shell-användare ni vill välja och klicka på denna.

Kopiera er PUBLIKA nyckel till "SSH-RSA Offentlig nyckel" fältet och klicka på Spara.

När ni har gjort det kan ni nu logga in med ssh, med exemplet ovan, ssh bnekvqtkssh@www1.ic.etableraweb.com.

Eftersom angripare kommer från mycket stora IP-adressområden är det inte alltid .htaccess är en god idé. .htaccess är också resurskrävande om den är stor. Att blockera ett hundratal explicita IP adresser, eller hela subnät är dock inga problem

//Blocka en IP
Deny from 192.168.0.3
//Blocka flera IP
Deny from 111.111.111.111 222.222.222.222 333.333.333.333
//Blocka subnät, i detta fall blockas 192.168.*.*
Deny from 192.168

Om det är enbart vissa IP adresser ni vill tillåta, då kan ni sätta Deny som standard och sedan sätt Allow för de IP adresser ni vill tillåta.

Order Deny,Allow
Deny from all
Allow from 192.168.2.3 192.168.2.3 192.168.10

Kontakta gärna Kundtjänst för information om tjänster som kan tillhandahållas. T.ex. blocka all besökare från ett eller flera länder, bara tillåta besökare från vissa länder och så vidare.

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Här är en bra artikeln, på engelska förvisso, som beskriver hur man skapar ett e-postkonto i ISPConfig. Den beskriver den fullständiga processen med att först skapa en maildomän för den aktuella domänen och sedan skapa e-postkontot. I regel är maildomänen redan skapad, men om det gäller tilläggsdomäner, då behöver man lägga till dem som maildomäner också.

How to Add an Email Account in ISPConfig 3.2

Vi rekommenderar att man använder SMTP för att skicka mail, och anledningen till det är att man då skickar e-post genom att autentisera sig och att då brevet tydligt kommer från en korrekt avsändare, och också i regel DKIM signerat.

Den inbyggda mail() funktionen i php använder programmet sendmail för att skicka e-post. Detta skickas då från www servern och som verklig avsändare kommer mottagaren att se själva servern, oavsett vad ni satt som From adress.

Även om det fungerar att skicka e-post, använder många e-postleverantörer, som Gmail, Outlook och andra, en mängd olika verktyg för att minska e-postspam. Dessa verktyg försöker upptäcka att ett e-postmeddelande verkligen kommer från den plats som det påstår sig vara plus flera ytterligare tester.

E-postmeddelanden som skickas via php's inbyggda mail() funktion misslyckas ofta i dessa test.

Detta innebär att när ett e-postmeddelande skickas ut från din webbplats (kontaktformulärplugin, adminavisering, etc), kanske det inte ens hamnar i mottagarens skräppostmapp, än mindre i inkorgen.

Det absolut bästa är att använda SMTP för att skicka mail med php. Ett enkelt sätt att göra det är att använda GitHub - PHPMailer/PHPMailer: The classic email sending library for PHP. Denna installerar ni enkelt på er hemsida.

För att skicka mail med SMTP med PHPMailer behöver ni först skapa ett e-postkonto på er mailserver, typ smtp@foo.com. Detta skapar ni med ett bra lösenord.

När ni sedan kodar i php använder ni följande för PHPMailer:

    $mail = new PHPMailer\PHPMailer();
    $mail->IsSMTP();
    $mail->Host = $SMTP['smtp_host_name'];
    $mail->Hostname = $SMTP['smtp_host_name'];
    $mail->Port = 587;
    $mail->SMTPSecure = 'tls';
    $mail->SMTPAuth = true;
    $mail->Username = $SMTP['smtp_user_name'];
    $mail->Password = $SMTP['smtp_user_pw'];
    $mail->Sender = $SMTP['smtp_user_name'];

Där $SMTP['smtp_user_name'] är smtp@foo.com i exemplet och $SMTP['smtp_user_pw'] dess lösenord. Där $SMTP['smtp_host_name'] är er e-postserver.

Nu är det möjligt att använda 2FA inloggning ISPConfig. Detta aktiveras genom Verktyg >> Användarinställningar, enligt bilden nedan.

För nuvarande finns bara alternativet 2-Faktor med e-post. Implementering med typ authenticator finns dessvärre inte med på ISPConfigs roadmap.

Ja, composer finns installerad som standard.

Skapa en shell användare och logga sedan in till denna med ssh.

Gå till er webbplats, typiskt 

cd /web

och ge ert composer kommando.

Om inte composer finns i /usr/local/bin, kontakta i så fall kundtjänst.

När ni har loggat in till en shell user med ssh, då finns det två sätt att se vilka versioner av php som finns tillgängliga.

Vilken version som är standard beror på vilket operativsystem som är installerat på servern. Ge kommadot "php --version" så ser ni vilket php version som är standard:

I detta fall är det version 7.3 som är standard.

För att se vilka ytterligare versionen av php som finns tillgängliga finns det (minst) två olika sätt:

Alternativ 1

Ange php på kommando raden och sedan TAB direkt efter:

I detta fall finns versionerna 7.0, 7.3, 7.4, 8.1 och 8.2 tillgängliga.

Alternativ 2

php binärerna ligger i regel i /usr/bin. Lista alla php binärer med kommandot ls -l /usr/bin/php*:

varvid ni kan identifiera vilka versioner som finns installerade.

För att använda t.ex. php version 8.2, använd då binären php8.2:

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Om du är iCloud-användare och du har funnit ett behov av att dela ut en kalender till en applikation via en URL, har du förmodligen stött på ett antal hinder. Med en kalender-URL kan du använda den för att prenumerera på en kalender i ett program utanför Apples universum (som med Google eller Thunderbird/Lightning). Att hitta webbadressen till en offentlig kalender är väldigt enkelt:

1. Logga in på iCloud.
2. Öppna Kalender-appen.
3. Klicka på den nedtonade "trådlös"-ikonen.
4. Klicka på Offentlig kalender.
5. Kopiera den givna webbadressen (den börjar med webcal).

Du kan sedan använda den webbadressen för att prenumerera på kalendern i fråga. 

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Dåligt.

En av de vanligaste frågorna användare av WordPress har är hur man åtgärdar problem med WordPress som inte skickar e-post.

Många användare på nybörjarnivå frågar varför deras plugin för kontaktformulär inte skickar e-post, eller varför de inte ser några WordPress-aviseringar.

I den här artikeln kommer vi att visa hur man åtgärdar problemet med att WordPress inte skickar e-post, så att din webbplats kan skicka e-postmeddelanden mer tillförlitligt och kringgå skräppostmappen. Ett annat alternativ är de lösningar som diskuteras i How to Change Sender Name in Outgoing WordPress Email och mer explicit i How to Fix WordPress Not Sending Email Issue. Dessa artiklar rekommenderar WP Mail SMTP plugin, medan vi  i denna artikel rekommderar Post SMTP.

WordPress har mycket dåligt stöd för att skicka e-post. WP använder den mailfunktion, mail(), som php tillhandahåller. Denna i sin tur använder sendmail() från operativsystemet. Detta ställer till problem när man skall skicka e-post, e-post man skickar uppfattas i regel som skräp av mottagarna, läs mer om detta i artikeln Hur kan jag använda mail med php?

Problemet med WordPress är denna inte erbjuder alternativ till detta. De flesta andra system som bygger på php gör det, men inte WP.

Lösningen är att installera en plugin till WordPress. Den plugin som vi rekommenderar är Post SMTP.:

Konfigurerar om funktionen wp_mail() för att använda Gmail/Mailgun/SendGrid/SMTP istället för standardmail() och skapar en alternativsida för att hantera inställningarna.

Med denna kan ni använda ert vanliga e-postkonto för att skicka e-post, eller skapa ett dedikerat e-postkonto för just WP.

Installera denna plugin och starta dess Setup Wizard. På första sidan anger ni en e-postadress som ni redan har skapat och som ni vet fungerar.

Nästa steg är att ange er mailserver. Nedan är ett exempel, ni får kontrollera med er leverantör vilken mailserver ni har.

När ni angivit mailserver och e-postadress kommer Post SMTP att försöka hitta er leverantör för e-post, och naturligtvis kommer denne att promota diverse kommersiella aktörer, POST SMTP är som sagt gratis. Efter en liten stund kommer denna bild fram.

Välj här ett av SMTP alternativen. I regel är alternativet på port 587 det säkraste och bästa, i andra hand port 465.

Nästa steg är att ange lösenordet den e-postadress ni angivit.

Lösenordet kommer att lagras någonstans i WordPress, hur vet man inte. Därför rekommenderar vi att ni skapar ett dedikerat e-postkonto för att skicka e-post, typ smtp@datest.se i detta fall. Använd denna endast för att skicka e-post, och för att bevaka e-poststudsar på mail ni har skickat.

I nästa steg kan ni sätta upp någon typ av monitorering av hur det går att skicka er e-post. Ni väljer här det som är lämpligt för er.

Nu när ni är klar med inställningarna återstår att testa att det fungerar. Klicka Send a Test Email och följ sedan instruktionerna.

Lyckas det skall ni få bilden ovan.

Ni kan sedan titta på era inställningar som denna wizzard nu skapat åt er. Ni kan också ändra dessa nu i efterhand, utan att behöva gå igenom wizzard igen.

Det skall se ut typ så här:

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

 

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

Att sätta upp alias eller vidarebefodring för befintligt e-postkonto fungerar inte.

Dock går det att sätta upp så att alla mail som kommer in också skickas vidare som CC till en annan e-postadress.

Detta görs enklast i webmail, https://webmail.webbmotell.se. Se denna bild för vägledning.

Har ni tillgång till kontrollpanelen ISPConfig kan ni också göra det där, med lite fler alternativ:

Skapa första ett mail som skall skickas. Klicka sedan på de tre cirklarna enligt bilden nedan.

Klicka sedan på Alternativ och bilagor enligt bilden nedan.

Klicka sedan på Bifoga fil för att ladda upp bilagan.

Dessa instruktioner gäller oavsett vilken enhet man använder, dator, mobiltelefon, padda, laptop osv.

Se denna film

I syfte att skydda användarnas e-post tillkännagav Gmail och Yahoo Mail en ny uppsättning krav för avsändare som gäller från februari 2024. Låt oss fördjupa oss i detaljerna och vad man behöver göra för att uppfylla dessa krav.

Vilka är de nya kraven för e-postavsändare?

De nya kraven inkluderar långvariga bästa praxis som alla e-postavsändare bör följa för att uppnå god leveransbarhet med postlådeleverantörer. Vad som är nytt är att Gmail, Yahoo Mail och andra postlådeleverantörer kommer att kräva anpassning till dessa bästa praxis för dem som skickar massmeddelanden över 5 000 per dag eller om ett stort antal mottagare anger att e-posten är skräppost.

Kraven kan destilleras in i tre kategorier: 1) striktare efterlevnad av domänautentisering, 2) ger mottagarna ett enkelt sätt att avbryta prenumerationen på massutskick och 3) övervakar antalet skräppostklagomål och håller dem under en tröskel på 0,3 %.

1. Domänautentisering

E-posteleverantörer kommer att kräva domänjusterad autentisering med DKIM och SPF, och de kommer att tillämpa DMARC-policyer för domänen som används i meddelandehuvudet From. De flesta e-postleverantörer gör inte det idag, möjligen använder man resultater från DMARC till att öka sannolikheten att brevet är skräp.

Till exempel kommer gmail.com att publicera en DMARC-policy som anger karantän, vilket innebär att obehöriga meddelanden som påstår sig vara från Gmail skall skickas till mottagarens skräppostmapp.

Har man då t.ex. en hemsida där man använder en gmail-epostadress för att skicka meddelanden till sina kunder, och man skickar brevet från den server som hemsidan ligger på, då kommer inte  DMARC att vara uppfyllt och mottagarens e-postsystem skall då lägga brevet i skräpkorgen. Skickar man till en gmail eller yahoo adress, då kommer definitivt brevet hamna i mottagarens skräpkorg.

Läs Artikeln: E-postautentisering och få ut värdet av en DMARC-policy för att få en djupare förståelse av SPF- och DKIM-domänanpassning och maximera värdet av din domäns DMARC-policy.

Det man behöver göra är att se till att ens domännamn lever upp till DMARC. För att ett domännamn skall leva upp till DMARC, då behöver SPF och DKIM sättas och e-post endast skickas från servrar där dessa är uppfyllda.

Vill man vara säker på att sina meddelanden verkligen skall komma fram till gmail och yahoo adresser, och sannolikt många andra, då skall man sätta DMARC, oavsett om man skickar över eller under 5000 meddelanden per dag.

2. Skapa en enkel avregistrering för e-postmottagare

Krav nummer 2 gäller massutskick av e-post, typ nyhetsbrev.

Bulksändare förväntas inkludera en mekanism för att avsluta prenumerationen genom att lägga till en länk i meddelandet som är lätt att hitt. Reglerna för postlådeleverantörer från februari 2024 kommer att kräva att avsändare dessutom lägger till rubriker för att avbryta prenumerationen med ett klick enligt definitionen i RFC 2369 och RFC 8058. Dessa rubriker gör det lättare för mottagare att avbryta prenumerationen, vilket minskar andelen  mottagare som kommer att klaga genom att markera meddelanden som skräppost .

Det finns många faktorer som kan leda till att dina meddelanden klassificeras som bulk av en e-postleverantörer. Volymer över 5000 per dag är en faktor, men den primära faktorn som postleverantörer använder är om mottagaren verkligen vill ta emot breven.

Så här lever du upp till kravet på enkel avregistrering

Följande steg beskriver hur man kan leva upp till kravet på enkel avregistrering:

Lägg till rubriker för att avsluta prenumerationen med ett klick till meddelandena du skickar: Skickar man massmeddelanden eller potentiellt oönskade meddelanden måste  man implementera en ett enkelt sätt för mottagare att avsluta prenumerationen.

E-postleverantörer kräver, eller kommer att kräva, att stora utskick ger mottagare möjlighet att avbryta prenumeration på massmejl med bara ett klick på en länk i meddelandet. Det är acceptabelt att avregistreringslänken i meddelandet dirigerar mottagaren till en webbsida för mottagaren att bekräfta sina inställningar och då avsluta/ändra prenumerationen.

För att uppnå detta, inkludera båda dessa rader i e-posthuvudet i det utgående meddelandet:

• List-Unsubscribe-Post: List-Unsubscribe=One-Click
• List-Unsubscribe: <https://example.com/ avregistrera/exempel>

Du behöver då implementera en av-prenumerationsfunktion på https://example.com/ avregistrera/exempel.

Gmails FAQ och Yahoos FAQ förtydligar båda att kravet på att avbryta prenumerationen med ett klick inte kommer att tillämpas förrän i juni 2024 så länge som masssändaren har en funktionell avregistreringslänk som är tydligt synlig i sidfoten i varje meddelande.

Besvara begäranden om att avsluta prenumerationen inom 2 dagar: Kontrollera att din avregistreringsprocess omedelbart tar bort mottagaren från att ta emot liknande framtida meddelanden. E-posteverantörer kräver att massavsändare ger mottagarna möjlighet att avsluta prenumerationen på e-post med ett klick, och att avsändarna behandlar begäranden om avregistrering inom två dagar.

Granska dina e-postlistor: Säkerställ en ansvarsfull e-postpraxis genom att avstå från att köpa e-postlistor, skydda opt-in-formulär från botmissbruk, verifiera mottagarnas preferenser genom bekräftelsemeddelanden och avstå från att automatiskt registrera mottagare i kategorier som inte efterfrågades.

3. Övervaka skräppostfrekvensen

E-postleverantörer kommer att kräva att alla avsändare håller andelen spamklagomål under 0,3 % för att undvika att deras e-post behandlas som skräppost av brevlådeleverantören. 

Registrera dig med Google Postmaster Tools: Man bör registrera sig för Google Postmaster Tools för att övervaka antalet skräppostklagomål för Gmail-mottagare.

Gmail rekommenderar att andelen skräppostklagomål håller sig under 0,1 %. Om du skickar till en blandning av Gmail-mottagare och mottagare hos andra brevlådeleverantörer, är andelen skräppostklagomål som rapporteras av Gmails Postmaster Tools en bra indikator på antalet skräppostklagomål hos brevlådeleverantörer som inte låter dig se statistik.

Slutsats

Dessa ändringar är planerade till februari 2024, men tänk på att den exakta tidpunkten och de metoder som används av varje postlådeleverantör kan variera. Om du upplever leveransproblem med någon postlådeleverantör före februari, är det i ditt bästa intresse att följa dessa nödvändiga bästa praxis som ett första steg.

Vi hoppas att den här artikeln klargör eventuella områden av förvirring om denna förändring och ger dig den information du behöver för att vara förberedd inför februari 2024. 

Användbara länkar:

• Gmail-meddelande: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
• Yahoo Announcement: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam

Källa: https://aws.amazon.com/blogs/messaging-and-targeting/an-overview-of-bulk-sender-changes-at-yahoo-gmail/

Inledning

För företag av alla storlekar är e-post en viktig del av infrastrukturen som stöder stora mängder kommunikation. För att förbättra säkerheten och pålitligheten för e-postkommunikation vänder sig många organisationer till e-postleverantörer (ESP) som webbmotell.se. Dessa ESP:er tillåter användare att skicka autentiserade e-postmeddelanden från sina domäner, genom att använda industristandardprotokoll som Sender Policy Framework (SPF) och DomainKeys Identified Mail (DKIM). Meddelanden som autentiserats med SPF eller DKIM kommer att klara din domäns policy för domänbaserad meddelandeautentisering, rapportering och överensstämmelse (DMARC).

Den här artikeln kommer att fokusera på DMARC:s policytillämpningsmekanism. Artikeln kommer att utforska några av anledningarna till att e-post kan misslyckas med DMARC-policyutvärderingen och föreslå lösningar för att åtgärda eventuella fel som du identifierar.

För en introduktion till DMARC och hur du noggrant väljer din e-postsändande domänidentitet. DMARC-efterlevnad är kritiskt för e-postleverans och är avgörande för organisationer som strävar efter att upprätthålla ett positivt avsändarrykte och säkerställa framgångsrik e-postleverans.

Det finns många fördelar när organisationer har denna korrekta inställning, dessa inkluderar:

• Förbättrad e-postleverans
• Minskad risk för att bli utsatt för e-postförfalskning och nätfiske
• Positivt avsändarrykte
• Minskad risk för att skickad e-post hamnar i mottagarens skräpkorg
• Ert "Brands" rykte.

Utifrån detta, låt oss utforska komplexiteten med DMARC och hur det kan gynna din organisations e-postkommunikation.

Vad är DMARC?

DMARC är en mekanism för domänägare att publisera SPF- och DKIM-skydd och berätta för mottagare hur de ska agera om dessa autentiseringsmetoder misslyckas.

Domänens DMARC-policy skyddar din domän från tredje part som försöker förfalska domänen i e-postheadern "From:" i e-postmeddelanden. Skadliga e-postmeddelanden som syftar till att skicka nätfiskeförsök med din domän kommer att bli föremål för en DMARC-policyutvärdering, vilket kan leda till att de sätts i karantän eller avvisas av den e-postmottagande organisationen. Denna strikta policy säkerställer att e-postmeddelanden som tas emot av e-postmottagare verkligen kommer från den påstådda sändningsdomänen, vilket minimerar risken för att människor faller offer för e-postbaserade bedrägerier.

Domänägare publicerar DMARC-policyer som en TXT-post i domänens _dmarc.<domain> DNS-post. Till exempel, om domänen som används i "From:"-rubriken är exempel.se, så skulle domänens DMARC-policy finnas i en DNS TXT-post med namnet _dmarc.exempel.se. DMARC-policyn kan ha ett av tre policylägen:

• En typisk DMARC-distribution av en befintlig domän börjar med att publicera "p=none". En ingen-policy betyder att domänägaren befinner sig i en övervakningsfas; domänägaren övervakar meddelanden som inte är autentiserade med SPF och DKIM och försöker se till att all e-post är korrekt autentiserad
  
  
• När domänägaren är säker på att alla legitima användningsfall är korrekt autentiserade med SPF och/eller DKIM, kan de ändra DMARC-policy till "p=quarantine". En karantänpolicy innebär att meddelanden som misslyckas med att skapa en domänjusterad autentiserad identifierare via SPF eller DKIM kommer att sättas i karantän av den e-postmottagande organisationen. Den e-postmottagande organisationen kan filtrera dessa meddelanden i skräppostmappar eller vidta en annan åtgärd som de anser bäst skyddar sina mottagare.
  
  
• Slutligen kan domänägare som är övertygade om att alla legitima meddelanden som använder deras domän är autentiserade med SPF eller DKIM ändra DMARC-policyn till "p=reject". En avvisningspolicy innebär att meddelanden som misslyckas med att skapa en domänjusterad autentiserad identifierare via SPF eller DKIM kommer att avvisas av den e-postmottagande organisationen.

Följande är exempel på en TXT-post som innehåller en DMARC-policy, beroende på önskad policy (p-taggen):

Denna policy säger åt e-postleverantörer att tillämpa DMARC-policyn på meddelanden som inte skapar en DKIM- eller SPF-autentiserad identifierare som är anpassad till domänen i "From"-huvudet. Justering innebär att en eller båda av följande inträffar:

• Meddelanden passerar SPF-policyn för MAIL FROM-domänen och MAIL FROM-domänen är densamma som domänen i "From"-huvudet, eller en underdomän av denna.
• Meddelanden har en DKIM-signatur signerad av en offentlig nyckel i DNS på en plats inom domänen för "From:"-huvudet. 

DMARC-rapportering

Rua-taggen i domänens DMARC-policy anger platsen dit e-postmottagande organisationer ska skicka sammanställda rapporter om meddelanden som godkänner eller misslyckas med SPF- och DKIM-anpassning. I regel är detta en e-postadress, typ rua=mailto:dmarcreports@exempel.se.

Domänägare, dmarcreports@exempel.se i detta exempel, analyserar dessa rapporter för att upptäcka meddelanden som använder domänen i "From:"-huvudet men som inte är korrekt autentiserade med SPF eller DKIM. Domänägaren kommer att försöka säkerställa att alla legitima meddelanden autentiseras genom analys av DMARC:s samlade rapporter över tid.

E-postmottagande organisationer som stöder att skicka DMARC-rapporter skickar vanligtvis dessa sammanställda rapporter en gång om dagen, även om dessa metoder skiljer sig från leverantör till leverantör.

Vad skall man typiskt göra för implementera DMARC framgångsrikt?

I ett nötskal:

• Se till att alla e-postmeddelanden som använder domänen i "From:"-huvudet autentiseras med DKIM- och SPF-domänjusterade identifierare. Fokusera på DKIM som det primära sättet för autentisering.
• Publicera en DMARC-policy (none, quarantine, eller reject) för domänen som återspeglar hur domänägaren vill att e-postmottagande organisationer ska hantera oautentiserad e-post som påstår sig vara från deras domän.

Nya domäner och underdomäner

Det är enkelt att implementera DMARC för domäner och subdomäner som aldrig använts för e-post. Man har ingen ryggsäck här att ta hänsyn till.

Dessa domäner kan börja direkt med "p=reject" DMARC-tillämpningspolicy eftersom policyn inte kommer att påverka befintliga program för att skicka e-post. Denna strikta tillämpning är till för att säkerställa att det inte finns någon oautentiserad användning av domänen och dess underdomäner.

Befintliga domäner

Domäner, och subdomäner, som redan används för e-post, där är det lite trickigare. Problemet här är att få kolla på hur domänen används för att skicka e-post, vilka organisationer använder den, vilka hemsidor och program använder den, och när de använder den, vilka e-postservrar skickar de igenom, och så vidare.

För dessa är en DMARC-implemtentering en iterativ process. Det är viktigt att få en fullständig förståelse för hur domänen och dess underdomäner används för e-postsändning innan du publicear en restriktiv DMARC-policy (p=quarantine eller p=reject).

För att komma igång med DMARC-implementeringen är det här några åtgärder att vidta:

1. Publicera en p=none DMARC-policy (ibland kallad övervakningsläge) och ställ in rua-taggen till den mottagre där du vill ta emot samlade rapporter.
2. Analysera de samlade rapporterna. E-postmottagande organisationer skickar rapporter som innehåller information för att avgöra om domänen och dess underdomäner används för att skicka e-post och hur meddelandena autentiseras (eller inte) med en DKIM- eller SPF-domänjusterad identifierare. Ett lättanvänt analysverktyg är Dmarcian XML to Human Converter.
3. Undvik att publicera en "p=quarantine"- eller "p=reject"-policy i förtid. Om du gör det kan det leda till blockerad eller minskad leverans av legitima meddelanden från befintliga e-postprogram.
   
   

Ett alternativ att börja använda DMARC på en befintlig domän är att skapa en helt ny subdomän och använda denna för att skicka e-post. Denna är då "ren" och man kan vara säker på att den uppfyller en restriktiv DMARC och mail från denna kommer att komma fram. "Ryggsäcken" får man hantera med en ingen-policy under en period.

Överhuvudtaget är det en mycket bra ide att skapa separata subdomäner för massutskick av mail. Dessa riskerar i mycket större omfattning att bli "skitiga" och när de väl blir det, påverkar det inte den ordinarie domänen som organsiationen skickar vanlig mail med.

Bilden nedan illustrerar hur DMARC kommer att tillämpas på ett e-postmeddelande som tas emot av den e-postmottagande servern och åtgärder som vidtas baserat på tillämpningspolicyn:

För att DMARC skall uppfyllas hos den mottande e-postservern måste båda resultaten ovan vara Y.

Hur får SPF och DKIM DMARC att uppfyllas?

Hur SPF lever upp till DMARC

När du skickar ett e-postmeddelanden sätts automatiskt av e-post servern en MAIL FROM adress genom att sätta ett e-posthuvud Return-Path. Denna kan se ut så här:

Return-Path: <kalle@exempel.se>

När man skall skicka e-post måste man autentisera sig. Det gör man med sin e-postadress och lösenordet till denna (i regel). I detta exempel är det kalle@exempel.se som autentiserat sig. E-postservern vet då att det är just det här e-postkontot som skickar brevet. Denna rad är inte något som man som användare kan påverka, det är servern som sätter den. Till skillnad till From: raden i e-posthuvudet som användaren kan sätta till vad som helst i sin e-postklient. Så, MAIL FROM kan man lita på, men inte på From:.

När den mottagande e-postservern skall utvärdera SPF tittar den på den SPF policy som MAIL FROM domänen (exempel.se i detta exempel) har. Denna skall då innehålla den avsändande e-postserver, dess IP-adress mer specifikt. Stämmer det, då får man "SPF=PASS".

Utöver "SPF=PASS" kräver DMARC att MAIL FROM domänen och From: domänen hör ihop, dvs att de antingen är desamma eller att MAIL FROM är en subdomän till From: domänen. Det sistnämnda fungerar endast om DMARC innehåller direktivet aspf=r, vilket är standardinställning om man inte anger den alls. r står här för relaxed.

Hur DKIM lever upp till DMARC

Två kriterier:

1. Att DKIM aktiverats för er domän. Detta är något ert webbhotell gör. Med ISPConfig kan användaren gör det själv, har man bara tillgång till den Enkla kontrollpanelen behöver man kontakta support.
2. Att man alltid skickar mail via sin mailserver hos webbhotellet. Detta är särskilt viktigt att tänka på när man skickar e-post från sin hemsida, t.ex. om man använder WordPress. Som standard skickar dessa e-post genom webbservern, och då kommer inte DKIM vara uppfyllt.

DMARC ställer dock ytterligare ett krav på DKIM, vilket också framgår av bilden ovan. MAIL FROM domänen måste vara samma som den är i "d=" taggen i DKIM-signaturen som finns i själva e-postbrevet.

DKIM och SPF tillsammans

E-postmeddelanden är helt autentiserade när meddelandena passerar både DKIM och SPF, och både DKIM- och SPF-autentiserade identifierare är domänjusterade, dvs att de angivna domänerna stämmer överens enligt bilden ovan.

Om endast DKIM är domänjusterat, kommer meddelandena fortfarande att passera DMARC-policyn, även om SPF "pass" är ojusterat. E-postmottagare kommer att ta hänsyn till hela sammanhanget för SPF och DKIM när de avgör hur de kommer att hantera dispositionen av meddelandena du skickar, så det är bäst att fullständigt autentisera dina meddelanden när det är möjligt.

Google har satt som krav att antingen DKIM eller SPF skall vara uppfyllt för att brev överhuvudtaget skall tas emot. Här behöver de inte vara domänjusterade. Dock, om någon av dessa fallerar, då är det sannolikt att brevet tas emot, men hamnar i mottagarens skräpkorg.

Skickar man stora mängder mail till Google gmail adresser, då kräver Google att DMARC uppfylls fullt ut för att ta emot mailet.

Webbhotellet förenklar i regel denna process väsentligt, genom att kunna göra det genom några klick.

Varför misslyckas DMARC?

Det finns tillfällen då du kanske märker att meddelanden misslyckas med DMARC, oavsett om dina meddelanden är helt autentiserade eller delvis autentiserade. Följande är saker du bör hålla utkik efter:

Ändring av e-postinnehåll Ibland ändras e-postinnehåll under leveransen till mottagarnas e-postservrar.

Denna ändring kan vara ett resultat av en säkerhetsanordning eller anti-spam-agent längs leveransvägen (till exempel: meddelandet Ämne kan ändras med en "[EXTERN]"-varning till mottagarna). Det modifierade meddelandet ogiltigförklarar DKIM-signaturen vilket orsakar ett DKIM-fel. Kom ihåg att syftet med DKIM är att säkerställa att innehållet i ett e-postmeddelande inte har manipulerats under leveransprocessen. Om detta händer kommer DKIM-autentiseringen att misslyckas med ett autentiseringsfel som liknar "DKIM-signature body hash not verified".

Lösningar:

• Om du har full kontroll över hela vägen som e-postmeddelandet kommer att passera från avsändare till mottagare, se till att ingen e-postserver emellan ändrar e-postinnehållet under överföring.
• Sätt DMARC-policyn i övervakningsläge (p=none) tills dessa problem har identifierats/lösts.

Vidarebefordran av e-post

Vidarebefodran av e-post är ett stort problem att få att fungera med SPF/DKIM/DMARC. Med policies som Google har är det högst osäkert om vidarebefodrad e-post verkligen kommer fram till ens gmail-adress, och gör det väl det, då hamnar det i skräpposten.

Det är inte ovanligt att ett meddelande som vidarebefordras, resulterar i att både/antingen SPF och DKIM misslyckas med att skapa en domänjusterad autentiserad identifierare. För SPF betyder det att e-postservern för vidarebefordran inte är listad i MAIL FROM-domänens SPF-policy.

Det är möjligt för en e-postserver för vidarebefordran att undvika SPF-fel och ta ansvar för e-posthanteringen för de meddelanden den vidarebefordrar genom att skriva om MAIL FROM-adressen så att den ligger i den domän som kontrolleras av vidarebefordranservern. Vidarebefordran av servrar som inte skriver om MAIL FROM-adressen utgör en risk för identitetsattacker och nätfiske. Å andra sidan, om e-postservern gör denna ändring i meddelandet, då kommer DKIM att fallera. Det har utarbetats olika lösningar för att lösa detta, men ingen av dessa är tillräckligt robusta. Slutsatsen är helt enkelt att man inte skall använda sig av vidarebefodran. Gör man det ändå, då får man ta eget ansvar för det, e-postleverantören kan inte lösa det problemet.

Skickar e-post från sin webbsida

Detta är något som ofta glöms bort. Mail som skickas från en webbsida kan t.ex. vara beställningsinformation, fakturor, supportärenden osv. Om man använder de standardfunktioner som ofta finns i olika program, då kommer man att skicka e-post som inte uppfyller DMARC. Man riskerar också att SPF och DKIM fallerar, och då kommer inte den e-post man skickar komma fram till t.ex. Google Gmail.

Här måste man se till att man konfigurerar sin hemsida att skicka e-post på rätt sätt. Läs mer om detta i denna artikel Hur kan jag använda mail med php?.

Referenser

• https://aws.amazon.com/blogs/messaging-and-targeting/email-authenctication-dmarc-policy/

Vi rekommenderar 

Marcs Updater

Produktsida: https://registrera-doman.se/webbhotell-webbmotell.php

WebbMotell med ett M

Vår Premium plan, som kan uppgraderas, är något utöver det vanliga. Ni får en helt egen server för er själv. Ni konkurrerar inte med någon annan om CPU och minne, allt är ert! Och detta till ett pris som motsvarar ett vanligt webbhotell. Vad mer som motsvarar ett eget webbhotell är att ni inte behöver bekymra er om tekniken alls, vi sköter allt, ni sköter era hemsidor med kontrollpanelerna och vi tar hand om resten.

Ni betalar bara för den support ni själv behöver, ni betalar inte för support som andra behöver. På så sätt kan vi erbjuda webbhotell med ett M, hotell till budgetpris.

Vi erbjuder också två instegskonton, Start och Standard, från 99 kr/år. Dessa är vanliga webbhotellkonton där ni delar resurser som CPU och minne/RAM med andra kunder.

Säker hemsida med SSL

Säkerhet blir allt viktigare och fokus på detta blir allt större. Google, Bing och många andra, uppmuntrar hemsidor till att vara krypterade. Detta oberoende av vad hemsidan innehåller, även om det är hemsidor som bara läses, ingen information skickas till dem. För att kryptera en hemsida behöver man skaffa ett certifikat och sedan med hjälp av sin webbhotellleverantör installera detta. Man behöver också en egen dedikerade IP adress, något som blir allt svårare då dessa sedan länge har börjat ta slut. Detta är en omständlig process, som också måste repeteras varje år när certifikatet behöver förnyas.

Tecknar ni webbhotell med oss ingår SSL, utan kostnad och utan krångel. Era sidor krypteras och Google respektive Bing blir glad. Era sidor kommer i varje fall inte straffas av dem pga av att de inte är krypterade. Vill ni installera egna certifikat, på traditionellt vis, stödjer vi naturligtvis det också.

Ultrasäker E-Post

E-post idag är i princip en värdehandling. Ofta används e-post för att bekräfta vem man är, en sort av id-legmitation. E-post används också ofta för inloggning till viktiga konton, där man har tillgångar. Det är därför nu för tiden av största vikt att man skyddar sin e-post,läs mer om Ultrasäker E-Post här.

Vi erbjuder ultrasäker e-post som alternativ helt kostnadsfritt för samtliga våra webbhotellplaner. Med vår ultrasäkra e-post går det bara att läsa och skicka e-post genom att logga in till en webmailportal med 2-faktors autentisering, på samma sätt som t.ex. Gmail och Hotmail. Även om ert lösenord till ert e-postkonto skulle komma på vift kan ingen komma åt er e-post. Priset man får betala är att man bara kan använda webmail för att läsa och skicka sin e-post, man måste använda en webbläsare, det går inte att använda de inbyggda e-postklienterna som finns på telefoner och datorer.

Weebly

Vi erbjuder världens nog mest använda och antagligen bästa webbyggare Weebly helt gratis med alla hotellplaner. Med denna version kan ni enkelt börja bygga er hemsida, behöver ni mer funktioner kan ni enkelt uppgradera. Den största fördelen med att använda Weebly genom oss är att hemsidan ni skapar med Weebly, den publiserar på ert webbhotellkonto hos oss. Ni kan då vara säker på att er hemsida finns inom EU och att vårt support har full kontroll över er hemsida, med t.ex. backup.

Weeblys kraftfulla webbplatsbyggare med dra och släpp-funktioner samt guider hjälper er att nå målet snabbare utan att någon kodning krävs.

Weeblys dra och släpp-funktioner gör det lätt att skapa en kraftfull, professionell webbplats utan att ha några tekniska kunskaper. Mer än 40 miljoner entreprenörer och småföretag har redan använt Weebly för att bygga upp sin närvaro på nätet med en webbplats, blogg eller butik.

Läs mer om vårt Weebly-erbjudande här.

Massor av appar

Med Installatron kan ni enkelt installera, uppgradera och avinstallera massor av mycket kraftfulla program som finns på Internet. Med dessa program kan ni bygga er hemsida, utan att behöva någon kunskap om html, php osv.

Genom Installatron kan ni enkelt installera portalprogramvaror, shoppingsystem, forum, supportsystem, bloggar, gästböcker och mycket mycket mer. Med dessa programvaror går det t.ex. att bygga upp ett komplett företag med ett kundssystem, med varukorgssystem, med supportsystem osv.

Är det en Blogg ni behöver? Ni installerar då WordPress enkelt med Installatron. Det är så enkelt att installera att vem som helt kan göra det och behöver ni hjälp hjälper vi er med det.

Läs mer om Installatron här.

Oöverträffad prestanda - Servrar optimerade för php drivna hemsidor

Vår server-miljö är optimerad för prestanda. Dels för att vi använder bästa möjliga hårdvara och dels för att vi är noga med att inte placera för många kunder på varje server. Våra servrar har aldrig en last större än 1. Vi övervakar detta noga och uppgraderar servrar snabbt när det behövs. Det är oerhört viktigt för oss att våra kunder upplever sina hemsidor som snabba. Det är överordnat det mesta, det är en del av vår affärsidé.

Många använder i dag php för sina hemsidor. Exempel på hemsidor som använder php är de som använder WordPress och Joomla. php är dynamisk, vilket innebär att servern måste göra ett antal beräkningar för varje sida som visas. Detta tar tid och kan göra hemsidan långsam.

Våra servrar är optimerade för hemsidor byggda med php, vi använder Apache med event-mpm och php-fpm. Vi erbjuder emellertid Nginx (Engine X) till våra Premium planer, för hemsidor som har oerhört många besökare och då behöver extra prestanda.

När skall jag då välja Nginx istället för Apache? Ja, idag är det inte helt självklart då Apache i stor utsträckning mitigerat sina tidigare tillkortakommanden. Har man en dynamisk sida, t.ex. WordPress, då är det absolut inte säkert att Nginx är snabbare än Apache med event-mpm och php-fpm. Nginx kan vara snabbare för statiska sidor. Är man inloggad som användare i WordPress, då är defintivt inte nginx snabbare. Nginx är främst ett alternativ om man har många, väldigt väldigt, många besökare till sin hemsida. Nginx gör inte en hemsida snabbare för få besökare, men kan gör det om man har väldigt väldigt många besökare. Har man få besökare till sin hemsida, typ några tusen per dag, då upplevs absolut ingen skillnad alls. Hursomhaver, för den som vet vad den vill erbjuder vi som sagt också Nginx.

Väljer ni Premium kontot får ni tillgång till en helt egen Redis. Ni kan bland annat använda denna för WordPress och då få en osannolikt snabb WordPress hemsida. WordPress har utmärkt stöd för Redis, bland annat genom Redis Object Cache plugin. Superenkel att installera från WordPress admin sida.

Säkerhetskopiering med stöd för GDPR

Hanterar ni personlig information? Eller ännu värre, känslig personlig information? Gör ni det ställer GDPR hårda krav på att ni har kontroll över er information, vart data lagras, vem som kan se den.

Vi erbjuder säkerhetskopiering som klarar av dessa hårda krav. Med vår GDPR backup krypteras all data och data lagras aldrig utanför EU eller utanför EU jurisdiktion. Ni kan också välja om ni inte vill att er data skall säkerhetskopieras över huvud taget, varken hemsida eller e-post. I ISPConfig finns utmärkta verktyg för att själv hantera sin säkerhetskopiering.