All of lore.kernel.org
 help / color / mirror / Atom feed
* [mlmmj] Duplicate mail
@ 2013-11-28 13:51 Paul Fariello
  2013-11-28 18:19 ` Richard Mortimer
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Paul Fariello @ 2013-11-28 13:51 UTC (permalink / raw)
  To: mlmmj

Hi all,

I may be wrong but mlmmj don't seems to ignore subscribers that already are in "cc" or "to" headers.
This end up with user complaining about duplicate mail.

Is there a way to avoid this behavior ? Either by tweaking customheaders, by
using a configuration I may have missed, by patching ?


Regards,

-- 
Paul Fariello


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [mlmmj] Duplicate mail
  2013-11-28 13:51 [mlmmj] Duplicate mail Paul Fariello
@ 2013-11-28 18:19 ` Richard Mortimer
  2013-11-28 21:03 ` Ben Schmidt
  2013-12-02  6:52 ` G Stansfield
  2 siblings, 0 replies; 4+ messages in thread
From: Richard Mortimer @ 2013-11-28 18:19 UTC (permalink / raw)
  To: mlmmj

Hi,

On 28/11/2013 13:51, Paul Fariello wrote:
> Hi all,
>
> I may be wrong but mlmmj don't seems to ignore subscribers that already are in "cc" or "to" headers.
> This end up with user complaining about duplicate mail.
This isn't a problem that can be solved in general. The visible "cc" and 
"to" headers are not necessarily what was used as the envelope addresses 
to deliver to. There may also be "bcc" or (non-mlmmj) aliases used in 
the visible headers.

By the time that the mail gets to mlmmj any original destinations will 
already have been lost in intermediate mailservers so at best you are 
going to be able to paper over the cracks with a solution that will work 
in some (most maybe) cases but will fail in others and either the mail 
will get lost or delivered twice.

>
> Is there a way to avoid this behavior ? Either by tweaking customheaders, by
> using a configuration I may have missed, by patching ?
>
Sorry. I don't have a ready answer for that.

The only way that I know is to filter on MessageID on the receiving 
server. The cyrus mail suite will do that but obviously that relies on 
the receiver's ISP which you will not be able to fix. Oh and it does in 
theory filter out any messages that errorneously have duplicate 
MessageID fields but that tends to be spam in my experience so no big loss!

Regards

Richard


>
> Regards,
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [mlmmj] Duplicate mail
  2013-11-28 13:51 [mlmmj] Duplicate mail Paul Fariello
  2013-11-28 18:19 ` Richard Mortimer
@ 2013-11-28 21:03 ` Ben Schmidt
  2013-12-02  6:52 ` G Stansfield
  2 siblings, 0 replies; 4+ messages in thread
From: Ben Schmidt @ 2013-11-28 21:03 UTC (permalink / raw)
  To: mlmmj

On 29/11/13 5:19 AM, Richard Mortimer wrote:
> On 28/11/2013 13:51, Paul Fariello wrote:
>> I may be wrong but mlmmj don't seems to ignore subscribers that
>> already are in "cc" or "to" headers. This end up with user
>> complaining about duplicate mail.
...
>> Is there a way to avoid this behavior ? Either by tweaking
>> customheaders, by using a configuration I may have missed, by
>> patching ?
>>
> Sorry. I don't have a ready answer for that.
>
> The only way that I know is to filter on MessageID on the receiving
> server. The cyrus mail suite will do that but obviously that relies on
> the receiver's ISP which you will not be able to fix. Oh and it does
> in theory filter out any messages that errorneously have duplicate
> MessageID fields but that tends to be spam in my experience so no big
> loss!

I agree it is best to deal with this at the receiving end if possible.

That said, I suppose this is similar to the "notmetoo" functionality,
and perhaps "notmetoo" could be extended to cover these cases, too, i.e.
ignore "to" and "cc" addresses as well as the "from" one when
distributing posts. It shouldn't be too hard (I wrote the notmetoo
functionality, so am fairly familiar with it.)

Open an enhancement request on the bug tracker and/or write a patch for
it if you like.

Smiles,

Ben.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [mlmmj] Duplicate mail
  2013-11-28 13:51 [mlmmj] Duplicate mail Paul Fariello
  2013-11-28 18:19 ` Richard Mortimer
  2013-11-28 21:03 ` Ben Schmidt
@ 2013-12-02  6:52 ` G Stansfield
  2 siblings, 0 replies; 4+ messages in thread
From: G Stansfield @ 2013-12-02  6:52 UTC (permalink / raw)
  To: mlmmj

On 28-Nov-13 8:19 PM, Richard Mortimer wrote:
> Hi,
>
> On 28/11/2013 13:51, Paul Fariello wrote:
>> Hi all,
>>
>> I may be wrong but mlmmj don't seems to ignore subscribers that
>> already are in "cc" or "to" headers.
>> This end up with user complaining about duplicate mail.
> This isn't a problem that can be solved in general. The visible "cc" and
> "to" headers are not necessarily what was used as the envelope addresses
> to deliver to. There may also be "bcc" or (non-mlmmj) aliases used in
> the visible headers.
>
> By the time that the mail gets to mlmmj any original destinations will
> already have been lost in intermediate mailservers so at best you are
> going to be able to paper over the cracks with a solution that will work
> in some (most maybe) cases but will fail in others and either the mail
> will get lost or delivered twice.
>
>>
>> Is there a way to avoid this behavior ? Either by tweaking
>> customheaders, by
>> using a configuration I may have missed, by patching ?
>>
> Sorry. I don't have a ready answer for that.
>
> The only way that I know is to filter on MessageID on the receiving
> server. The cyrus mail suite will do that but obviously that relies on
> the receiver's ISP which you will not be able to fix. Oh and it does in
> theory filter out any messages that errorneously have duplicate
> MessageID fields but that tends to be spam in my experience so no big loss!
>
> Regards
>
> Richard
>
>
>>
>> Regards,
>>
>
Hi all!
Just adding a bit about my experience with duplicate mails, Bcc and 
MessageID that is not mlmmj specific but is 'real world' pain in the ... 
! [My setup is using OpenSUSE to fetchmail / procmail and place mail for 
local users to collect on a LAN with Windows machines.]

Let fred@gmail.com send a mail To:Jack@myisp and Bcc:Jill@myisp where 
both Jack and Jill are aliases and the mails are delivered to the same 
POP3 box at @myisp for collection and local delivery.

gmail sends two mails, both with identical MessageID - so letting 
anything reject duplicate mails based on MessageID results in a 
non-delivery to one recipient.

The mail Bcc:Jill@myisp has the envelope Delivered-To:jill@myisp and I 
have to check that for delivery. Unfortunately, it also has a valid 
To:Jack@myisp line. So the way / sequence of checking the envelope for 
delivery *beyond To: and Cc:* matters to avoid duplicate mails. If this 
is not done correctly then one recipient receives multiple deliveries.

Just to complicate matters, not all mailer systems are set up to handle 
Bcc: the way gmail does ..... and I give up!

So I agree with Richard - hopefully get "a solution that will work in 
some (most maybe) cases".

Regards,
Geoff


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-12-02  6:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-28 13:51 [mlmmj] Duplicate mail Paul Fariello
2013-11-28 18:19 ` Richard Mortimer
2013-11-28 21:03 ` Ben Schmidt
2013-12-02  6:52 ` G Stansfield

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.