Well, I've got a problem with an SMTP server refusing a null DSN. Apparently this guy John Levine (iecc.com) refuses any connects with a MAIL FRM: <and thus callout verification fails.
We've sent a number of mails back and forth, and it boils down to me arguing "RFC XXX, RFC XXX, RFC XXX says you MUST accept this. Sendmail, the largest producer of SMTP software in the world says you must accept this"
Then he point off to his own failed attempt at an RFC (BATV , draft-levine-mass-batv-01.txt ) and says that says it is okay, and what we are doing it wrong.
Any insights?
Steve

Sat, 20 Aug 2005, Steve B wrote:

Well, I've got a problem with an SMTP server refusing a null DSN.
Apparently this guy John Levine (iecc.com) refuses any connects with a
MAIL FRM: <and thus callout verification fails.

Eh I suspect your statement "refuses any connects with a MAIL FRM: <>"
is not entirely accurate.

We've sent a number of mails back and forth, and it boils down to me
arguing "RFC XXX, RFC XXX, RFC XXX says you MUST accept this. Sendmail,
the largest producer of SMTP software in the world says you must accept
this"

If he never sent the original item that resulted in the bounce,
WHY would he want to accept the blowback that the bounce represents?

Then he point off to his own failed attempt at an RFC (BATV ,
draft-levine-mass-batv-01.txt ) and says that says it is okay, and what
we are doing it wrong.

'Scuse me? Failed attempt? BATV works great, or at least the
customers I have that have enabled it are very happy with it.

Any insights?

My understanding is that due to the massive forgery of John's
domains, he's SWAMPED with callback verifications. To him,
they can be accurately described as a DoS he never asked for.

"Dave Lugo" <dlugo (AT) etherboy (DOT) comwrites:

>>
>Well, I've got a problem with an SMTP server refusing a null DSN.
>Apparently this guy John Levine (iecc.com) refuses any connects with a
>MAIL FRM: <and thus callout verification fails.
>>
>
Eh I suspect your statement "refuses any connects with a MAIL FRM: <>"
is not entirely accurate.

No, I should say he responds with "250 K" if you have something between the
"<>" and he responds with a "553 Not our message (#5.7.1)" if you simply
send a null "<>"

If he never sent the original item that resulted in the bounce,
WHY would he want to accept the blowback that the bounce represents?

There is no original item, he operates a mailing list for eefc.org and when
one does a callout to see if eefc (AT) eefc (DOT) org is a valid e-mail, he 553's you.

>Then he point off to his own failed attempt at an RFC (BATV ,
>draft-levine-mass-batv-01.txt ) and says that says it is okay, and what
>we are doing it wrong.
>>
>
'Scuse me? Failed attempt? BATV works great, or at least the
customers I have that have enabled it are very happy with it.

I didn't say BATV is a failure, I said the RFC was never reviewed by the
IESG or made into an official RFC.

He uses BATV as an excuse for ignoring RFC 821, 1153, 2821, 3461, advice
from sendmail, et al.

I am not saying is right or wrong. The reason I posted here is to check
myself and get other peoples opinions on this failure to accept a null DSN
which various RFC's, and sendmail.org, specifically say you should accept.

My understanding is that due to the massive forgery of John's
domains, he's SWAMPED with callback verifications. To him,
they can be accurately described as a DoS he never asked for.

So somehow sending a "553" reduces the load on his system versus sending a
"250 K"? Please explain. Well, I suppose if enough people put him in a
white list it would.

But then again, if that were the reason, he could explain that to people. If
I heard him say "For reason XXX I have been getting DoS attacked by spammers
with forged return addresses, I am ignoring the established RFC's and
standards. Please put me on an exception list in your callout/callback ACL"
then I would be fine with that.

Steve

PGP SIGNED MESSAGE
Hash: SHA1

In message <045a01c5a5f9$231b7950$6401a8c0@sativa>, Steve B
<exim (AT) stellablue (DOT) orgwrites

>"Dave Lugo" <dlugo (AT) etherboy (DOT) comwrites:
>
Well, I've got a problem with an SMTP server refusing a null DSN.
Apparently this guy John Levine (iecc.com) refuses any connects with a
MAIL FRM: <and thus callout verification fails.
>>
>Eh I suspect your statement "refuses any connects with a MAIL FRM: <>"
>is not entirely accurate.
>
>No, I should say he responds with "250 K" if you have something between the
>"<>" and he responds with a "553 Not our message (#5.7.1)" if you simply
>send a null "<>"

you could always process this specific 553 message (rather than adding
the whole of rfc-ignorant to your exceptions)

>If he never sent the original item that resulted in the bounce,
>WHY would he want to accept the blowback that the bounce represents?
>
>There is no original item

exactly John Levine's point : and he suspects that you are about to send
him a DSN in which he has no interest whatsoever, and so he declines to
talk with you any further.

>So somehow sending a "553" reduces the load on his system versus sending a
>"250 K"?

If it _was_ a bounce (and not one of Exim's callbacks) then there would
be further traffic

Your heuristic (generating extra traffic to strangers in the hope of
reducing spam) broke because it encountered John's heuristic (guessing
at the nature of a transaction to reduce bandwidth)

Appealing to RFCs is not going to help you here (this is more to do with
faith than protocols) -- so get over it and tweak the nature of your
heuristic in some manner.

At least you got an informative error message !
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"

PGP SIGNATURE
Version: PGPsdk version 1.7.1

zDzXvcXPYxDVT6Du7vYQ04P9
=W3dK
PGP SIGNATURE

Sat, 2005-08-20 at 14:29 -0700, Steve B wrote:
Well, I've got a problem with an SMTP server refusing a null DSN.
Apparently this guy John Levine (iecc.com) refuses any connects with a
MAIL FRM: <and thus callout verification fails.

We've sent a number of mails back and forth, and it boils down to me
arguing "RFC XXX, RFC XXX, RFC XXX says you MUST accept this.
Sendmail, the largest producer of SMTP software in the world says you
must accept this"

Then he point off to his own failed attempt at an RFC (BATV ,
draft-levine-mass-batv-01.txt ) and says that says it is okay, and
what we are doing it wrong.

You're probably doing postmaster or header_sender callouts with a
non-empty reverse-path, which is unfortunately Exim's default. Use the
use_sender option on your callouts to make your mail server behave more
sanely.

Your description of John's behaviour is untrue. It's not that he rejects
all mail with empty reverse-path. It's just that he doesn't accept mail
with empty reverse-path if the recipient is an address which never sends
mail in the first place and hence should never receive bounces.

Mon, 2005-08-22 at 00:24 +0100, David Woodhouse wrote:
You're probably doing postmaster or header_sender callouts with a
non-empty reverse-path, which is unfortunately Exim's default. Use the
use_sender option on your callouts to make your mail server behave
more sanely.

Er, use_sender for recipient callouts. Some other option for
header_sender and postmaster callouts.

You're probably doing postmaster or header_sender callouts with a
non-empty reverse-path, which is unfortunately Exim's default. Use the
use_sender option on your callouts to make your mail server behave more
sanely.

So why all the warnings in the docs about not using an address in the DSN
and talk about callback loops?

I noticed that one version of Exim switched to a default of (use sender,
postmaster?) and the next version switches back to null.

Steve

Sun, 2005-08-21 at 21:10 -0700, Steve Brown wrote:
So why all the warnings in the docs about not using an address in the DSN
and talk about callback loops?

That warning is appropriate for normal sender verification callouts. Not
for postmaster or header_sender callouts, which should have a non-empty
local sender (which doesn't trigger callouts of its own) -- or for
recipient callouts, which should use the same reverse-path as the mail
causing the callout.

David Woodhouse wrote:
Sun, 2005-08-21 at 21:10 -0700, Steve Brown wrote:

>>So why all the warnings in the docs about not using an address in the DSN
>>and talk about callback loops?

That warning is appropriate for normal sender verification callouts. Not
for postmaster or header_sender callouts, which should have a non-empty
local sender (which doesn't trigger callouts of its own) -- or for
recipient callouts, which should use the same reverse-path as the mail
causing the callout.

So, I'm confused. Surely the avoidance of loops always requires callout
to use a null sender, and postmaster and header-sender callouts are
in contravention of that? I'd say that the warning is *always*
appropriate. Your "doesn't trigger callouts of its own" is not
under your control; it's the remote end which might be deciding to
make yet another callout.
- Jeremy

Mon, 2005-08-22 at 09:34 +0100, Jeremy Harris wrote:
So, I'm confused. Surely the avoidance of loops always requires
callout to use a null sender, and postmaster and header-sender
callouts are in contravention of that? I'd say that the warning is
*always* appropriate. Your "doesn't trigger callouts of its own" is
not under your control; it's the remote end which might be deciding to
make yet another callout.

I mean an address like 'postmaster-nocallout (AT) your (DOT) local.domain' which,
if you received a probe for that address, would not cause _further_
callouts.

To do a header_sender callout with a null sender is broken, as Steve B
discovered. The RFC2822 sender address may never be used as an RFC2821
sender, and may reject all bounces.

Mon, 2005-08-22 at 13:17 +0100, David Woodhouse wrote:
To do a header_sender callout with a null sender is broken, as Steve B
discovered. The RFC2822 sender address may never be used as an RFC2821
sender, and may reject all bounces.

As an example think about this list. The address <exim-users (AT) exim (DOT) org>
is never ever used to send mail (mail going to you will instead have a
sender address of <exim-users-bounces+@exim.org>), so attempting a
call out verify of the address will cause the following:-
MAIL FRM: <>
250 K
RCPT T: <exim-users (AT) exim (DOT) org>
550 "Recipient never sends mail so cannot cause bounces"

If you are trying to do call out verification of this address then
either:-
1. You received a forged message in the first place (so its not my
problem).
2. You are extracting addresses from headers (so thats your
problem).

Nigel.

David Woodhouse wrote:
To do a header_sender callout with a null sender is broken, as Steve B
discovered. The RFC2822 sender address may never be used as an RFC2821
sender, and may reject all bounces.

Gotcha - I'd missed the point about header-sender callouts (and
that Steve was doing that!). Thanks.
- Jeremy

, so why would one ever do a sender callout rather than just *always*
doing a header_sender callout?

And am I missing a FAQ somewhere that explains the finer details of
callouts?

Steve

As an example think about this list. The address <exim-users (AT) exim (DOT) org>
is never ever used to send mail (mail going to you will instead have a
sender address of <exim-users-bounces+@exim.org>), so attempting a
call out verify of the address will cause the following:-
MAIL FRM: <>
250 K
RCPT T: <exim-users (AT) exim (DOT) org>
550 "Recipient never sends mail so cannot cause bounces"

If you are trying to do call out verification of this address then
either:-
1. You received a forged message in the first place (so its not my
problem).
2. You are extracting addresses from headers (so thats your
problem).

Nigel.

Mon, 22 Aug 2005, Steve Brown wrote:

, so why would one ever do a sender callout rather than just *always*
doing a header_sender callout?

A return-path callout gives you some confidence that a message can be
bounced, and therefore greatly reduces the number of double bounces you
must deal with.

Tony.

Mon, 22 Aug 2005, Steve Brown wrote:

, so why would one ever do a sender callout rather than just
*always* doing a header_sender callout?

As far as an MTA is concerned (for example, if it has to create a
"bounce"), the envelope-sender is the critical address. What appears
in mail headers is of only secondary concern to it, as the MTA itsef
wouldn't use those addresses for itself - they are for a human
recipient, not for the MTA itself. In the case of spam, these
addresses are sometimes very, very different from each other.[0]

If our MTA needed to create a "bounce" it would, of course, create it
with a null sender, so in this case we are particularly interested in
the response of the relevant MTA to a null-sender callout. That all
hangs together.[1]

If (as seems to be traditional for Chinese MTAs, for example) it
refuses null senders on principle, then we know we'll never be able to
send a "bounce" to it, so we know that reliable mail exchange with it
isn't possible: so, generally speaking[2], we err on the safe side and
set things up for it to reject our callouts, which in turn means that
we tell it that their sender verification has failed, goodbye.

(Sure, there are a few rogue MTAs closer to home which behave that way
too, but where we'd have some reason to want to hear from them, and
that reason might be strong enough to override our normal reluctance
to accept mail from such a rogue. In the past this has been the case
for some potential sources of research funding, for example: our
manglement would not have been happy if we'd rejected their mail on
such grounds, or even if we had tried to throw the RFCs at them!).

hope that's useful

[0] most recent example in the rejection log, an envelope-sender of
www-data (AT) bces-1650 (DOT) de with a From: header which read:
From: info (AT) perhits (DOT) de <zwulff (AT) gmx (DOT) de>

Hmmm fortunately, that header fails syntax checks, so we didn't
need to bother spamassassin with the content of this pink stuff

[1]Conversely, a real user would be expected to reply to a header
address using their own address as sender. Users manually creating
mail with a null sender is improper. So if you want to verify a header
"from" or other kind of header sender address under realistic
conditions, it would be logical to do the callout with a non-null
sender. that you're not going to try a callout on when the remote
MTA tries it back at you, naturally.

[2]Just to recap that we don't simply throw sender verification
callouts at every mail offer that we get: we use them selectively,
typically where the caller domain is in a local list of domains where
callout has been proved efficacious to reduce spam and other kinds of
abuse. We *do* understand that callouts in response to spam, where
envelope senders are widely faked, represent a certain level of misuse
of a third-party's MTA, and that it would be rude of us to over-use
that facility, so we try to repel spam on other grounds first; but we
do feel that on balance a controlled use of callouts is the lesser
evil, compared with the potential consequences of accepting such faked
mails. today we had a naive user, despite our best efforts at
education, trying to reply to a fraudulent mail (fortunately, the
reply failed) *and* visiting the cited fraudulent web page, where an
exploit was waiting to catch any unpatched victim. then did the
user ask for advice from support staff. ! We now know that if
this item's envelope sender domain had been in our callouts list, the
callout would have caused it to be rejected.

Mon, Aug 22, 2005, Nigel Metheringham wrote:
MAIL FRM: <>
250 K
RCPT T: <exim-users (AT) exim (DOT) org>
It's interesting how many people get this wrong
RFC (2)821 doesn't allow a space after colon.

So basically it seems that one could consider a very loose interpretation of
the RFC's "everything should be accepted with a null DSN" appropriate, while
another could consider a stricter interpretation of "you only have to accept
null DSN to accommodate for mail originating from your server" appropriate.

From what I have gathered reading various discussions and on this list, it
seems that the need for a stricter interpretation has gained favor and
general acceptance due to the actions of malevolent parties and the need to
deal with those situations.

Seems reasonable.

Steve

"you only have to accept null DSN to accommodate for mail originating from
your server"
clarification " accommodate for bounces/notifications/etc relating to
mail originating from your server "

Wed, 2005-08-24 at 11:34 -0400, Greg A. Woods wrote:
There's _never_ any need to reject the empty _sender_ address, especially
not in that case.

If the address never sends any messages and the incoming message addressed
to that address is using an empty sender address, then the correct and sane
thing to do is to reject the RCPT T: command.

Indeed so. you don't reject the empty sender immediately after
MAIL FRM:<; you can only do it after you've seen the address in the
RCPT T: and determined that it's an address which never sends mail.

That is in fact what John is doing, and that's why I corrected Steve's
mis-statement of the observed behaviour.