meerdere BCC emails komen niet aan

[Anoniem: 404753]

Hallo tweakers,
ik moet zeggen met normaal emailen van en naar transip gaat prima ..

maar ik heb een vreemd issue...

Wat ik vandaag merk is dat als ik meerdere BCC addressen een email stuur ( 2 of 3 ) deze niet aankomen op mijn VPS bij TransIP.
Ik heb al even zitten neuzen in de headers van de ontvangen email.
Wat er mist is een "for" of "to" in de headers van deze emails.
daardoor kunnen de emails niet behandeld worden en worden deze retour afzender gestuurd.

Hebben hier meerdere mensen last van ?

Ik email bijvoorbeeld vanaf de smtp server van ziggo ( webmail ) naar deze transip domein/vps.
Dit gaat dus NIET goed.

Het vreemde is wel .. als ik een email vanaf mijn gmail adres stuur naar dit transip domein deze WEL aankomen . In de headers van dit emailtje staan netjes de "for" en/of "to" addressen.


ik hoop dat iemand mij mee kan helpen en/of meerdere mensen dit issue hebben zodat we snel naar een oplossing kunnen gaan kijken.

vooral nieuwsbrieven e.d. worden met hele lijsten in de BCC verstuurd. Deze komen dus niet aan !!!

Alvast dank voor het meedenken
m

...

[DJMaze]

Heb ik geen last van met mijn CentOS 8 VPS die postfix en rspamd gebruikt.
De vraag is dus: wat gebruik jij als SMTP

[hcQd]

De adressen in de BCC staan normaal nooit in de headers, dat is juist het idee daarachter.

[Anoniem: 404753]

*Knip*, het op de man spelen is niet nodig.

ik stuur een email met 2 of meer mensen in de BCC vanaf een ziggo ( kan ook vanaf kpn, transip ) smtp server richting mijn VPS.
email versturen gaat prima !
Dan open ik de webmail van transip en zie dan netjes ( zoals mijn voorbeeld ) 2 emailtjes in de webmail van transip staan.
Als ik één van deze emailtjes open en kijk in de headers zie ik geen "TO" of "FOR" staan.

Mijn email server ( kerio ) kan dus niet zien voor wie deze emails zijn dus deze gaan retour afzender.
Dit is dus GEEN kerio probleem.
In de email die in de webmail omgeving van transip staan staat dus al geen "to" of "for" .
Vroeger stond er bij trans ip in deze header een "X-TransIP-Original_to" maar deze staat er dus niet meer in.

zoals ik al zei ... de emails komen netjes aan maar geen geaddreseede in de email.

ik gebruik om te versturen ziggo SMTP , maar kpn en/of transip zelf heeft daar ook issues mee.
mijn vps gebruikt vps.transip.email als smtp

ik hoop dat het nu wat helderder is..
m

[ Voor 3% gewijzigd door MisteRMeesteR op 17-02-2020 10:17 ]

[DutchKel]

En als je een andere smtp server gebruikt, gaat het dan ook fout? Gmail oid?

[Anoniem: 404753]

@DutchKel
Dat is nou het leuke ...als ik een email verstuur vanuit gmail of yahoo gaat het wel goed.

als ik dus een email stuur vanaf mijn gmail account met dus weer 2 mensen in de BCC dan komen er weer netjes 2 emails aan bij transip.
als ik dan één van deze 2 email de headers open zie ik netjes een "to" of "for" als geaddresseerde staan.
dan gaat het dus wel goed.

....vreemd...

dankje wel voor het meedenken ..

ik denk trouwens dat veel meer mensen hier last van moeten hebben ..maar ja.. dat komt later wel
m

[ Voor 14% gewijzigd door Anoniem: 404753 op 17-02-2020 07:34 ]

[Sabbi]

BCC staat nooit in de headers, en dat hoeft ook niet, want in de smtp-sessie tussen de verzendende mailserver en jouw mailserver wordt al meegegeven voor wie het bericht is met het RECEIPT TO commando
Het probleem zit hem in je smtp server die kennelijk niet weet welke e-mailadressen hij bedient.

[Anoniem: 404753]

@Sabbi
dat klopt maar dan zouden er wel in de headers "iets" moeten staan aan wie deze email gericht is
en dat staat er dus niet ..

er staat dus geen geaddresseerde .. dus niets bij "TO:" of "FOR" de hele regel is er niet.
het vreemde is dus wel ..als ik vanuit gmail de email verstuur dan wel.

transip naat transip gaat niet goed, ook ziggo naar transip gaat niet goed
yahoo en gmail naar transip gaat wel goed

dan zie ik netjes in mijn email een geaddresseerde staan ... dus een TO of FOR email adres

dank voor het meedenken
m

p.s.
wat me te binnen schoot..
doe maar eens een test van een ziggo smtp server ( of kpn ) met 2 mensen in de BCC naar een transip domein ( liefst met VPS )
kijk dan in de header .. je zal geen geaddreseerde zien staan.

m

[ Voor 17% gewijzigd door Anoniem: 404753 op 17-02-2020 07:54 ]

[Sabbi]

@Anoniem: 404753 Het punt is dat email-headers niet gebruikt worden om te bepalen voor wie de mail is, en dat je dus daar niet naar kan/hoeft te kijken.

Om het op z'n noobs uit te leggen , de headers zijn als het briefhoofd wat je bovenaan je A4tje op een brief hebt. Handig voor je eigen archief, maar de postbode kijkt alleen naar het adres wat buiten op de envelop staat. Jij als eindgebruiker krijgt de smtp-'envelop' geeneens te zien, maar de mailserver (postbode) wel:

code:

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.com
S: 250 smtp.example.com, I am glad to meet you
C: MAIL FROM:<[e-mail]>
S: 250 Ok
C: RCPT TO:<[e-mail]>
S: 250 Ok
C: RCPT TO:<[e-mail]>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <[e-mail]>
C: To: Alice Example <[e-mail]>
C: Cc: [e-mail]
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C: 
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

De adressen die in de header staan kunnen anders zijn of zelf helemaal afwezig zijn, en toch zal de mail aankomen of gebounced kunnen worden omdat in het SMTP bericht zelf altijd MAIL FROM en RCPT TO staat. Dat zie je bijvoorbeeld bij BCCs (geen to:) en bij mailinglists (from: adres wijkt af van MAIL FROM)

[Anoniem: 404753]

niet helemaal met je eens ...
want als ik email vanaf gmail stuur zie ik ze namelijk wel
er worden ( in dit voorbeeld ) 2 emailtjes in mijn webmail.transip.nl inbox gezet waar ik gewoon de "TO" zie staan.

doe ik dit vanuit een ziggo smtp server dan krijg ik ook netjes 2 emails in mijn webmail.transip.nl inbox maar ZONDER de "TO" ... als mijn kerio mailserver de emails ophaalt weet kerio ook niet aan wie ze gericht zijn .. Dat is dus helemaal juist want er staat niets in de headers / source van dat emailtje.

email gaat dan dus retour.


wat ik al zei :
Vroeger stond er bij trans ip in deze header een "X-TransIP-Original_to" maar deze staat er dus niet meer in.
toen ging het wel goed.

m

[ Voor 12% gewijzigd door Anoniem: 404753 op 17-02-2020 10:11 ]

[Blokker_1999]

In geval van BCC adressen horen de ontvangers die in BCC staan niet voor te komen in de headers. Dat is het hele punt van die blinde kopie. Staan ze wel in de headers dan zijn ze niet meer blind. Het kan zijn dat bepaalde mailservers, wanneer zij de mail krijgen van de mail client, de BCC ontvangers 1 voor 1 een kopie toesturen met telkens hun adres in het FOR field, maar zeker NOOIT in het TO field aangezien dit gereserveerd is voor de mensen die origineel in dat TO veld stonden toen je de mail verzonden hebt.

Het feit dat het header field X-TrainsIP-Original_to noemt toont aan waar het vandaan komt. X- betekend dat het een niet standaard veld betreft, TransIP toont aan dat het werd toegevoegd door TransIP zelf. TransIP heeft zijn server software aangepast om dit veld niet langer weer te geven in de uiteindelijke email.

[Anoniem: 404753]

@Blokker_1999 ok top dank je voor je reactie en je verduidelijking

vervelend is nu dus wel dat de email dus niet aankomt en er geen adres staat in het "for" veld ( source email )

van een bulk email met b.v. 10 email adressen in de BCC zal er dus geen één aankomen. alle 10 emails worden retour gestuurd omdat er dus geen email adres staat bij het "FOR" veld.

ik heb inmiddels een ticket ingeschoten bij transip... ik ben benieuwd
m

[Illusion]

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 12:25:
@Blokker_1999 ok top dank je voor je reactie en je verduidelijking

vervelend is nu dus wel dat de email dus niet aankomt en er geen adres staat in het "for" veld ( source email )

van een bulk email met b.v. 10 email adressen in de BCC zal er dus geen één aankomen. alle 10 emails worden retour gestuurd omdat er dus geen email adres staat bij het "FOR" veld.

ik heb inmiddels een ticket ingeschoten bij transip... ik ben benieuwd
m

Bcc mails zonder een to, zijn per definitie een raar iets. Je stuurt mensen een blinde kopie (bcc) van een mail die naar niemand gaat.

Gmail gooit alle mails waar ik in de bcc sta, maar met een lege “to” standaard in de spamfolder. Ook niet altijd handig.

Pragmatische oplossing: als je een bcc-mail verstuurd, zet jezelf in de to. Heb je 90% van je problemen al opgelost.

[Blokker_1999]

Maar zoals @Sabbi aangeeft kan dat de oorzaak niet zijn.

Jij stuurt een email van je mail client (ongeacht of dit webmail of een fat client is). Deze komt aan op je mailserver, oftewel MTA. De MTA kijkt naar de ontvanger. Dit mag zelfs enkel en alleen een BCC zijn. De MTA gaat via DNS opzoeken welke server hij moet contacteren om deze email af te leveren en neemt contact op met die server. Daar speelt zich af wat Sabbi heeft gepost. De server maakt zich bekend met een EHLO, zegt dan wie de afzender is, wie de bedoelde ontvanger is op die server en geeft dan aan data te willen afleveren. Die data is gewoon dat. data die in de mailbox van de ontvanger moet komen. En het is aan de mail software van de ontvanger om die data te verwerken.

Het TO veld in de header van de email is gereserveerd voor de mensen aan wie je de mail hebt geaddresseerd, dus niet de mensen in Cc of BCc. Een FOR veld bestaat voor zover ik weet niet. Tenzij je die tekst bedoeld die een server toevoegt tenzij je iets bedoeld zoals deze:

Received: from mail-sor-f69.google.com (mail-sor-f69.google.com. [209.85.220.69])
by mx.google.com with SMTPS id q1sor102524otc.1.2020.02.17.03.29.13
for <[e-mail]>
(Google Transport Security);
Mon, 17 Feb 2020 03:29:13 -0800 (PST)

Maar die dienen alleen maar om aan te geven wat er op eventueel tussenliggende servers gebeurd. Bijvoorbeeld een distributielijst die uit elkaar gehaald wordt. Kan je dan perfect nagaan welke server verantwoordelijk was om die distributielijst om te zetten in onafhankelijke ontvangers.

[Anoniem: 404753]

@Blokker_1999
juist ! die ..

Received: from mail-sor-f69.google.com (mail-sor-f69.google.com. [209.85.220.69])
by mx.google.com with SMTPS id q1sor102524otc.1.2020.02.17.03.29.13
for <[e-mail]>
(Google Transport Security);
Mon, 17 Feb 2020 03:29:13 -0800 (PST)

deze komt netjes mee als ik vanuit gmail een email stuur ... mijn kerio mail server weet dan ook netjes dat deze ( zoals jou voorbeeld ) naar de gebruiker moet die bij "for" staat.
mijn sorting rule in kerio staat ook op "recieved"

nu is dus het geval dat bij b.v. ziggo en/of kpn deze for regel er dus NIET is en ik dus ook niet kan zien aan wie deze email gericht is ... daarom gaat deze retour afzender.

dat is nou juist het issue wat ik heb.

trouwens dank voor het meedenken
m

[ Voor 3% gewijzigd door Anoniem: 404753 op 17-02-2020 12:45 . Reden: typos ]

[AlbertJP]

De naam die je zoekt is het RCPT TO commando in SMTP, wat geen mail-header is. Is het mogelijk om van je eigen server een transcript te krijgen van de SMTP-sessie zodat we kunnen zien wat de Ziggo/KPN server doet?

[Anoniem: 404753]

@AlbertJP
hier zitten geen eigen server bij .
nogmaals ik email vanaf de ziggo webmail naar de transip webmail interface.
eigen servers komen hier (nog) niet bij kijken.

van ziggo webmail naar transip webmail mist dus al deze for <[e-mail]> lijn.
bij webmail google ( gmail ) naar webmail transip zit deze regel er wel bij.

ik kan best een copy/paste doen van het Recieved blokje van de source van de email ... maar je zal zien dat deze regel mist.
Dat had ik al gevonden. Wat wil je nog meer dan ?
m

[DutchKel]

Maar komt de e-mail dan wel aan bij de webmail? Zo ja dan klopt het toch?

[Anoniem: 404753]

@DutchKel
ja maar zonder een geaddreseerde in de email
ik zie niets in de source van de email staan.

dus .. zoals ik al zei ... retour afzender omdat er geen geaddreseerde in staat

m

[AlbertJP]

Kun je de logs waarin je dit ziet gebeuren hier plakken?

Als de mailserver Postfix of Exim is, dan zou die wel een melding over een ongeldige RCPT TO moeten geven in de log. Wil graag weten hoe die er dan uit ziet, als je daarbij kunt.

[ Voor 14% gewijzigd door AlbertJP op 17-02-2020 14:46 ]

[Anoniem: 404753]

@AlbertJP
ik ben geen beheerder van de mailservers van ziggo en/of transip dus de logs kan ik je helaas niet sturen of hier plakken.
Ik kan alleen zien wat er in beide webmail servers (front end) gebeurt.

m

[DJMaze]

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 12:43:
Received: from mail-sor-f69.google.com (mail-sor-f69.google.com. [209.85.220.69])
by mx.google.com with SMTPS id q1sor102524otc.1.2020.02.17.03.29.13
for <[e-mail]>
(Google Transport Security);
Mon, 17 Feb 2020 03:29:13 -0800 (PST)

Heeft er niks mee te maken. Ik heb soms 20 van die Received regels. Het is een trace route.

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 14:31:
dus .. zoals ik al zei ... retour afzender omdat er geen geaddreseerde in staat

Dan zou de afzender een bounce melding moeten krijgen met de reden waarom TransIP je e-mail niet wil ontvangen.
En in deze hele discussie zie ik nergens waar jij de xx.xxx bounce code geeft.

Al met al wordt er hier dus geroeptoetert alsof er heel veel kennis is, maar wat simpele mailserver logs missen ook in de discussie.
Je hebt het over "mijn VPS bij TransIP" en vervolgens "mijn kerio mailserver" en dan opeens "hier zitten geen eigen server bij".
Dus waar heb je het over? Wees duidelijk?

Dus zoiets:

1. ik open de webmail van Ziggo
2. ik geef geen adres op in het 'To' veld
3. ik geef twee adressen op in het BCC veld
4. ik verstuur de e-mail
5. domein xxx.xx DNS MX staat ingesteld op mail.transip.nl
6. de e-mail komt niet in mijn inbox
7. de webmail van Ziggo heeft geen bounce bericht ontvangen
8. mijn server mail logs zien geen inkomende berichten van mail.transip.nl
9. ik heb aan transip deze stappen doorgegeven en wacht op antwoord

[Anoniem: 404753]

@DJMaze
ik ben al blij dat er mensen helpen !
Dank daarvoor .

Nogmaals ik kan geen logs van de mailservers van ziggo of transip meesturen omdat ik die niet heb !

verder ..wat ik dus doe

1. stuur vanuit de webmail omgeving van ziggo een email naar een transip domein
geen TO alleen 2 mensen in de BCC ( natuurlijk wel onderwerp en body )
2. email komt aan in de webmail omgeving van trans ip , sterker er komen 2 emailtjes in de transip webmail omgeving.
3. als ik de source bekijk van één van deze 2 emailtjes staat er geen geaddreseerde bij ... geen TO geen FOR ..niks ...

dat is het issue , meer niet ...
vroeger stond daar dus een X-transip-original-to in maar tegenwoordig dus niet meer

wat verder niet belangrijk is in dit verhaal...
heb ik een kerio mail server die met pop deze transip mailbox leeg lees elke X minuten.
zoals ik al zei omdat er in de source van de email geen geaddreseerde staat bij to of for ..zal kerio hem ook niet behandelen.

email wordt doot kerio terug gestuurd met email box bestaat niet. bounce email
Kerio doet dus netjes wat hij hoort te doen.

ik hoop dat het nu duidelijk is

ik heb ook al een ticket aangemaakt bij trans ip
want wat blijkt .. al mijn trans ip domeinen hebben hier last van.
m

[DJMaze]

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 15:01:
1. stuur vanuit de webmail omgeving van ziggo een email naar een transip domein
geen TO alleen 2 mensen in de BCC ( natuurlijk wel onderwerp en body )
2. email komt aan in de webmail omgeving van trans ip , sterker er komen 2 emailtjes in de transip webmail omgeving.

Super, nou weten we dat ze WEL aankomen.

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 15:01:
heb ik een kerio mail server die met pop deze transip mailbox leeg lees elke X minuten.
zoals ik al zei omdat er in de source van de email geen geaddreseerde staat bij to of for ..zal kerio hem ook niet behandelen.

Hier zit je probleem. De e-mail komt aan in de mailbox van TransIP zoals het hoort.
Dat de SMTP van TransIP geen "X-transip-original-to" header meer zet mag gewoon.
Ik ken bijna geen één SMTPD die zoiets doet (mijn servers sowieso niet).

Wat mijn postfix wel doet in de trace:

code:

Received: from server1.nl
    by server2.nl (Postfix) with ESMTP id 344D9A0075
    for <megasound@tweakers>; Mon, 17 Feb 2020 14:31:09 +0000 (UTC)

Dus kijk eens in de mail headers of er zo'n "Received" regel staat.
Zo ja, repareer Kerio om daar naar te kijken.
Zo nee: Kerio moet niet zeuren.

[Anoniem: 404753]

Nee helaas ,
hieronder de source van de email die ik vanaf ziggo webmail naar transip webmail stuur

deze email is voor ??? goed dat staat er dus NIET in
dat is precies het probleem

ter info
dit is dus een BCC email van ziggo naar transip


Return-Path: <[e-mail]>
Received: from mdaproxy2.mail.transip.nl ([10.103.8.132])
by mda33.mail.transip.io (Dovecot) with LMTP id SR1HNUKsSl4lIwAAGiDlzQ
; Mon, 17 Feb 2020 16:07:46 +0100
Received: from mx6.mail.transip.nl ([10.103.8.147])
by mdaproxy2.mail.transip.nl (Dovecot) with LMTP id ITEvNEKsSl7/QwAADLDEfg
; Mon, 17 Feb 2020 16:07:46 +0100
Received: from smtpq3.tb.mail.iss.as9143.net (smtpq3.tb.mail.iss.as9143.net [212.54.42.166])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mx6.mail.transip.nl (Postfix) with ESMTPS id 48LnR5360HzCqyC;
Mon, 17 Feb 2020 16:07:45 +0100 (CET)
Received: from [212.54.42.136] (helo=smtp12.tb.mail.iss.as9143.net)
by smtpq3.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
(envelope-from <[e-mail]>)
id 1j3hzt-0008KE-A4; Mon, 17 Feb 2020 16:07:45 +0100
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ziggo.nl;
s=202002corplgsmtpnl; h=Subject:From:Date:to;
bh=hMihF2ZTrpyEDOukfiRkGQ51v6DCI+3dyccNfMqTOsM=; b=FS9kzdYwaROUIcXvX6zT0yPgYb
ygGBTDXWsNgrU63DK2WIGyIDdV1VqkcLilChfEX+iJgkSrJWyqvWWmqtTgPYczDY5JVCM7BBqp45M
QIEJOzuETxGN71CfaLA5IzRHx2fA5iJqzNl5bR1PtoC8G6X315fiH/amygGOTqeKqFB//zcP3mqpe
yJQa0ysMgM9sAOZ6QMZiFhyiczGR/nWIaSEddoBAI1YuSiFzp0jf4BZdn8i+Hha61igNmefIYVuRA
XNAmAkXG2TMN2F+ufLFT/EF7kaJnswWZPwLH2V7r5miHZG3yqLS98AKSZOSMGEoBQCjQwBz03JZNu
4iRccLfw==;
Received: from outbound-5.tb.mail.iss.as9143.net ([212.54.41.168] helo=oxbe5.tb.mail.iss.local)
by smtp12.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1)
(envelope-from <[e-mail]>)
id 1j3hzt-0003dL-2o; Mon, 17 Feb 2020 16:07:45 +0100

[Anoniem: 404753]

extra info
dit is de source als ik naar 2 BCC email adressen stuur

Received: from outbound-5.tb.mail.iss.as9143.net ([212.54.41.168] helo=oxbe5.tb.mail.iss.local)
by smtp12.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1)
(envelope-from <[e-mail]>)
id 1j3iEF-0006Br-LB; Mon, 17 Feb 2020 16:22:35 +0100
Date: Mon, 17 Feb 2020 16:22:35 +0100 (CET)

dit is de source als ik naar 1 BCC email adres stuur

Received: from outbound-5.tb.mail.iss.as9143.net ([212.54.41.168] helo=oxbe5.tb.mail.iss.local)
by smtp12.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1)
(envelope-from <[e-mail]>)
id 1j3iDe-0005kB-Es
for [e-mail]; Mon, 17 Feb 2020 16:21:58 +0100
Date: Mon, 17 Feb 2020 16:21:58 +0100 (CET)

[AlbertJP]

Dat ziet eruit alsof Exim de 'for' verbergt als er 2 of meer verschillende RCPT TO commando's binnenkomen.
Als de server geen RCTP TO had gestuurd, had Exim die mail in het geheel niet geaccepteerd.

Wat Exim in de headers van de mail schrijft, is niet heel relevant voor volgende mailservers. Volgende mailservers lezen de Received header in het algemeen niet, die wordt gewoon in zijn geheel gekopieerd. De volgende server leest wel de RCPT TO commando's via SMTP en ik heb geen reden om aan te nemen dat dat niet goed staat.

Nogmaals, als er géén bounce komt (de envelope-from staat goed ingesteld, dus bounces moeten het doen) dan ziet dit eruit als een probleem bij Kerio, zoals @DJMaze al zei.

[ Voor 7% gewijzigd door AlbertJP op 17-02-2020 16:43 ]

[mrdemc]

Even ter verduidelijking, zover ik het begrijp is dit jouw opzet:

1. Verzendende mailserver is: Ziggo of Gmail
2. Ontvangende mailserver is: Standaard TransIP server met een catch-all mailbox
3. VPS betreft een Kerio installatie met daarin een POP3 Connector ingesteld waarbij de connector de catch-all mailbox uitleest om a.d.h.d. de mails te verdelen tussen de mailboxen die voor Kerio lokaal bekend zijn.

Mails vanuit de Ziggo mailserver komen wel aan in de catch-all, net als die van Gmail.
Maar de mails worden vervolgens opgehaald door Kerio, en door het gebrek aan een header waarin de ontvangende partij wordt benoemd in het geval van een BCC kan Kerio niets met de mails van Ziggo m.b.t. de routering naar de lokale mailboxen.

Het is normaal gedrag van een mailserver dat er geen vermelding wordt gemaakt van een BCC adres in de headers van de e-mail. Soms wil het ook nog wel eens de "Delivered-To" header plaatsen of aan de hand van een niet-standaard header "X-*", maar dat is een keuze van de beheerder van de ontvangende mailserver. De verzendende mailserver heeft daar in principe geen invloed op al zou het wel kunnen dat deze weggelaten wordt indien er wel een TO: header in staat, wat soms gebeurd bij e-mails zonder TO maar met BCC's (To: undisclosed-recipients:; krijg je dan vaak) en dat dit het verschil verklaart tussen mails van Ziggo en van Gmail.


Wat ik aanraad om te doen is om gewoon de service van Kerio te gebruiken voor het ontvangen van de e-mail en geen tussenliggende mailserver met POP3-connector.

[ Voor 7% gewijzigd door mrdemc op 17-02-2020 16:47 ]

[DutchKel]

Zoals al is gezegd is dit inderdaad gewenst gedrag en zal transip het (hopelijk) niet aanpassen. Het is volstrekt onwenselijk dat een bcc adres ergens in de headers wordt vermeld.

Ik zou echt niet willen dat mensen kunnen achterhalen wie ik in de bcc zet. Daarvoor zet ik ze bewust in de bcc, anders kon ik ze wel prima in het cc veld zetten.

Je kunt ook eens kijken naar een smtp relay.

[HenkEisDS]

Waarom gebruik je uberhaupt zo'n complexe oplossing voor het versturen van nieuwsbrieven? Waarom niet gewoon een 3rd party zoals mailchimp?

[mrdemc]

DutchKel schreef op maandag 17 februari 2020 @ 18:06:
Zoals al is gezegd is dit inderdaad gewenst gedrag en zal transip het (hopelijk) niet aanpassen. Het is volstrekt onwenselijk dat een bcc adres ergens in de headers wordt vermeld.

Ik zou echt niet willen dat mensen kunnen achterhalen wie ik in de bcc zet. Daarvoor zet ik ze bewust in de bcc, anders kon ik ze wel prima in het cc veld zetten.

Je kunt ook eens kijken naar een smtp relay.

Het gaat hier om de ontvangende server van de betreffende BCC. Dat geldt dus enkel voor de BCC die op dat moment de RCPT TO is en er is dus geen sprake van BCC adressen die inzichtelijk worden.

[DutchKel]

mrdemc schreef op maandag 17 februari 2020 @ 19:08:
[...]


Het gaat hier om de ontvangende server van de betreffende BCC. Dat geldt dus enkel voor de BCC die op dat moment de RCPT TO is en er is dus geen sprake van BCC adressen die inzichtelijk worden.

Dus jij denkt dat die e-mails nooit worden doorgestuurd? Want de headers worden daarin bij de meeste clients aangevuld ipv vervangen.

[Anoniem: 404753]

@mrdemc
u schreef:
Wat ik aanraad om te doen is om gewoon de service van Kerio te gebruiken voor het ontvangen van de e-mail en geen tussenliggende mailserver met POP3-connector.

dit willen we juist wel , we willen juist die fallback hebben en de pop connector blijven gebruiken
verder zat je helemaal goed met je verhaal.

issue nog steeds niet gevonden , ik blijf zoeken.
transip weet het namelijk ook niet .. wordt morgen hopelijk geholpen

allen dank voor jullie hulp

[ Voor 8% gewijzigd door Anoniem: 404753 op 17-02-2020 19:29 ]

[mrdemc]

DutchKel schreef op maandag 17 februari 2020 @ 19:25:
[...]

Dus jij denkt dat die e-mails nooit worden doorgestuurd? Want de headers worden daarin bij de meeste clients aangevuld ipv vervangen.

Bij het doorsturen zal dan alleen het adres van diegene die het doorstuurt te zien zijn.

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 19:28:
@mrdemc
u schreef:
Wat ik aanraad om te doen is om gewoon de service van Kerio te gebruiken voor het ontvangen van de e-mail en geen tussenliggende mailserver met POP3-connector.

dit willen we juist wel , we willen juist die fallback hebben en de pop connector blijven gebruiken
verder zat je helemaal goed met je verhaal.

issue nog steeds niet gevonden , ik blijf zoeken.
transip weet het namelijk ook niet .. wordt morgen hopelijk geholpen

allen dank voor jullie hulp

Dan zou het misschien handig zijn een eigen server op te zetten waarin je dit regelt als je die kennis hebt. Je zou dan een SMTP Relay kunnen opzetten waarin je direct doorstuurt naar de SMTP van Kerio waarbij je uiteraard alleen relayed naar jouw domein en geen open relay.

[ Voor 56% gewijzigd door mrdemc op 17-02-2020 20:07 ]

[DJMaze]

Anoniem: 404753 schreef op maandag 17 februari 2020 @ 16:25:
dit is de source als ik naar 2 BCC email adressen stuur

Received: from outbound-5.tb.mail.iss.as9143.net ([212.54.41.168] helo=oxbe5.tb.mail.iss.local)
by smtp12.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1)
(envelope-from <[e-mail]>)
id 1j3iEF-0006Br-LB; Mon, 17 Feb 2020 16:22:35 +0100
Date: Mon, 17 Feb 2020 16:22:35 +0100 (CET)

dit is de source als ik naar 1 BCC email adres stuur

Received: from outbound-5.tb.mail.iss.as9143.net ([212.54.41.168] helo=oxbe5.tb.mail.iss.local)
by smtp12.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1)
(envelope-from <[e-mail]>)
id 1j3iDe-0005kB-Es
for [e-mail]; Mon, 17 Feb 2020 16:21:58 +0100
Date: Mon, 17 Feb 2020 16:21:58 +0100 (CET)

Mijn postfix doet exact het zelfde.
Sterker nog, omdat ik een catch-all gebruik, wordt de e-mail maar 1x afgeleverd en niet 2x.
Scheelt toch dubbele mails