Mailing List Archive: exim: users

[EXIM] confirmation receptions

Index | Next | Previous | View Threaded

info at paraprueba

Jul 23, 2013, 12:25 PM

Post #1 of 17 (162 views)
Permalink

[EXIM] confirmation receptions

Hi, all.

You can configure the confirmation of receipt of an email in exim?
I need that the arrive mails requesting confirmation of receipt, the
response is sent to recipient

Sorry for my poor Inglish

Thanks.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jgh at wizmail

Jul 23, 2013, 1:01 PM

Post #2 of 17 (160 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On 23/07/13 20:25, info [at] paraprueba wrote:
> You can configure the confirmation of receipt of an email in exim?
> I need that the arrive mails requesting confirmation of receipt, the
> response is sent to recipient

That's not Exim's job. You're interested in what a Mail User Agent
(MUA) can do; Exim is an MTA (Mail Transmission Agent.
--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

eslist at ols

Jul 23, 2013, 11:24 PM

Post #3 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

Hi

There is a DSN patch for Exim (RFC 3461 SMTP Service Extension for
Delivery Status Notifications) at
http://sourceforge.net/projects/eximdsn/ , it's a confirmation of
delivery to the remote mta (not a user confirmation receipt) but may
help ... i wonder why this feature was never added to Exim

El 23/07/2013 21:25, info [at] paraprueba escribió:
> Hi, all.
>
> You can configure the confirmation of receipt of an email in exim?
> I need that the arrive mails requesting confirmation of receipt, the
> response is sent to recipient
>
> Sorry for my poor Inglish
>
> Thanks.
>
>

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

pdp at exim

Jul 24, 2013, 12:13 AM

Post #4 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On 2013-07-24 at 08:24 +0200, David Saez wrote:
> There is a DSN patch for Exim (RFC 3461 SMTP Service Extension for
> Delivery Status Notifications) at
> http://sourceforge.net/projects/eximdsn/ , it's a confirmation of
> delivery to the remote mta (not a user confirmation receipt) but may
> help ... i wonder why this feature was never added to Exim

Fundamental philosophical differences, with those maintaining Exim then
(and, I believe, now: certainly the case for me) believing that DSN
support for messages originating outside of your own organisation are a
gross violation of privacy.

It's open source. Patches exist for those who want them, that's fine.

(DSN support at the protocol level for things like successful delivery
is not the same as support for the RFC 3464 message/delivery-status DSN
format for bounces, which is something I have argued in favour of, but
the two get tied together by some folks which has led to emotional
rejections of a decent improvement in bounce message formats, alas)

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

eslist at ols

Jul 24, 2013, 12:30 AM

Post #5 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

Hi
>> There is a DSN patch for Exim (RFC 3461 SMTP Service Extension for
>> Delivery Status Notifications) at
>> http://sourceforge.net/projects/eximdsn/ , it's a confirmation of
>> delivery to the remote mta (not a user confirmation receipt) but may
>> help ... i wonder why this feature was never added to Exim
> Fundamental philosophical differences, with those maintaining Exim then
> (and, I believe, now: certainly the case for me) believing that DSN
> support for messages originating outside of your own organisation are a
> gross violation of privacy.

well, this can be implemented as a configurable option, so users can
decide by themselves if this is a privacy violation or not (unless
explicity forbidden by law).

In the other hand i think it's not very good that maintainers decide
what's philosophically right or wrong appart from strictly technical
questions, and decide by themselves what technology is right to use or not.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jgh at wizmail

Jul 24, 2013, 1:07 AM

Post #6 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On 24/07/13 08:30, David Saez wrote:
> In the other hand i think it's not very good that maintainers decide
> what's philosophically right or wrong appart from strictly technical
> questions, and decide by themselves what technology is right to use or not.

Who else will? If you want to put the effort in, join us!
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

eslist at ols

Jul 24, 2013, 1:32 AM

Post #7 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

El 24/07/2013 10:07, Jeremy Harris escribió:
> On 24/07/13 08:30, David Saez wrote:
>> In the other hand i think it's not very good that maintainers decide
>> what's philosophically right or wrong appart from strictly technical
>> questions, and decide by themselves what technology is right to use
>> or not.
>
> Who else will? If you want to put the effort in, join us!

Well this patch is flaoting around since year 2004 ready to be
incorporated in Exim, the effort is already there, what else is need ?

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

michael at talamasca

Jul 24, 2013, 1:37 AM

Post #8 of 17 (157 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On Wed, 24 Jul 2013, David Saez wrote:
> There is a DSN patch for Exim (RFC 3461 SMTP Service Extension for
> Delivery Status Notifications) at
> http://sourceforge.net/projects/eximdsn/ , it's a confirmation of
> delivery to the remote mta (not a user confirmation receipt) but may
> help ... i wonder why this feature was never added to Exim

DSN is a really heavyweight feature. I wouldn't expect most casual
contributors to get it right. And it's not hopeful that the latest
release of the patch was in early 2011 while Exim was last updated in late
2012.

I took a look at the patch (it at least applies with no rejects against
4.80.1) to see how it handled what I would consider a really hard part of
the problem - the format of the DSN messages themselves. Here, you have
to:

* detect invalid (8-bit) content in the message and avoid including the
full message if so. MIME stupidly forbids nested encoding, so if the
message to be bounced is not clean there's no way to legally include it
as a message/rfc822 attachment.

* choose a MIME multipart boundary that does not clash with the message.

* encode the enclosed headers if they aren't clean. Thankfully QP
CTE is allowed for the text/rfc822-headers format defined in RFC 3462.

The patch I see handles none of that. It just picks a random boundary
and *assumes* it won't clash, and *assumes* the message is clean.

Furthermore, it makes two other mistakes:

* When omitting the message body (which it only does on request of the
originator), it still uses the message/rfc822 content type instead of
text/rfc822-headers.

* While it implements RFC 3464 for the new success or relay-to-non-DSN
messages, it leaves Exim's old non-MIME format for delivery *failure*
notifications unchanged. DSN requires that failure messages follow the
3464 format too.

---- Michael Deutschmann <michael [at] talamasca>

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

eslist at ols

Jul 24, 2013, 2:38 AM

Post #9 of 17 (155 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

Hi

El 24/07/2013 10:37, Michael Deutschmann escribió:
> I took a look at the patch (it at least applies with no rejects
> against 4.80.1) to see how it handled what I would consider a really
> hard part of the problem - the format of the DSN messages themselves.
> Here, you have to:

maybe a good start point would be to ommit the original message body
entirely

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jasen at xnet

Jul 24, 2013, 3:25 AM

Post #10 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On 2013-07-23, info [at] paraprueba <info [at] paraprueba> wrote:
> Hi, all.
>
> You can configure the confirmation of receipt of an email in exim?

you can change the 250 message if you want :^) but this is probably
now what you mean.

> I need that the arrive mails requesting confirmation of receipt, the
> response is sent to recipient

Exim has no way to tell if the addressee received the email.

If you want DSN (RFC3461) then no, exim does not do that either.

--
âš‚âšƒ 100% natural

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

info at paraprueba

Jul 24, 2013, 9:06 AM

Post #11 of 17 (156 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On 24/07/13 07:25, Jasen Betts wrote:
> On 2013-07-23, info [at] paraprueba <info [at] paraprueba> wrote:
>> Hi, all.
>>
>> You can configure the confirmation of receipt of an email in exim?
> you can change the 250 message if you want :^) but this is probably
> now what you mean.
>
>> I need that the arrive mails requesting confirmation of receipt, the
>> response is sent to recipient
> Exim has no way to tell if the addressee received the email.
>
> If you want DSN (RFC3461) then no, exim does not do that either.
>
Ok, thanks very much. And now I test DSN Exim Patch.

I compile the Exim with this patch, And now?

Add "dsn_process" in my router but nothing happens. somebody have this
up and running?

My Exim version is: 4.77

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

michael at talamasca

Jul 24, 2013, 11:56 AM

Post #12 of 17 (137 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On Wed, 24 Jul 2013, David Saez wrote:
> El 24/07/2013 10:37, Michael Deutschmann escribió:
> > I took a look at the patch (it at least applies with no rejects
> > against 4.80.1) to see how it handled what I would consider a really
> > hard part of the problem - the format of the DSN messages themselves.
> > Here, you have to:
>
> maybe a good start point would be to ommit the original message body
> entirely

That would not be an implementation of RFC 3461 (the DSN ESMTP
extension), since the extension provides a way for the sender to demand
that the recipient commit to including the full content of the message
when bouncing.

RFC 3461 doesn't actually go out and say "MUST", but it does say the only
exception should be an implementation defined length limit.

It's a little better as an implementation of RFC 3462 alone, (the MIME
format for all DSNs including bounces), but even that document says the
default should be to return full content.

By the way, reading RFC 3461 I see *another* bug in the Exim DSN patch.
The RFC specifies that the sender's preference for full content or merely
headers is only applied to failed deliveries -- for other DSNs (eg:
successful delivery) only headers are ever to be sent.

But the DSN patch sends full headers on success DSNs unless explicitly
asked not to. And, as I noted earlier, the patch does not change the
format of failure DSNs at all.

---- Michael Deutschmann <michael [at] talamasca>

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

eslist at ols

Jul 25, 2013, 5:14 AM

Post #13 of 17 (137 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

Hi

i cannot see why it's not possible to start with a "partial"
implementation that does not return the message body (does it explicity
forbid to have a implementation defined lenght limit of zero ?)

the rest of problems seem easy to fix

> On Wed, 24 Jul 2013, David Saez wrote:
>> El 24/07/2013 10:37, Michael Deutschmann escribió:
>>> I took a look at the patch (it at least applies with no rejects
>>> against 4.80.1) to see how it handled what I would consider a really
>>> hard part of the problem - the format of the DSN messages themselves.
>>> Here, you have to:
>> maybe a good start point would be to ommit the original message body
>> entirely
> That would not be an implementation of RFC 3461 (the DSN ESMTP
> extension), since the extension provides a way for the sender to demand
> that the recipient commit to including the full content of the message
> when bouncing.
>
> RFC 3461 doesn't actually go out and say "MUST", but it does say the only
> exception should be an implementation defined length limit.
>
> It's a little better as an implementation of RFC 3462 alone, (the MIME
> format for all DSNs including bounces), but even that document says the
> default should be to return full content.
>
>
> By the way, reading RFC 3461 I see *another* bug in the Exim DSN patch.
> The RFC specifies that the sender's preference for full content or merely
> headers is only applied to failed deliveries -- for other DSNs (eg:
> successful delivery) only headers are ever to be sent.
>
> But the DSN patch sends full headers on success DSNs unless explicitly
> asked not to. And, as I noted earlier, the patch does not change the
> format of failure DSNs at all.
>
> ---- Michael Deutschmann <michael [at] talamasca>
>
>

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

michael at talamasca

Jul 25, 2013, 7:50 PM

Post #14 of 17 (134 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On Thu, 25 Jul 2013, David Saez wrote:
> i cannot see why it's not possible to start with a "partial"
> implementation that does not return the message body

An implementation of RFC 3462 (MIME formatted bounces) would indeed be an
improvement over the status quo. At the moment it is embarassing that
Exim still uses an arbitrary bounce format.

I'd say it would still be improvement even if it did ignore the RFC
recommendation to send full message content by default. Other people may
differ though, as Exim's legacy bounce format does quote the full message
and thus the change would be a feature loss.

But everything else must be perfect before moving on to RFC 3461 (the DSN
ESMTP option). By advertising this option Exim would make a pledge of
standard conformance in this area.

The current "DSN patch" is actively harmful since it breaks that promise.
At least with vanilla Exim a DSN-using sending MTA will know Exim isn't
standard and take appropriate action.

> (does it explicity
> forbid to have a implementation defined lenght limit of zero ?)
Not explicitly.

---- Michael Deutschmann <michael [at] talamasca>

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

subscriptions.private at mgn

Jul 26, 2013, 4:26 AM

Post #15 of 17 (132 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

There is a logging option:
log_selector = +smtp_confirmation

From the docs:
> smtp_confirmation: The response to the final â€œ.â€ in the SMTP dialogue
> for outgoing messages is added to delivery log lines in the form
> C=<text>. A number of MTAs (including Exim) return an identifying
> string in this response.

For exim the entry on the "=>" line looks a little like this:
C="250 OK id=1V2XUp-0005jj-9Z"
Gmail:
C="250 2.0.0 OK 1374826502 gg6si20604438wjb.120 - gsmtp"

This is a confirmation that the email has indeed been delivered to the
appropriate server. After that it is out of your hands what happens,
but this is proof that a particular message has been sent and accepted
(asuming it isn't backscattered back again).

You can quote this in the event of any dispute over whether the mail was
ever sent.

Note that the receiving server's Message ID is given to you which is
useful evidence of acceptance.

--
Regards,

Martin Nicholas.

E-mail: reply-2013 [at] mgn

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

eslist at ols

Jul 26, 2013, 9:35 AM

Post #16 of 17 (131 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

Hi
> An implementation of RFC 3462 (MIME formatted bounces) would indeed be an
> improvement over the status quo. At the moment it is embarassing that
> Exim still uses an arbitrary bounce format.
This would be really great, the multi language support on the human
readable section
is something we really need, does anybody know if this is something
widely supported
in mail clients (specially microsoft ones) ?

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

michael at talamasca

Jul 27, 2013, 10:14 AM

Post #17 of 17 (125 views)
Permalink

Re: [EXIM] confirmation receptions [In reply to]

On Fri, 26 Jul 2013, David Saez wrote:
> Hi
> > An implementation of RFC 3462 (MIME formatted bounces) would indeed be an
> > improvement over the status quo. At the moment it is embarassing that
> > Exim still uses an arbitrary bounce format.
> This would be really great,
But there's no patch to implement it in front of us. The "Exim DSN"
patch does not, even though that very fact makes it a quite broken
implementation of DSN.

> the multi language support on the human readable section is something
> we really need, does anybody know if this is something widely supported in
> mail clients (specially microsoft ones) ?
DSN has nothing to do with this.

The only connection I can see is that by being machine readable, it might
be possible for an MUA to throw away the original human readable text and
synthesize a new one based on the machine data.

But that's problematic as there may be information in the original human
readable section that's not representable in the machine section.

---- Michael Deutschmann <michael [at] talamasca>

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads