Egen SMTP Server i stedet for post@e-conomic.dk

Question

I dag modtages faktura fra følgende email adresse:

post@e-conomic.dk

Vi oplever større og større problemer med at kunder ikke modtager faktura - og vi bruger stadig mere tid på at gensende og rykke for betaling.

Hovedparten af vores kunder er i udlandet - og rigtig mange er i USA og de kender slet ikke til en .dk email adresse og faktura ender ofte i deres SPAM filtre.

Vi har fuldstændig styr på vores egne emails og kunderne kender vores domaine (som er .com).
Derfor er det super frustrende at se så vigtig en korrespondance forsvinde ud i det blå.

Kan vi få lov til at sætte vores egen SMTP Server op? Please ....

Tak
Jesper Frier

Answer 1

Hej Jesper,

Tak for dig forslag. Jeg vil lige vende tilbage til dig, når jeg har vendt denne med mine teknikere.

Answer 2

Hej Steffen,

Har du nyt fra teknikerne?

Tak
Jesper

Answer 3

Hej Jesper,

Det har jeg. Jeg er dog ikke tekniker nok til at komme med svaret, så jeg vil lige få en af vores teknikere til at svare dig.

Answer 4

Hej Jesper,

Umiddelbart kan det selvfølgelig synes som en forholdsvis lille ting at tilbyde at få sendt mails gennem jeres egen mailserver.

Der er dog to forhold, der gør, at det desværre ikke er noget, vi vil kunne tilbyde i den nærmeste fremtid:

<em>For det første</em> vil vi ikke have mulighed for at yde support - korrekt opsætning af mailservere er uvægerligt en teknisk opgave, og vores supportere er nu engang ikke teknikere.

<em>For det andet</em> vil valgfri SMTP-server kræve en større grad af fleksibilitet i den måde, hvorpå e-conomic-applikationen håndterer kommunikationen med serveren. Forskellige mailservere har det desværre med at håndtere samme mails og/eller fejl vidt forskelligt - så vi ville i givet fald være nødt til <em>enten</em> at opstille nogle meget klare tekniske definitioner af, hvorledes en egen SMTP-server skulle tilbagemelde forskellige typer fejl, <em>eller</em> ende med at stå med konstante ændringsønsker ud fra alle mulige forskellige mailservere.

(Og ja, der findes en vis form for standarder, som vi bare kunne kræve, at man overholder. Det gør der også for fx HTML, Javascript, CSS, etc. - men dét ændrer ikke på, at visse browsere er så udbredte, at vi alligevel i praksis er nødt til at håndtere dem )

<em>Til gengæld</em> gør vi os for tiden nogle <em>overvejelser</em> om at muliggøre valgfri afsenderadresse - som alternativ til den nuværende post@e-conomic.dk. Det, vi i den forbindelse skal have afklaret internt, er dog, om vi vil kunne formidle de deraf følgende begrænsninger tilstrækkelig hensigtsmæssigt:

1. Ved brug af egen afsenderadresse fraviges muligheden for at sende digitalt signerede mails - da signaturen knytter sig til afsenderadressen, og vi desværre ikke kan tilbyde, at man kan uploade sin egen signatur.

2. Hvad værre er: Visse spamfiltre og -filtreringsprincipper vil være på vagt over for mails, hvis afsenderadresse ikke er hjemmehørende på den sendende mail-server (som jo stadig vil være e-conomics mailserver).
For at undgå problemer hermed vil man som afsender skulle registrere, at e-conomics mailserver gerne må sende mails på vegne af én. Dette kan hurtigt blive temmelig teknisk - og vores supportmodel er ikke gearet til denne type superbruger-funktioner.


Mvh.

Answer 5

Hej Christian,

Tak for dit svar. Det var desværre ikke det svar jeg havde håbet.
Supporten kan I bare frasige Jer - ikke noget problem - og forståeligt at I gør det.
Ja, der er nogle tekniske udfordringer der skal klares - det er jeg sikker på I kan - hvis I vil (det kan stort set alle andre udbydere af services). Vi hjælper gerne hvis I har brug for det?
Valgfri e-conomics afsender adresse vil ikke hjælpe på spam filtreringen, da emails stadig modtages fra en adresse kunden ikke kender og har tillid til (det er hele problemet).

Jeg oplever det lidt som om at I ved bedst og nok skal sørge for at råde og vejlede. Det er den holdning jeg ikke forstår... når vi snakker om en service som reelt ikke har noget med e-conomics at gøre ... eller er emails en del af e-conomics efter Jeres opfattelse? Det er måske her det reelle problem er ...  

Vi har ikke råd til at  sende fra <a href="mailto:post@e-conomic.dk">post@e-conomic.dk</a> fordi betalinger udeblir i væsentligt omfang. Vores eneste løsning er derfor at sende pr. post - vi har kunder i +50 lande, så det forsinker også betalingen og koster ekstra i administration og virker bare totalt forældet. Vi vil helst blive hos e-conomics, men dette er kritisk for os og vi vil helt sikkert kigge efter andre muligheder hvis det bliver nødvendigt.

Glem lige supporten for en stund (lad os antage at den sørger kunden selv for - eller kundens SMTP udbyder hvilket er helt normalt).

Er teknikken så det reelle problem her?

Jeg tænker lidt videre ... har I udenlandske kunder? Hvad gør de? Ved de der er et problem?

Tak
Jesper

Answer 6

Jesper - ikke fordi jeg er uenig men jeg har et alternativt forslag.
Det kan simpelhen ikke passe at e-conomic ikke kan levere et produkt som kan sende post uden at det bliver fanget i kundernes - kunders spamfiltre. Jesper kan jo ikke være den eneste med dette problem, og det bedste ville da være en løsning for alle.

Jeg foreslår at e-conomic analyserer problemet med de udenlandske spam filtre og derefter justerer på de ting som gør at spam filtrene fanger posten. Hvis problemet er at afsender domænet er e-conomic.dk, ja så kan e-conomic jo i første omgang tilbyde at brugeren sendte fra e-conomic.com (eller et andet .com domæne). Derudover er der massere ting der kan gøres i DNS mht reverse lookup osv. Samtidig kan e-conomic overveje at vælge at sende via en extern anderkendt mailservice og dermed opnå en bedre rating hos modtagerne.
Jeg har selv haft erfaring med andre systemer som havde problemer (bla spam) med at sende direkte fra serveren og problemet blev løst ved at sende posten via en smart host og ASMTP til en ekstern email udbyder.

mvh

Tue

Answer 7

Jesper - overvejelsen går nu ikke på at kunne anvende en valgfri <em>e-conomic</em>-afsenderadresse, men derimod en <em>helt</em> valgfri adresse.

Ifald modtager <em>vælger</em> - direkte i sit mailprogram, eller ved sin brug af spamfilter - at filtrere indgående post med udgangspunkt i whitelisting på afsender-<em>adressen</em>, burde dette da løse problemet?

Som jeg nævner, kan valgfri afsenderadresse dog - ud over, at man så vil fraskrive sig muligheden for at få sendt digitalt signerede mails - potentielt kræve noget opsætning fra vores kunders side af, af hensyn til fx SPF-baseret spamfiltrering. Dette er heldigvis noget, ejeren af <em>afsenderadressen</em> kan/skal sætte op, snarere end ejeren af <em>den sendende SMTP-server</em> - men dét ændrer ikke på, at vi erfaringsmæssigt kan få meget svært ved at formidle, at support af dette vil være begrænset til en standard-vejledning, som man så må videregive til sine egne teknikere.

Tue - som generel betragtning er mails kontra spamfiltre jo en konstant katten-efter-musen. Grundlæggende kan jeg ikke sige mig fri for det synspunkt, at hvis man vælger at overlade til tredjepart at sortere sin post efter samme tredjeparts løbende ændrede principper, så kan det ikke pr. definition være afsenderens ansvar at holde sig orienteret om samme løbende ændrede principper. Principper, som måske endda ikke altid er offentlige.

Dét er dog så, indrømmet, en temmelig teoretisk betragtning - i praksis <em>oplever</em> mange det jo som afsenderens skyld, hvorfor vi selvfølgelig også har brugt en del krudt på at få vores mail-setup skruet korrekt sammen i forhold til de <em>server-setup-mæssige</em> forhold, spamfiltre <em>almindeligvis</em> checker på.

Vi kan dog dårligt forhindre kunder i eksempelvis at sende tilbud ud med *** Here is your offer *** som emne - dette er faktisk et autentisk eksempel, hvor vores kunde undrede sig over, at hans kunde ikke modtog mailen

Jesper - som jeg forstår dig, har en del af dine kunder whitelisting-baserede spamfiltre. I så fald er det vel bedøvende ligegyldigt, hvilket e-conomic-domæne vi sender fra; så skal samme kunder tilføje noget til deres whitelists under alle omstændigheder?

(Vi er faktisk derudover ved at teste afsendelse via en standard ekstern service- i første omgang for vores egne mails. Om det er helt fleksibelt nok, og i øvrigt vil kunne tilbydes til vores kunder til en fornuftig pris, er dog stadig usikkert - så lige dét ligger ikke lige om hjørnet).


Mvh.

Answer 8

Jesper,

Bonusspørgsmål:

Er det dit indtryk, at dine (amerikanske) kunders problemer med afsenderadressen kun er i forhold til .dk kontra .com - og egentlig ikke så omfattende, at de reelt kører per-individuel-adresse whitelisting?

Vi kommer nemlig under alle omstændigheder til at konsolidere vores interne afsenderadresse i den kommende tid - alene for at forenkle vores løbende administration af digitale signaturer - så når vi forventeligt konsoliderer på .com, vil vi måske allerede dér være kommet et stykke?


Mvh.

Answer 9

Hej Christian,

Tak for dit indspark Tue ...   

Som udgangs punkt ved kunderne ikke at deres faktura er fanget i spam filter. De konstaterer bare at de ikke har modtaget faktura når vi rykker og beder os gensende. Så vi ved ligeså lidt som spammerne om hvad der konkret trikker de mange forskellige spam filtre.

Lad mig gøre det lidt mere konkret. Jeg har kørt en test på en ganske normal faktura afsendt fra <a href="mailto:post@e-conomics.dk">post@e-conomics.dk</a>

Faktura fanges i disse filtre:
<ul>
Outlook - The built-in junk e-mail filter for Outlook, which ships as part of Microsoft Office. This has various sensitivity settings, here we have set it to High.
Sender Policy Framework - Sender Policy Framework (SPF) is an e-mail sending validation system designed to prevent e-mail spam by confirming the sender is permitted to send via their host. SPF allows administrators to specify which hosts are allowed to send e-mail for a domain.
DKIM - DomainKeys Identified Mail (DKIM) is a method for associating a domain name to an email, thereby allowing an organization to take responsibility for a message in a way that can be validated by a recipient.
DomainKeys - Although still in use today, Domain Keys has been described as a historic protocol and DKIM is considered its replacement.
Sender ID - SenderID is very similar to Sender Policy Framework (SPF) with a few additions. It supports additional fields that can be validated, but in almost all cases a correct SPF record will suffice in passing a SenderID filter.
</ul>

Ovenstående indikerer overfor mig at der er et problem som løses ved at vi selv bliver ansvarlig for afsendelsen.

Faktura fanges IKKE i disse filtre:
<ul>MessageLabs - Postini - Barracuda - SpamAssassin - Gmail - Yahoo! Mail - Mobile Me - GMX - Hushmail - FastMail - Lycos - Mail.com.</ul>
 
Jeg ser kun én reel løsning på problemet - at I overlader ansvaret for email afsendelsen/modtagelsen til os kunder. Så har vi styr på hvad der gøres og hvorfor (og så beslutter vi også om digitalt signerede mails har nogen betydning). At skifte mellem forskellige e-conomics email adresser ser jeg ikke som nogen løsning. Jeg har stadig meget svært ved at se support problematikken da kunden bare skal orienteres og selv vælger.

<em>En bilforhandler sælger jo heller ikke den lovpligtige ansvarsforsikring</em>   

Jeg er glad for at du holder fast og er lydhør - det er den første forudsætning for at findes en løsning som virker for os begge ... eller rettere ... for rigtig mange af Jeres kunder som er uvidende om problemstillingen.

Tak
Jesper Frier

Answer 10

Holder du stadig påskeferie ... eller er det sort snak det jeg skriver?

Jeg er nødt til at vide hvor I står vi kan komme videre med løsningsmodeller da det har højeste prioritet hos os.

Tak.