Kommentarerna som påpekar att SMTP inte kräver autentisering är korrekta. Som sagt, alla tre av alternativen du angav är osäkra, förutsatt att servern använder hårdvara och mjukvara. Jag ska visa varför var och en är osäker, även om jag inte följer din ursprungliga beställning.
Tänk om någon skulle stjäla servern? Sedan kunde de bara öppna filen eller databasen, läsa lösenordet och omedelbart få tillgång till all viktig information i företaget. Så om du inte har beväpnade vakter runt servern dag och natt, är detta redan ganska osäkert.
Men det blir värre. Inget datorsystem är helt osårbart för attacker, och flera väl omskrivna attacker (Sonys PlayStation Network, till exempel) under de senaste åren har visat att en angripare kan ta sig till innehållet i diskfiler och databaser utan fysisk åtkomst. Dessutom verkar det utifrån din fråga som om servern i fråga är avsedd att acceptera paket (HTTP-förfrågningar, inkommande e-postmeddelanden etc.) från omvärlden, vilket förstärker din attackyta.
Detta är frestande, men det här är ännu mer skadligt än alternativ 2 eller alternativ 3. För det första lagras ett privat sista strängfält i .class-filen som genereras av Java-kompilatorn, så med det här alternativet lagrar du redan det okrypterade lösenordet på serverns hårddisk. Efter att ha kompromissat med servern som i alternativ 2 eller 3 kan en angripare bara köra javap för att få ut klartextlösenordet från .class-filen.
Detta tillvägagångssätt breddar din attackyta ännu mer. Om lösenordet lagras som en del av källkoden är det plötsligt tillgängligt för alla utvecklare som arbetar med koden. Enligt principen om minsta privilegium bör utvecklarna inte känna till extra lösenord, och det finns en mycket god anledning här. Om någon av utvecklarnas maskiner blir stulen eller äventyrad utifrån, kan angriparen titta igenom den komprometterade maskinens hårddisk och få klartextlösenordet. Sedan finns det källkontroll. En av de riktigt viktiga fördelarna med källkontroll är att den låter dig inspektera vilken tidigare version av din kod som helst. Så även om du byter till en säker metod i framtiden, om lösenordet någonsin har kommit in i källkontroll är källkontrollservern en potentiell attackpunkt.
Alla dessa faktorer visar att även om HTTP/e-postserverns säkerhet är förstklassig, ökar alternativ 1 attackytan så mycket att HTTP/e-postserverns säkerhet inte riktigt hjälper.
Extra detalj:I början angav jag "förutsatt att servern använder hårdvara och mjukvara." Om du inte använder hårdvara och mjukvara kan du göra saker som att starta från skrivskyddad lagring och endast använda en krypterad databas, vilket kräver att en person tillhandahåller dekrypteringsnyckeln vid varje start. Därefter finns den dekrypterade informationen endast i minnet och skrivs aldrig till disk. På det här sättet, om servern blir stulen, måste en angripare koppla ur servern och därmed förlora all dekrypterad information som bara fanns i minnet. Den här typen av inställningar används ibland för en Kerberos KDC (med servern i en låst låda för extra säkerhet), men används sällan annars, och är uppriktigt sagt överdrivet när det finns ett enkelt sätt att lösa ditt problem utan att gå till allt detta extra kostnad.