Subject: [Asrg] Ban the bounce; improved challenge-response systems

From: [email-masked]
Date: Sat, 5 Apr 2003 23:23:07 -0500

Bounce messages are a relic from a kinder/gentler internet where
spammers didn't exist, and didn't forge innocent 3rd-parties' email
addresses into the "From:" or "Reply-To:" headers.  Maybe it's time to
depracate bounce messages.  Open relays were once considered good, but
spammers' abuse has caused them to be depracated.

  To continue providing delivery-failure info to legitimate senders, we
will have to use some variant of 4xx or 5xx reject messages.  This, of
course, implies that the internet-facing MTA will have be able to make
and carry out the decision to reject an email.  A clunky system that
blindly accepts all incoming email and passes it on to a second machine
for final disposition won't work.  If the second machine decides, for
whatever reason, to refuse the email, the only way it can send that
notification is via a bounce message.  And if a spammer has forged the
"From:" and/or "Reply-To:" header, innocent third parties get mailbombed.

  Current challenge-response systems share the major flaw of bounce
messages, i.e. they blindly accept the "From:" header as gospel.  So
instead of a spamrun resulting in a few angry responses from clueless
newbies who can't parse headers, it may draw a whole slew of challenges
from whitelist systems.  Then there's stuff like the [email-masked]
fiasco; nuff said.

  I have an account with an ISP with a hacked-up Qmail that parses
filter-config files in users' home directories right after the RCPT:
stage.  If the filter results in rejection, the email is rejected with a
550 code before the DATA: stage.  It is *NOT* bounced.  This ISP doesn't
participate in the mailbombing of innocent 3rd-parties.

  I didn't think of it as a challenge-response system at the time, but
for most reject messages, I include a URL to one of my home webpages
that has my current temporary unfiltered email address to bypass the
filters.  I assume that spammers use spamware and won't read, let alone
act on, 550 reject messages.  Real people trying to get in touch with me
will receive the 550 reject, along with the pointer to my bypass address
and can contact me that way.  A spam that gets rejected will result in a
550 to the sending MTA, not a bounce to an innocent 3rd party.  If
something breaks and asrg list messages get rejected, the list-manager
MTA will get 550's, rather than subscribers getting "[email-masked]"
messages.

  I do realize that there is a significant difference in scale between a
small ISP, versus AOL.  Looking up a RCPT: address amongst 30 million
main addresses (and who-knows-how-many "screen names") requires
significant hardware/software to do in a timely manner.  But it will
have to be done.  Otherwise other people, and entire ISPs, may be forced
to blockade in self-defense against biggies who mailbomb-by-proxy.

-- 
Walter Dnes <[email-masked]>
An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Sat, 05 Apr 2003 22:46:12 -0800

On Sat, 5 Apr 2003 23:23:07 -0500 
waltdnes  <[email-masked]> wrote:

> To continue providing delivery-failure info to legitimate senders,
> we will have to use some variant of 4xx or 5xx reject messages.  

This creates five obvious problems: inbound and outbound relays,
aliases, .forwards, and header rewriting.  Inbound and outbound relays
architectures are extremely common, for good reasons like scalability,
control, oversight, network security/posture, etc.  Aliases and
.forwards I'll leave to themselves with the simple comment, "role
addresses".  

As soon as a there's a disjoint between the system that the MUA is
running on, and the final delivery address for a mail, return signalling
has to be OOB.  What that really means is that as long as the MUA can't
originate a direct TCP connection to the final delivery system, knowing
that its the final delivery system, you have to have OOB error
signalling.

> This, of course, implies that the internet-facing MTA will have be
> able to make and carry out the decision to reject an email.

It implies rather more than that.  It implies that the MUA does all the
hard work from scheduling to spooling on down as well.

> messages, i.e. they blindly accept the "From:" header as gospel.  

False.  TMDA among other challenge/response systems authenticates on
envelope and From: together.  This is deliberate.

> have to be done.  Otherwise other people, and entire ISPs, may be
> forced to blockade in self-defense against biggies who
> mailbomb-by-proxy.

You also assume that mail is delivered to directly connected systems
only.  What about, say, domains sitting behind UUCP or ETRN links
wherein the relay box *HAS* no knowledge of accounts configured on that
domain as it has no organisational ties to it other than as an MX.

Removing OOB error signalling is a fundamental protocol change as it
moves SMTP from a largely asynchronous messaging system to a purely
synchronous messaging system.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 6 Apr 2003 08:24:27 -0400 (EDT)

> hard work from scheduling to spooling on down as well.

The MUA could still forward to an MSA without contradicting the spirit of
the proposal.

An MSA that has some knowledge of where its messages come from, either by
SMTP AUTH or merely because it only accepts submissions from hosts it
trusts, can still relay that mail to other internet hosts without
generating DSN notices to innocent third parties.

The proposal only suggests that hosts accepting mail from *stangers*
should know if they are going to deliver that mail before they "OK" it at
the completion of the mail acceptance process. RBLs do this, most content
based screening does not, but could if it wanted too. MTAs don't usually
support this very enthusiastically.

No doubt that some mail architectures will not be able to do this. To
reject mail for non-existant users the accepting MTA will have to have
access to the user list, which is sometimes not available to the accepting
MTA in the DMZ. That would have to change. The alternatives are to stop
bouncing bad email-addresses or become a vehicle for spammers to abuse,
neither of which is very attractive.

We have gone to quite a bit of trouble to start doing Spamassassin
screening in a Sendmail Milter, rather than in the local delivery agent,
just for this reason. By refusing mail rather than dropping it on the
floor we will give senders of false positives a rejection rather than
risk losing the message entirely.

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 13:51:50 -0700

On Sun, 6 Apr 2003 08:24:27 -0400 (EDT) 
Daniel Feenberg <[email-masked]> wrote:

> The MUA could still forward to an MSA without contradicting the spirit
> of the proposal.

> An MSA that has some knowledge of where its messages come from, either
> by SMTP AUTH or merely because it only accepts submissions from hosts
> it trusts, can still relay that mail to other internet hosts without

That would require both that all .forwards and aliases are fully known
to the receiving MTA, and that they only operate within the field
controlled/behind that MTA.  

> No doubt that some mail architectures will not be able to do this. 

Aye.

> To reject mail for non-existant users the accepting MTA will have to
> have access to the user list, which is sometimes not available to the
> accepting MTA in the DMZ. That would have to change. The alternatives
> are to stop bouncing bad email-addresses or become a vehicle for
> spammers to abuse, neither of which is very attractive.

At the simple human end of affairs, if Susan Secretary typoes (or
misreads from handwritten notes) the address on the email her boss told
her to send to the CEO of partner-company, then she needs a way to find
out about it.  Similarly for the email a grandmother sends her
granddaughter in her new job/college/etc.

---

From: [email-masked]
Date: Sun, 6 Apr 2003 18:00:21 -0400

Let me clarify this a bit.  A bounce message should not be sent to
anybody *EXCEPT THE ACCOUNT THAT ORIGINATED THE EMAIL*.  The only MTA in
a position to know this info is the the MTA at the sender's ISP (or
place of work or whatever).

On Sat, Apr 05, 2003 at 10:46:12PM -0800, J C Lawrence wrote
> .forwards I'll leave to themselves with the simple comment, "role

  1) Inbound relays is a design decision.  It will have to change in
future.

  2) The outbound relay should not be a problem.  I *HOPE* that an ISP
is competent enough to log who is logged in, and to be able to translate
a 550 from a distant MTA into a bounce message *TO THE ACCOUNT THAT SENT
THE ORIGINAL EMAIL*.

  3) aliases.  See 2), the ISP should translate the 550 error message to
a bounce message *TO THE ACCOUNT THAT SENT THE ORIGINAL EMAIL*.

  4) .forwards The risks of running a bot.

  5) Header re-writing is to good email practice what self-modifying
code is to good programming.  Mailing lists are one exception to that.
They should handle 550 rejects properly, because they are effectively
originating a new email.

> hard work from scheduling to spooling on down as well.

  WRONG.  The *MTA* does that.  An ISP knows who is logged on via which
IP address.  Until such time as the email has been accepted by the
recipient's ISP's MTA, the email is still queued up on the sender's ISP.
They should be able to generate an *INTERNAL* bounce message *TO THE
ACCOUNT (not the address) THAT SENT THE ORIGINAL EMAIL*.

> envelope and From: together.  This is deliberate.

  And a spammer running "Desktop Mailer" direct-to-MX or going via an
0wn3d machine is *NOT* going to be deterred by having to forge one more
item in the spam.

> synchronous messaging system.

  Main problem is that it's *NOT* OOB.  Just ask any innocent victim
who's gotten thousands of bounce messages when a spammer has forged
their email address as the "From:".

---

From: Daniel Feenberg <[email-masked]>
Date: Sun, 6 Apr 2003 18:31:59 -0400 (EDT)

The proposal is that MTAs reject messages before acceptance rather than
bounce them. 

On the other side we have the statement that this will kill UUCP.

This is really a stretch. UUCP is fully capable of handling message
rejection. So no matter how many sites start stop accepting invalid mail
and responding later with a DSN in favor of rejecting the message promptly
while still connected, there is no adverse affect on UUCP sites.

It is possible that some site might take this one step farther (one step
too far?) and stop accepting bounce messages entirely on the grounds that
they were no longer necessary. I haven't read anything here that suggests
that as a course of action.  That would adversely affect the ability of
UUCP sites to notify those over-zelous sites that their mail had bounced.
It wouldn't affect anyone else, and it wouldn't affect any valid mail.

So why is this so controversial? 

Daniel Feenberg

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 6 Apr 2003 18:02:18 -0600 (MDT)

> From: [email-masked]

> ...

Please say why the reasons that required inbound relays are no longer valid.

> ...

You seem to be thinking of aliases at the source of the mail, while I 
suspect that the other person is thinking of aliases at the destination.

>   4) .forwards The risks of running a bot.

What do "bots" have to do with idea behind .forward files?
Have you never changed employers or had other reasons to want your
own mail forwarded from an old address to a new address?

Would you prohibit ISPs from forwarding mail for recently departed
customers?

> ...

That assumes that the original MTA talks directly to the ultimate MTA
that delivers the message to the final mailbox or at least talks to
other MTAs that do not say "250 ok" to a DATA command until the ultimate
MTA delivers the message.  Such a system is not a store-and-forward
mail system.  It has advantages compared to store-and-forward, but it
also has major disadvantages.  If store-and-forward messaging systems
were not required, we would still be using alternatives such as the
40 year linage that is represented by IRC.  (At least 40 years old,
because the Berkeley Project Genie or SDS 940 had something that looked
very much like `talk`.)

> ...

Are you sure you understand the same thing in "OOB" that the other 
person meant? 

  .....................
(another msg from someone else)

+ Instead, I would like to see a new and better protocol.  The new mail 
+ programs could take advantage of it and its new capabilities.  (I for one 
+ would like to see a References: header just like in NNTP for article 
+ threading though that has nothing to do with spam in itself.)

What's wrong with the References header defined in section 3.6.4 of
RFC 2822?

It would be really swell if all of some of these proposals to fix SMTP
were grounded on a little knowledge of the nature of the thing being
fixed.  

Note that the author of that particular proposal is not among those
who are really enthusiastic about proposing changes while demonstrating
a distinct lack of familiarity with email and SMTP.

   ...............

] From: Kee Hinckley <[email-masked]>

] >However, I think it would be a bit better if a very few high volume
] >posters such as yourself would start adding either In-Reply-To or
] >References headers just like the vast majority of posters do.
]
] Sure, everyone can just run right out and patch the binary.

Who needs to patch which binaries?  I use an older than ancient MUA that
knows nothing about References or In-Reply-To headers.  However, except
when I mess up, my messages contain a References haeder, a subject line
identical or strongly related to the preceding article, and are sent
only to the mailing list and not to all of the random other addresses
that have accreted.  For me all it takes is some time and effort.

> ...
] And do most MUAs generate their own Message-IDs?

At least some MUAs leave Message-ID generating to MTAs or MSAs, and
some of MTAs (e.g. qmail in some installations) blow it.
(One of my best filters for bulk mail is the lack of the a Message-ID
line, and the only noticable false positives involve qmail.)

   .....................

} From: [email-masked]

} > More common examples of why relays are required and why they cannot
} > know whether an incoming message can be delivered during the SMTP
} > transaction are MX secondaries and corporate firewalls.
}
}   Is the corporate firewall a NAT machine or is it a dumb MTA that
} relays to the "smart MTA" ?  If it's a dumb MTA, then why is it being
} used ?

This problem has nothing to do with the intelligence of any MTAs or
network address translation Instead it is related to the practical
problems in synchronizing large databases among computers thousands
of mails apart as well as security issues.

There are security arguments that say that computers exposed to the
Internet should not know anything that is sensitive.  Lists of
valid email addresses can be very sensitive.  Thus you can reasonably
argue that machines outside your firewalls should not know which
email addresses are valid, and so should not be able to reject
mail to invalid addresses.

In naive, simplistic, and wrong theory, it is trivial to synchronize
databases of 100,000's or 1,000,000's of users names among MX servers.
This is yet another case where "in (naive, simplistic, and wrong)
theory there is no difference between theory and practice but in
practice there is.  It is impractical to build a mail system that will
handle all of the incoming mail for a large company or medium sized
ISP but have all of the MX servers have the identical, always completely
accurate list of valid email addresses.  You might do that if you
required a business day to turn on email or to terminate an account,
but such a system would be unacceptable today.

} > How can an MX secondary or corporate firewall know not merely that
} > the Rcpt_To address is valid but that there will be no problems
} > putting the message into the mailbox?  "User unknown" is not the
} > only 5yz SMTP error code and not the only contents of a bounce.
}
}   Then fer-cryin-out-loud, hold off on the "OK" response for a few
} seconds and wait till the email is accepted.  If it isn't, issue the
} appropriate 5xx code after DATA:.

I wish I did not think you were seriously proposing that delivery to
the user's mailbox always be synchronous with the SMTP transaction on 
your external firewall.  It is not only that such a system could not
perform at speed, but that it would have intolerable reliability problems.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 06 Apr 2003 19:33:53 -0500

In <20030406042307.GC994@m1800> [email-masked] writes:

> depracate bounce messages.  

While I don't believe we can outright ban bounces, I do think it is a
very good idea to detect errors as early as possible.  

The receiving MTA should always try hard to make the sending MTA
generate the bounce via the 5xx reject codes.  It should also try to
verify that the MAIL FROM address is valid before it accepts the email
so that if a bounce has to be generated later, it can be.  Exim can
verify not only the MAIL FROM, but also the From:, Reply-To: and
Sender: headers to try and cut down on bad bounces.

Something like the RMX or domain-specific DNSBL solution would also
help make sure that later bounces are not being sent to third party
spammer victims.

In theory, the sender MTA could and probably should also verify these
things.  Again, the earlier the errors are detected, the better.  Of
course, the receiving MTA probably can't trust that the sending MTA
will have done these checks, but checking them twice won't hurt.

-wayne

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 17:39:11 -0700

On Sun, 6 Apr 2003 18:31:59 -0400 (EDT) 
Daniel Feenberg <[email-masked]> wrote:

> The proposal is that MTAs reject messages before acceptance rather
> than bounce them.

Not quite.  The proposal was initially to remove the bounce error
channel entirely, and then later that MTAs which are public-facing (eg
primary MXes) not generate bounces at all and instead return rejection
codes.  Both approaches would require vast architecural changes to
deployed mail systems, and would necessarily deliver a system that is
bot fragile and prone to silently losing mail.

> On the other side we have the statement that this will kill UUCP.

If receiving MXes can not generate bounces, then they must have perfect
knowledge of the mail systems behind them.  This is tantamountly
impossible in several cases, among which are out-of-domain aliasing,
.forwards, and (often) UUCP gateways.  If bounces as an OOB error form
remain allowed, then it doesn't break UUCP (or much at all).

Then again, if bounces are still allowed, then all this proposal really
sums to is, "Please be more aggressive about rejecting mail at the SMTP
level rather than accepting and later bouncing."  There's little to
argue with such a best-practices and better-efficiency approach.  

> rejection. So no matter how many sites start stop accepting invalid
> mail and responding later with a DSN in favor of rejecting the message
> promptly while still connected, there is no adverse affect on UUCP
> sites.

Which was not the point discussed.

> It is possible that some site might take this one step farther (one
> step too far?) and stop accepting bounce messages entirely on the
> grounds that they were no longer necessary. I haven't read anything
> here that suggests that as a course of action.  

The initial proposal was to entirely do away with bounce messages.

> That would adversely affect the ability of UUCP sites to notify those
> over-zelous sites that their mail had bounced.  It wouldn't affect
> anyone else, and it wouldn't affect any valid mail.

Doing such would have adverse impacts as it removes the entire OOB error
channel.  Susie Secretary no longer has a way of telling that she typoed
an address.  Bad bad bad.

> So why is this so controversial?

Because they were different contentions than you have listed.

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 18:15:26 -0700

On Sun, 6 Apr 2003 18:00:21 -0400 
waltdnes  <[email-masked]> wrote:

> anybody *EXCEPT THE ACCOUNT THAT ORIGINATED THE EMAIL*.  

What is the definition of, "the account that originated the email" for
mail originating from an automated system, such as a cron job, make,
logcheck, or similar?  

In what way does this alter Return-Path semantics?

> The only MTA in a position to know this info is the the MTA at the
> sender's ISP (or place of work or whatever).

How do they know?  A standard ISP has several hundred thousand domains
typically.  Do we require per-mail account registration and
authentication for senders?  Where's the value add to the ISp to deploy
all the extra machinery, configurations, and end-user tech support for
such?

>> On Sat, 5 Apr 2003 23:23:07 -0500 waltdnes <[email-masked]>
>> wrote:

>> aliases, .forwards, and header rewriting.  Inbound and outbound
>> relays architectures are extremely common, for good reasons like
>> scalability, control, oversight, network security/posture, etc.
>> Aliases and .forwards I'll leave to themselves with the simple
>> comment, "role addresses".

> 1) Inbound relays is a design decision.  It will have to change in

Its a pretty hard thing to remove as use of inbound relays is one of the
early tools in building scalable mail processors (they provide
buffering, control, review, etc).  Inbound relays also (essentially)
match the definition of transport protocol gateways, and secondary MXes.

What happens for a delivery error when a secondary MX delivers to the
primary MX?

> is competent enough to log who is logged in, and to be able to
> translate a 550 from a distant MTA into a bounce message *TO THE
> ACCOUNT THAT SENT THE ORIGINAL EMAIL*.

See above.  There's an assumed knowledge space there which doesn't
currently exist and is difficult to make exist.  If you add things like
per-mail user authentication (shared secret, whatever), then perhaps.
However, that gets even more difficult with things like, ohh, a company
with its own domain and an intermittent connection using an ISP's
smarthost to relay out mail, a multi-homed company also using a
smarthost, or a standard distributed corporate deployment using a single
outbound relay (as IBM for instance once did, several chunks of the US
military still do, etc).

> a bounce message *TO THE ACCOUNT THAT SENT THE ORIGINAL EMAIL*.

How do you handle the case where an alias points out of domain, or where
an alias points to several delivery targets, only some of which error?

>   4) .forwards The risks of running a bot.

They are essentially no different than aliases.

>> It implies rather more than that.  It implies that the MUA does all
>> the hard work from scheduling to spooling on down as well.

> IP address.  

Actually, they don't.  Assuming an ISP and a dialup account, they can at
best currently know a class of addresses which could be infinite in the
registered domain case, but could easily be >1 in the NAT or multi-user
household case.

Why are you dealing only with ISPs?  A small fraction, less than half,
of the mail that I deal with originated behind a consumer ISP.

> Until such time as the email has been accepted by the recipient's
> ISP's MTA, the email is still queued up on the sender's ISP.  

So no secondary MXing then, and the recipient MTA has to have perfect
knowledge of the state behind it such that the it can guarantee (or not)
successful delivery of a message at SMTP time...

Ouch.

You just lost the majority of the developed world there.

> 0wn3d machine is *NOT* going to be deterred by having to forge one
> more item in the spam.

True, tho the problem is knowing and getting both the envelope and From:
right for a given message to a given recipient.  <shrug> It can happen,
I've seen KLEZ do it twice in the last year.

There's a more simple clarity here.  If JoeBloew's machine can email
various people, then rogue software in control of JoeBlow's machine can
email those same people.  If we require manual revelation of a secret by
JoeBlow to be able to send mail, then there is nothing to prevent that
same rogue software from compromising the secret or impersonating
JoeBloe in other ways.  Additionally, such a manual repetitive barrier
will actively encourage Joe to not use email at all...

Where's the win?

> Main problem is that it's *NOT* OOB.  

Ahem.  They do not occur within the SMTP session that sent the message
generating the bounce.  (Tho I admit they use the same transport and
*MAY* use the same physical systems etc).

> Just ask any innocent victim who's gotten thousands of bounce messages
> when a spammer has forged their email address as the "From:".

As I mentioned early, I just got thru receiving a little over 80,000
such bounces.

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 18:36:08 -0700

On 06 Apr 2003 19:33:53 -0500 

>> addresses into the "From:" or "Reply-To:" headers.  Maybe it's time
>> to depracate bounce messages.

Minor note:  bounces go to the Return-Path in the envelope, not to From:
or Reply-To:.

> very good idea to detect errors as early as possible.

<nods eagerly>

> generate the bounce via the 5xx reject codes.  

Most MTAs do this as it is easier, faster, and requires less resources.
The problem, as always, is insufficient knowledge.

> It should also try to verify that the MAIL FROM address is valid
> before it accepts the email so that if a bounce has to be generated
> later, it can be.  Exim can verify not only the MAIL FROM, but also
> the From:, Reply-To: and Sender: headers to try and cut down on bad
> bounces.

Yeah, Exim is rather notably good in this regard.  

> will have done these checks, but checking them twice won't hurt.

This was one of the core ideas I tried to put in the forward chained
Received: header proposal.  Every node, at the time of receipt and later
can check and verify the chain.  They can do the cheap check and only
verify that the data as presented is internally consistent, or they can
verify the stated keys via DNS to authenticate their check of internal
consistency.  

Nobody has to trust, but everybody can not only distrust if they want
to, but if they don't bother checking, a later node can still isolate at
what point the trust chain was broken.

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 6 Apr 2003 21:49:29 -0400

>place of work or whatever).

First of all.  Let's back up a bit, because I missed something fundamental.

Why are we trying to get rid of bounces?

>   1) Inbound relays is a design decision.  It will have to change in

Do you have any idea what might have led that design decision?  Do 
you have a reasonable alternative?

>   4) .forwards The risks of running a bot.

Bot?  Who said a thing about bots?  My root account has a .forward to 
me.  My webmaster account at a hosting provider has a .forward to me. 
*All* of the aliases at one of my companies send to off-site 
addresses.  What, I'm supposed to run 50 different POP accounts?

>ACCOUNT (not the address) THAT SENT THE ORIGINAL EMAIL*.

Okay, so we're going to rewrite every MTA in the world so that it 
knows whether a message IN THE QUEUE was sent by an internal or 
external sender.  Because I seriously doubt any of them know now. 
They know when they *receive* the mail, but not once they have queued 
it.

Someone else already said words to this effect, but I'll repeat. 
This isn't a minor change to the protocol.  It's a fundamental change 
to the entire infrastructure.  You've changed the way everything 
works in a fundamental and painful way.  And given no thought to the 
unintentional consequences.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 6 Apr 2003 21:51:16 -0400

>So why is this so controversial?

Because it has nothing to do with UUCP. The whole UUCP thing is a red 
herring. There are lots of delayed delivery situations that can 
bounce.  A *vacation* message is a form of bounce.  A message could 
bounce after acceptance because it there wasn't enough disk space.  A 
message could bounce because it was forwarded to another machine 
which was down.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 6 Apr 2003 22:10:44 -0400

>Who needs to patch which binaries?  I use an older than ancient MUA that

Anyone running a commercial MUA that doesn't generate In-Reply-To or 
References headers.  But this was a pointless argument.  I just found 
it strange that someone was criticizing a mail-user for not 
generating those headers.  It's the MUAs responsibility, not the 
users.  And since both are recommendations, even that's putting it 
too strongly.

>line, and the only noticable false positives involve qmail.)

It's definitely an indicator (our system works almost entirely by 
looking at hints like that).  But if qmail is your only false 
positive then you need to sign up for a few more commercial mailing 
lists.  It's *way* too common with commercially generated email. 
Esp. customer support systems, automated sales notifications and the 
like.  The folks who write those things clearly don't read the RFCs. 
(And don't get me started on this new trend towards parsing email 
addresses with javascript to see if they are "valid".)
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 23:28:45 -0700

See:

  http://www.cdt.org/speech/spam/030319spamreport.shtml

Dated March 2003.

Apologies if this has been mentioned afore.

---

From: [email-masked] (Claus Färber)
Date: 07 Apr 2003 10:39:00 +0200

> while still connected, there is no adverse affect on UUCP sites.

What UUCP sites can't do is to reject messages themselves: They can only
receive them and bounce them (i.e. send them across the UUCP link twice)
or they can have their upstream site reject the messages.

Claus
-- 
http://www.faerber.muc.de/
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 7 Apr 2003 07:00:17 -0400 (EDT)

> help make sure that later bounces are not being sent to third party

Could the receiving MTA, when it must send a DSN, restrict itself to
connecting to the connecting MTA or one of its MXs? In that case a forged
envelope from would typically result in a "relay denied" rather than
sending the DSN to an innocent third party. If the envelope from was in a
domain that the connecting MX serviced, presumably it would accept and
deliver the DSN. If the spammer forged addresses in the scope of the
connecting MTA, the DSN would still go through, of course, but the burden
would be on the "legitimate" users of the MTA, which would encourage
relays to be closed and spammer's accounts to be canceled.

---

From: J C Lawrence <[email-masked]>
Date: Mon, 07 Apr 2003 12:36:52 -0700

On Mon, 7 Apr 2003 07:00:17 -0400 (EDT) 

> connecting to the connecting MTA or one of its MXs? In that case a
> forged envelope from would typically result in a "relay denied" rather
> than sending the DSN to an innocent third party. If the envelope from
> was in a domain that the connecting MX serviced, presumably it would
> accept and deliver the DSN. If the spammer forged addresses in the
> scope of the connecting MTA, the DSN would still go through, of
> course, but the burden would be on the "legitimate" users of the MTA,
> which would encourage relays to be closed and spammer's accounts to be
> canceled.

While not making it impossible, this gets interesting when a message
transits a secondary MX.  Something has to track the originating
domain/MX for the transaction -- which in turn either exposes that
tracking to spammer forgery, or suggests that a new/different/custom
transport protocol be used between MX levels which is different than is
used for base message transfer.

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 7 Apr 2003 15:52:16 -0400 (EDT)

> used for base message transfer.

Two of the objections raised in the last several messages are not
convincing. A third is more interesting.

(1) If you have some relationship with the secondary MX, and I assume you
have, you can easily tell that the Received header from it was not forged.
Therefore the IP address of the connecting host of the stranger machine
is available in the headers with some high level of confidence. The bounce
message can then be sent to that machine, or an MX for that machine
discovered through RDNS. 

(2) In answer to a previous message, RDNS always provides a host name or
an error, never a network number or subnet range.

(3) With respect to aliases, if you can't pass the message on to another
host, you can send a DSN to your connecting host with confidence that it
is the the immediate source of the message. The problem arises if the
final destination wants to reject the message. Then they have to send it
to a strange MTA that they have had no prior contact with. If they send to
the connecting machine, that machine will (unless it is an open relay)
reject the message with "We do not relay". That leaves the destination
with a choice of sending to the sender address or dropping it on the
floor. I assume most sites would chose to send to the possibly forged
address, but it might depend upon the reseason for refusing the message.
If it was because the content was spammy, it might make more sense to drop
the message on the floor. 

After all, the rationale for rejecting messages is to avoid the situation
where one has accepted a message, found it to be spam with 99%
probability, but don't want to drop it on the floor because of that final
1%. Nor do you want to issue a DSN that will go to a forged address with
75% probability. Supplying a DSN only if the sender is reachable via the
connecting machine or an MX for it seems like a reasonable compromise.