Topic: cc'd mail recieved many times

[gordonjames]

Hello ,

We have a 7.1 server and when an external person e-mails one of us with few users in the cc field or multiple users in the to field , we will recieve the mail as many times as there are names in the to or cc fields.

Below is a log I sent from my external (private) mail to the company , I hade me in the to fielsd and two others in the cc box , We all recieved the mail 3 times.

This only happens when the mail is from outside of the company.

1228986348.405990500 qp 5640: to=local.alias-localdelivery-gavin@rebelsafetygear.com, uid=453, ddelay=0.031051, xdelay=0.024329, stat=Sent (forward:_qp_5643/did_0+0+1/)
1228986348.405999500 qp 5640: to=local.alias-localdelivery-billy@rebelsafetygear.com, uid=453, ddelay=0.031060, xdelay=0.020810, stat=Sent (forward:_qp_5646/did_0+0+1/)
1228986348.406173500 qp 5640: to=local.alias-localdelivery-kim@rebelsafetygear.com, uid=453, ddelay=0.031234, xdelay=0.017703, stat=Sent (forward:_qp_5649/did_0+0+1/)
1228986348.406180500 qp 5640: from=<hulleys@icon.co.za>, uid=453, size=3058, nrcpts=3, deferrals=0, qtime=0.031241
1228986348.429289500 qp 5643: to=local.gavin@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.029415, xdelay=0.023310, stat=Sent (did_1+0+0/)
1228986348.522003500 qp 5643: from=<hulleys@icon.co.za>, uid=400, size=3186, nrcpts=1, deferrals=0, qtime=0.122129
1228986348.522138500 qp 5646: to=local.billy@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.115725, xdelay=0.092859, stat=Sent (did_1+0+0/)
1228986348.522604500 qp 5646: from=<hulleys@icon.co.za>, uid=400, size=3186, nrcpts=1, deferrals=0, qtime=0.116191
1228986348.615094500 qp 5649: to=local.kim@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.122067, xdelay=0.092692, stat=Sent (did_1+0+0/)
1228986348.615103500 qp 5649: from=<hulleys@icon.co.za>, uid=400, size=3184, nrcpts=1, deferrals=0, qtime=0.122076
1228986350.181820500 qp 5657: to=local.alias-localdelivery-gavin@rebelsafetygear.com, uid=453, ddelay=0.031109, xdelay=0.024268, stat=Sent (forward:_qp_5660/did_0+0+1/)
1228986350.181827500 qp 5657: to=local.alias-localdelivery-billy@rebelsafetygear.com, uid=453, ddelay=0.031116, xdelay=0.024266, stat=Sent (forward:_qp_5663/did_0+0+1/)
1228986350.181834500 qp 5657: to=local.alias-localdelivery-kim@rebelsafetygear.com, uid=453, ddelay=0.031123, xdelay=0.020923, stat=Sent (forward:_qp_5666/did_0+0+1/)
1228986350.181851500 qp 5657: from=<hulleys@icon.co.za>, uid=453, size=3060, nrcpts=3, deferrals=0, qtime=0.031140
1228986350.190929500 qp 5660: to=local.gavin@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.014444, xdelay=0.009118, stat=Sent (did_1+0+0/)
1228986350.198151500 qp 5660: from=<hulleys@icon.co.za>, uid=400, size=3188, nrcpts=1, deferrals=0, qtime=0.021666
1228986350.198400500 qp 5663: to=local.billy@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.016322, xdelay=0.007480, stat=Sent (did_1+0+0/)
1228986350.198415500 qp 5663: from=<hulleys@icon.co.za>, uid=400, size=3188, nrcpts=1, deferrals=0, qtime=0.016337
1228986350.203005500 qp 5666: to=local.kim@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.012065, xdelay=0.004598, stat=Sent (did_1+0+0/)
1228986350.203014500 qp 5666: from=<hulleys@icon.co.za>, uid=400, size=3186, nrcpts=1, deferrals=0, qtime=0.012074
1228986352.026717500 qp 5674: to=local.alias-localdelivery-gavin@rebelsafetygear.com, uid=453, ddelay=0.029273, xdelay=0.023546, stat=Sent (forward:_qp_5677/did_0+0+1/)
1228986352.026724500 qp 5674: to=local.alias-localdelivery-billy@rebelsafetygear.com, uid=453, ddelay=0.029280, xdelay=0.020042, stat=Sent (forward:_qp_5680/did_0+0+1/)
1228986352.026731500 qp 5674: to=local.alias-localdelivery-kim@rebelsafetygear.com, uid=453, ddelay=0.029287, xdelay=0.019832, stat=Sent (forward:_qp_5683/did_0+0+1/)
1228986352.026767500 qp 5674: from=<hulleys@icon.co.za>, uid=453, size=3059, nrcpts=3, deferrals=0, qtime=0.029323
1228986352.034721500 qp 5677: to=local.gavin@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.013956, xdelay=0.008014, stat=Sent (did_1+0+0/)
1228986352.042528500 qp 5677: from=<hulleys@icon.co.za>, uid=400, size=3187, nrcpts=1, deferrals=0, qtime=0.021763
1228986352.042776500 qp 5680: to=local.billy@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.015778, xdelay=0.008065, stat=Sent (did_1+0+0/)
1228986352.042791500 qp 5680: from=<hulleys@icon.co.za>, uid=400, size=3187, nrcpts=1, deferrals=0, qtime=0.015793
1228986352.058631500 qp 5683: to=local.kim@rebelsvr.rebelsafetygear.com, uid=400, ddelay=0.023900, xdelay=0.015847, stat=Sent (did_1+0+0/)
1228986352.058640500 qp 5683: from=<hulleys@icon.co.za>, uid=400, size=3185, nrcpts=1, deferrals=0, qtime=0.023909
End of Report
--------------------------------------------------------------------------------
SME Server 7.1

[CharlieBrady]

We have a 7.1 server ...

You should have upgraded.

and when an external person e-mails one of us with few users in the cc field or multiple users in the to field , we will recieve the mail as many times as there are names in the to or cc fields.

This is most likely because you are using multidrop email (which you should avoid if possible) and you don't have a suitable "sort header" configured. I can't tell you what header to sort on, because it depends on your ISP's mail server configuration.

[aussierob]

This is most likely because you are using multidrop email (which you should avoid if possible)

Hi Charlie,
I wonder if you could help me...

1. why should one not use multidrop?

2. I fetch emails for my whole domain from a single username with my ISP:
if I dont mutidrop, but change it to SMTP, the screen says username/password are for multidrop only,
so how is email fetched?

I suspect these questions may seem quite ignorant to you, but a reply would be appreciated,
as my sort by for multidrop is not letting Bcc through.
So rather than juggle that I thought I would take your advice to not-multidrop

kind regards
Robert

[janet]

aussierob

2. I fetch emails for my whole domain from a single username with my ISP:
if I dont mutidrop, but change it to SMTP, the screen says username/password are for multidrop only,
so how is email fetched?

Assuming I understand your question correctly.
 
You will need to change external MX records so that all mail for your domain points at your SME server IP rather than being delivered to your ISP's single account.
The email will be delivered to each user on the SME server via the SME servers mail server functionality.
It would function as a normal smtp mail server, no need to fetch mail anymore.

[aussierob]

aussierob

Assuming I understand your question correctly.
 
You will need to change external MX records so that all mail for your domain points at your SME server IP rather than being delivered to your ISP's single account.
The email will be delivered to each user on the SME server via the SME servers mail server functionality.
It would function as a normal smtp mail server, no need to fetch mail anymore.

Ah thats what I thought ! thanks Mary - it is not a static IP, so I cannot do that.
I will have to stick with multidrop and consider a different 'sort' option as Deliver-To is dropping Bcc inbound emails.

Thanks again for your kind and as always helpful information.
Robert

[janet]

aussierob

Depending how mission critical your mission is, you can run a mail server on a dynamic IP connection using a dynamic updater client to update the IP.
Most dynamic IPs do not change very often (depending on your situation & ISP of course) so the likelihood of mail going astray at the time the IP changes is minimal.
Gordon Rowell made a good post a while back about the cons of using a mail server on a dynamic IP connection.
If your mission is critical enough, get a static IP. Even cheap ADSL2+ these days give static IPs.

[Stefano]

Ah thats what I thought ! thanks Mary - it is not a static IP, so I cannot do that.
I will have to stick with multidrop and consider a different 'sort' option as Deliver-To is dropping Bcc inbound emails.

this is not true
if your router support dyndns (example), you can configure your DNS to have a cname record (for example mail.yourdomain.tld) pointing to your dyndns host (es. yourdomain.dyndns.org) and then pointing your mx record to mail.yourdomain.tld

you're done
HTH

[aussierob]

this is not true
if your router support dyndns (example), you can configure your DNS to have a cname record (for example mail.yourdomain.tld) pointing to your dyndns host (es. yourdomain.dyndns.org) and then pointing your mx record to mail.yourdomain.tld

you're done
HTH

WOW there are  very clever and generously helpful SME people around the world !
I will look at this -
 grazie mille Roberto

[cactus]

this is not true
if your router support dyndns (example), you can configure your DNS to have a cname record (for example mail.yourdomain.tld) pointing to your dyndns host (es. yourdomain.dyndns.org) and then pointing your mx record to mail.yourdomain.tld

you're done
HTH

But that still does not eliminate the risk of loosing mail in the events of IP changes (especially when there are issues and the window between the change and the dyndns being updated is long).

[Stefano]

But that still does not eliminate the risk of loosing mail in the events of IP changes (especially when there are issues and the window between the change and the dyndns being updated is long).

I don't think so

dyndns ttl is about 60 sec IIRC and sending server should keep mails in queue and retry

[CharlieBrady]

I don't think so

dyndns ttl is about 60 sec IIRC and sending server should keep mails in queue and retry

You're missing something important Stefano. Someone else may take the IP address while you are not using it (e.g. when your server is down). dyndns will still point to the IP address you last used. The new server at your old IP address may either keep or 5XX reject *your* mail. Neither is a good thing.

[Stefano]

You're missing something important Stefano. Someone else may take the IP address while you are not using it (e.g. when your server is down). dyndns will still point to the IP address you last used. The new server at your old IP address may either keep or 5XX reject *your* mail. Neither is a good thing.

since we are not talking about a home server, I hope/guess OP will work to avoid downtime..

[CharlieBrady]

since we are not talking about a home server, I hope/guess OP will work to avoid downtime..

Downtime is usually beyond our control.

[aussierob]

aussierob

Assuming I understand your question correctly.
 
You will need to change external MX records so that all mail for your domain points at your SME server IP rather than being delivered to your ISP's single account.
The email will be delivered to each user on the SME server via the SME servers mail server functionality.
It would function as a normal smtp mail server, no need to fetch mail anymore.

The sme server-manager says "multi-drop mode is the only option available when the server is configured in private server and gateway mode". So even if I get a static-IP I am still stuck.

Currently I use 'sort by' 'Delivered-To', but the Bcc has not got this. The email source shows nothing to sort by, and after googling it seems only an 'envelope' contains the who-to-go-to details.
The mail does not deliver to the 'unknown user': it seems to  just disappear (or rather not appear).
When I try this on Win7 Thunderbird, a Bcc arrives.
Surely there must be a solution to this. Would a blank sort by work?
TIA for any help to my ignorance.
Robert

[janet]

aussierob

The sme server-manager says "multi-drop mode is the only option available when the server is configured in private server and gateway mode". So even if I get a static-IP I am still stuck.

Select Server and gateway or Server-only, rather than Private server and gateway.
In Private server and gateway mode all external services are disabled, so you cannot run a mail or web server etc, your server cannot be seen from the Internet. Not a very useful mode/role if you want to run a mail server that talks to other external mail servers.

The usual modes are Server and gateway or Server-only, and the mail server is externally accessible in both of those modes (with appropriate port forwarding on your router when in server only mode).

It is really simple to use SME as a mail server, ideally with a static IP connection although it will still function with a dynamic IP connection with the slight possibility of mail going astray.

This possibility only occurs when the dynamic IP changes and during the time it takes your external DNS/MX records to update, and it just happens that mail is sent to your mail server and IF your old IP has also been allocated to another user who also runs a mail server, then the other server might get your mail. As soon as the DNS records are updated (typically TTL is 60 seconds), mail should be delivered correctly. We are talking about a very narrow window of opportunity for things to go wrong, coupled with the fact that someone else needs to be using a mail server who is also using a dynamic IP and uses the same ISP as you do (gets one of the unused IP's from the ISP's pool).
In my books the percentage chances of problems are very small. It also depends how often your IP changes.

I have ran a mail server on a dynamic IP for a few years and never lost mail (AFAIK), although it is a very low volume mail server and not mission critical.