E-poststandard för icke-SPAM?

[DeeDee]

Hej!

 

Vi har en appliance-burk som filtrerar ut SPAM. Vi har ett problem med att ett av våra verksamhetssystem skickar lösenord till användare som glömt sitt lösen spärras i vårt filter, eftersom det saknar To: mottagare.

 

Vi anser att det tillhör epoststandard att skriva en To: mottagare och inte bara en Bcc: mottagare, men tyvärr har vi inget dokument på att det verkligen är så.

 

Är det någon som vet vart man kan få tag på regler hur ett e-postmeddelande skall sättas upp?

 

[Cecilia]

Nu är jag ingen specialist, men en googling ger detta:

destination =  "To"          ":" 1#address  ; Primary
                /  "Resent-To"   ":" 1#address
                /  "cc"          ":" 1#address  ; Secondary
                /  "Resent-cc"   ":" 1#address
                /  "bcc"         ":"  #address  ; Blind carbon
                /  "Resent-bcc"  ":"  #address

http://www.faqs.org/rfcs/rfc822.html

där följande ger hur / ska tolkas

2.2.  RULE1 / RULE2:  ALTERNATIVES

         Elements separated by slash ("/") are alternatives.   There-
    fore "foo / bar" will accept foo or bar.

så jag kan inte se att To skulle krävas.

 

[fhe]

Vi anser att det tillhör epoststandard att skriva en To: mottagare och inte bara en Bcc: mottagare, men tyvärr har vi inget dokument på att det verkligen är så.

Något sådant krav finns inte (precis som Cecilia tolkar ut av rfc822).

 

Jag föreslår att ni skaffar ett riktigt spamfilter istället för att hitta på egna regler som ni tycker verkar vettiga. Det ökar nästan helt säkert träffsäkerheten och minskar garanterat risken för sådana fel du beskriver.

 

SpamAssassin är förmodligen det bästa som går att hitta och det är gratis, den går att plugga in i nästan allt som finns.

http://spamassassin.apache.org/

 

[lizardKng]

Lite OT kanske men är det inte RFC 2822 som gäller numera?

 

"Obsoletes: 822"

 

http://www.ietf.org/rfc/rfc2822.txt

 

Där finns en diskussion runt hanteringen av Bcc under "security considerations". Den säger inte att man inte får ha enbart Bcc men det får en del konsekvenser om man enbart har Bcc och dessa konsekvenser kanske man kan tolka som att det tillhör "god sed" eller nåt sånt att inte ha enbart Bcc.

 

[fhe]

Lite OT kanske men är det inte RFC 2822 som gäller numera?

Gäller och gäller. Förvisso är 2822 tydligare när den förklarar BCC men det gäller främst tolkningsskillnader om vad man ska göra med fältet när det finns (stycke 3.6.3), det är fortfarande 0 som är satt som minsta antal TO-fält.

 

men det får en del konsekvenser om man enbart har Bcc och dessa konsekvenser kanske man kan tolka som att det tillhör "god sed" eller nåt sånt att inte ha enbart Bcc.

Då tror jag faktiskt att man tolkar fel eller i vart fall för fritt.