Mailtjänst för larmgrejer

jag satte i förrgår upp mail på gmail med enbart user / pass. Var bara tvungen att klicka i "less secure third party applications"

Funkar finfint så vitt jag kan se

mvh Lazze

Behöver du endast skicka mail till dig själv?
Har du en statisk extern IP? (IPv4 eller IPv6 spelar ingen roll, så länge din e-postleverantör stödjer MX på motsvarande protokoll.)
Tillåter din ISP utgående port 25?
Har du, eller kan du skaffa en egen domän?

Om svaret på alla fyra är ja så kan du sätta upp din mail-leverantörs MX-record som SMTP-server i dina enheter. Ingen autentisering, port 25. Se till att från-adressen är satt till en adress som ligger under din domän, och att du har SPF-records i domänen som tillåter mail från din externa IP-adress.

Inga externa tjänster krävs, men det kommer gå sönder om din mailleverantör någonsin bestämmer sig för att ändra DNS-namnet i sina MX-poster.

Låter det här som en intressant lösning kan jag skriva lite mer.

Är du säker på det? "Use an app password" står ju som en lösning på den länkade sidan. Och texten i början...

... är inte skriven så att den säger att app passwords (som inte är "your password") stängs av.

sorry för att ha svarat men läst dåligt. Läste mer på googles sida nu samt googlade net c# gmail smtp app password. Verkar som många fått det att funka med app-password genom att helt enkelt fylla i det passwordet i det fält man skickade sitt vanliga password tidigare.

mvh Lazze

Det är inte möjligt att använda en tjänst som är mer gjort för sånt här, t.ex. Pushover?

Lär garanterat funka med gmail app passwords.
Man fick ju börja använda dem när man introducerade 2FA inloggning för snart 10 år sedan.

Visste inte ens att de tillät user/pass överhuvudtaget då det är en enorm säkerhetsbrist.

jag tolkade Googles text som att det var lösningen...så det borde verkligen fortsätta att fungera

// LZ

Om credentials går TLS'at, vad är det då som är en ENORM säkerhetsbrist - om man nu inte postar dess credentials öppet på twitter?

Jag vet att Google inaktiverar funktionen med jämna mellanrum och att man får gå in och aktivera den igen. Men nu slår de alltså igen den för gått. Frågan är ju om app-passworden kommer fungera tillförlitligt? eller om de inaktiveras också, speciellt om de inte används? Är det en grej som larmar en gång om året så är det ju viktigt att det fungerar

Du skapar app-passwordet och sedan ger du det ett smeknamn. Du kan bara se lösenordet en gång och det rekommenderas inte att du sparar det förutom i det program/pryl där det används.

På vilket sätt är det inte en säkerhetsrisk att ge ut sitt användarnamn/lösenord till epostkonto till tredjepart?
Du tillåter full access till ditt konto till en tredjepart. Vad händer om tredjeparten är illasinnad eller blir hackad?

Det är väl knappast FUD?
Om TS nu skulle använda "utrustning" som är skapad av tredjepart och ger den användarnamn/lösenord för mailkontot så har man ju per definition gett tredjepart tillgång till den informationen, och de kan göra vad som helst med kontot som du kan. Enbart om TS kodat allt själv så är det inte så.

App passwords är bättre än att ge bort användarnamn/lösenord, men inte optimala de heller. Appar kan fortfarande göra i princip vad som helst (som att skicka mail i ditt namn, ta bort mail, ändra kalender, lägga till/ta bort/ladda hem filer från Drive), men här ger man dem åtminstone inte ditt "riktiga" lösenord, och möjligheten att ta bort tillgången för en app finns alltid. Ger man bort det riktiga lösenordet kan en ond tjänst ju helt enkelt byta ut det och låsa dig ute permanent; den möjligheten finns inte med app passwords.

Jag har tyvärr inget direkt svar jag kan ge dig mer än frågan om du brukar ge ut dina inloggningar till tredjeparter?

I detta fall finns app passwords av en anledning.
Finns inga realistiska scenarion där man ger ut full access till en tredjepart. Det finns varken en vinst eller logik i att göra det.

Jag skulle vilja säga att det är själva definitionen av FUD. I stället för att förklara vad man kan göra och hur man säkrar upp tekniken så kör man med skrämselpropaganda. Inte speciellt konstruktivt i min mening.

Jag vet inte vilken utrustning TS refererar, till vet du? Ett exempel på utrustning som kan skicka mejl med larm, status och faktisk mejl är t ex Brandvägg, NAS och multifunktionsskrivare. Det betyder inte att tillverkarna av dessa enheter eller dess serviceorganisation automatisk får tillgång till kontouppgifterna.

Jag vet inte om TS använder sitt personliga mejlkonto för sin utrustning, vet du? Utrustning som skickar mejl skall tilldelas ett eget konto. Att rekommendera annat vore hål i huvudet såklart.

Vi använder SMTP2Go för alla larmutskick. Följ guiderna och sätt upp SPF och DKIM för avsändardomänen så funkar allt klockrent.

+1. Ett konto som f.ö. enbart har tillgång till SMTP - som då naturligtvis är uppsatt att inte ha expiration på lösen satt till fåniga tre månader som alla större svenska företag förespråkar - trots att även NIST sedan länge rekommenderar längre lösen som en människa kan komma ihåg utan att behöva skriva upp det på en Post-It lapp var tredje månad.

Kanske en tjänst som ex. SendGrid kan vara intressant?
Den är gratis upp till 100 mejl/dag och har ett API för att hantera åtkomst från dina applikationer.

Kräver stöd. Många saker som skickar meddelanden stödjer bara epost.

Nu blir jag nyfiken, har du något exempel på en applikation som bara stödjer e-post och inte har ett CLI?

CLI finns säkert ofta, men räcker nog inte alltid. T.ex. vad någon gjorde för att få in Pushover på TrueNAS.

https://medium.com/nerd-for-tech/truenas-bespoke-alerts-e8f91...

Var är alla artiklar på Aftonbladet för detta? Det är ju skitstort och många kommer bli lidande.

Men en dum fråga det står Less secure apps. Det finns ingen app som man kan använda som uppfyller kraven och man kan be sin lösning denna ska skicka mailet. T.ex. att man skapar en xml fil till detta program som ska sända.

Det står att ens app ska stöda Sign in with Google" option, det är ingen liten C# open source lösning man hittar som stöder detta eller? Vad nu Sign in with Google" option betyder.

Jag håller med, det är inte bra att göra det till sitt personliga epostkonto. Som säkert också med gmail är kopplat till massa andra saker. Nu har möjligheten sedan länge varit opt-in på google och inte öppen per default.

Det är en helt annan sak att skapa en dedikerad adress för uppgiften att skicka larm.

Så som jag förstått det kan man använda samma app-lösenord på flera olika ställen. Men de kanske har något skydd som känner av hur klienten "hälsar" och blockerar lösenordet. Fördelen är ju att om en pryl blir stulen eller skrotad att du kan fimpa det lösenordet, för ökad säkerhet

Jag skulle säga att det är många prylar. Det är vanligt att de kör SMTP och SNMP trap eller syslog. Det tar nog ytterligare innan de får stöd för att skicka http-anrop skulle jag säga.

Det är nog många som har prylar som använder google för att mejla. Så det kommer nog ställa till det lite i världen.

Appar som stödjer sign in with google öppnar en webbsida vid inloggningen, om man har MFA kör man de då och sedan får appen en tocken. Om sedan appen används regelbundet så lever den här tocken. I mitt epostprogram på datorn har jag loggat in en gång och sedan håller den mig inloggad. När jag startade min gamla mobil som legat i lådan ett tag så fick jag däremot logga in. Vet inte hur avancerat det är att bygga in funktionaliteten.

Den metoden används av bl.a. DYN.COM för att inte exponera ddns lösenord i klartext.