Mailing List Archive

On Thu, 2004-10-28 at 15:57 -0400, der Mouse wrote:
> Out of an email exchange with someone in Germany came the observation
> that exim apparently both does accept-and-bounce and generates
> non-RFC3462 bounces.

Exim will only normally accept-and-bounce if it's poorly configured, or
in exceptional circumstances. Besides, there are times when you _want_
it to accept-and-bounce, like when it's dealing with message submission
from an MUA which can't deal with rejection.

RFC3462 bounces seem like a sane plan though. Got a patch?

--
dwmw2

>> Out of an email exchange with someone in Germany came the
>> observation that exim apparently both does accept-and-bounce and
>> generates non-RFC3462 bounces.
> Exim will only normally accept-and-bounce if it's poorly configured,
> or in exceptional circumstances.

Oh, that's good to hear. (I guess the cases I see must be the
exceptional circumstances, or perhaps more likely botched
configurations. But of course I basically just never hear about the
many sites that don't do accept-and-bounce.)

> Besides, there are times when you _want_ it to accept-and-bounce,
> like when it's dealing with message submission from an MUA which
> can't deal with rejection.

Yes, that's entirely true; it's far more reasonable for mail received
as an MSA (vs an MTA). Even there, though, I'd be careful to bounce to
the user from whom it was received rather than to the envelope-from
address (which for all I know you may well already do - that is not a
criticism).

> RFC3462 bounces seem like a sane plan though. Got a patch?

No, unfortunately. I don't run exim myself.

The story, in brief: I ran into a German site that (a) did
accept-and-bounce, (b) didn't do 3462, and (c) rejected my reply to the
bounce (ie, mail to the From: address on the bounce) with a message
telling me my(!) software was broken. Someone from Germany tried to
mail me through it and failed, reached me by another channel, and in
talking about this site my correspondent said something like "I think
they use a modified exim - have you contacted the exim folks?". Upon
checking my own logs, I see that while exim bounces of forgeries are
not _common_, exactly, they are far from rare. So I thought I'd drop
you a line to put a bug in your ear about 3462.

Of course, even if you were to completely agree with me and rush to
implement RFC3462 bounces, it's not as if you can force anyone to use
the new version; this is not an attempt to cure the world's ills
tomorrow. Not even this one particular ill. Approaching you people
about it is a longer-term tack, trying to reduce the general level of
non-3462 (and thus non-machine-parseable) bounces (and thus the level
of such bounces I have to deal with).

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Thu, 28 Oct 2004, der Mouse wrote:

> > Exim will only normally accept-and-bounce if it's poorly configured,
> > or in exceptional circumstances.

Correct. You can configure it either way, but the default is to test
what it can before accepting. The point is you can never be 100% sure
that you will be able to deliver, so there will always be
accept-and-bounce cases (even for the non-submission situation).

> > RFC3462 bounces seem like a sane plan though. Got a patch?
>
> No, unfortunately. I don't run exim myself.

The Exim Wish List contains this item (note that 3462 obsoletes 1892):

------------------------------------------------------------------------------
(105) 28-Jun-1999 M MIME-format bounce messages
Paul Makepeace

"Is there any work going/gone on/planned to enable exim to report delivery
status notifications using RFC1892 multipart/report MIME messages? It would be
great to have errors reported in a message/rfc822 attachment."

Jeffrey Goldberg
"I like plain bounces, so would hope that if you do this, that it be
configurable. I think that even for those who want it, it shouldn't be very
high on the wish list priority."

Other suggestions: toggle for bounces/warnings; override max_return for
certain addresses; use plain text if original not MIME. See Paul's hack
for background of what to do.

Nigel suggests using a specially named autoreply transport to generate bounces;
people could then replace this with another transport (e.g. pipe) if they want
to customize it themselves.

Eli Chen posted an unconditional patch for 3.32 that does some of this work.
That could form a basis.
------------------------------------------------------------------------------

Nothing has happened since then. For myself, I've always found other
more pressing (IMHO) things to do, and nobody has been sufficiently keen
to provide a patch.

> The story, in brief: I ran into a German site that (a) did
> accept-and-bounce, (b) didn't do 3462, and (c) rejected my reply to the
> bounce (ie, mail to the From: address on the bounce) with a message
> telling me my(!) software was broken.

Was that an *automatic* reply to the bounce? If so, with respect, I
suggest that doing that is rather unwise. If not, then the German site
is not exactly well-managed...

> Of course, even if you were to completely agree with me and rush to
> implement RFC3462 bounces,

Given that it's been on the Wish List for 5 years, and I do not hear
millions of people shouting for it, or implementing it, I'm afraid that
I cannot conclude that there is any hurry. :-)

It would be interesting to know exactly which MTAs support 3462 and
which do not. I suspect Exim is not alone.

Regards,
Philip

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

>> The story, in brief: I ran into a German site that (a) did
>> accept-and-bounce, (b) didn't do 3462, and (c) rejected my reply to
>> the bounce (ie, mail to the From: address on the bounce) with a
>> message telling me my(!) software was broken.
> Was that an *automatic* reply to the bounce?

My message? No. Well, automatic in the sense of "habitual", maybe;
when I get a bounce that both is in response to a message I didn't send
and makes it to my mailbox, either (a) it's not a 3462 bounce, (b) my
code is broken, or (c) it's one of the rare messages that produces a
false positive from my "did I send this?" test. Case (a) is by far the
commonest, and when I get them I (manually, but almost reflexively)
send a response saying, basically, "please either stop doing
accept-and-bounce or start doing RFC3462 bounces so I can mechanically
identify and process them". (Sites that persist, I block completely.)

> If not, then the German site is not exactly well-managed...

Well, yes. That's why I blocked it.

>> Of course, even if you were to completely agree with me and rush to
>> implement RFC3462 bounces, [...]
> Given [...], I'm afraid that I cannot conclude that there is any
> hurry. :-)

Right. You will note I used the subjunctive. :-)

I was hardly expecting you people to drop everything and rush to
implement multipart/report bounces. And I'm not really surprised to
hear it's already on your wishlist; I was wrote more on the chance that
one more voice might push someone over into actually doing it.

> It would be interesting to know exactly which MTAs support 3462 and
> which do not. I suspect Exim is not alone.

I'm certain it's not alone. Even sendmail, which I use and which does
generate 3462 bounces, can be configured not to.

Not that its being alone or not matters much to me. Widespread bad
behaviour is no less bad behaviour for being widespread. (I hope we
can agree on that much, even though we may differ on exactly what
constitutes bad behaviour!)

Actually, the worst single offender, in terms of volume aimed at me,
qmail, fortunately (from my perspective) also ignores 2822 3.6.4's
dictum that every message SHOULD have a Message-ID:. I call this
fortunate because it means most qmail bounces get refused at the door
and never make it through to my mailbox despite the bounce-of-forgery
code's inability to pick out the bounced message. (I say "most"
because a few qmail sites have configured things so their bounces do
have message-IDs; also, a few get handled by MTAs which add
Message-ID:s to messages they're just passing on.)

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Fri, 29 Oct 2004, Philip Hazel wrote:
>
> It would be interesting to know exactly which MTAs support 3462 and
> which do not. I suspect Exim is not alone.

Yes: sendmail, postfix, exchange(?)
No: qmail

A clue is if they support the DSN ESMTP extension (postfix doesn't but it
does produce standard bounces).

Tony.
--
f.a.n.finch <dot@dotat.at> http://dotat.at/
MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING
MODERATE.

On Fri, 29 Oct 2004, der Mouse wrote:

> commonest, and when I get them I (manually, but almost reflexively)
> send a response saying, basically, "please either stop doing
> accept-and-bounce or start doing RFC3462 bounces so I can mechanically
> identify and process them".

I no longer bother to grumble about unwanted bounces. Fortunately, most
of those that come to me are sent to an email address that I never use
for sending, so I can silently discard them. Around 100 a day at the
moment.

> I was hardly expecting you people

Although I get help in the form of patches, etc, there's only one of me!

Regards,
Philip

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.

On 10/29/2004 6:26, "Philip Hazel" <ph10@cus.cam.ac.uk> wrote:

> Although I get help in the form of patches, etc, there's only one of me!
>
> Regards,
> Philip

Exim, plus PCRE plus ??? (is there a ??? in general distribution).

It's becoming increasingly hard to believe there's only one of you. ;-)

Thanks again for the great work!

--John

On Fri, 29 Oct 2004, John W. Baxter wrote:

> Exim, plus PCRE plus ??? (is there a ??? in general distribution).

??? == PMW (a music typesetting program, see www.quercite.com)

> It's becoming increasingly hard to believe there's only one of you. ;-)

I've been around a looooong time... :-)

> Thanks again for the great work!

Thank you.

Philip

--
Philip Hazel University of Cambridge Computing Service,
ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714.