Subject: Re: [Asrg] where the message originated

From: Gordon Peterson <[email-masked]>
Date: Sun, 11 Jan 2009 15:57:07 -0600

> > For example, I might be travelling somewhere and sending e-mail 
messages
 > > from an inhabitual location:  a cruise ship Internet cafe, an Internet
 > > access kiosk above a post office location in Beijing, a coffee bar, or
 > > other such public-access location.  In such a situation, I will
 > > typically have NO control over what outgoing mail server is sending my
 > > e-mail message, and since my being there is temporary I obviously 
don't
 > > want to put a return address on my mail that would be connected 
with the
 > > location where I physically am at the time.

 > That's a hopeless setting. If you carry a laptop, SMTP+AUTH to the
company server is the way to go, as Franck said already.

That's precisely the point.  I am not using my habitual mail client, nor 
am I using my own familiar webmail service.  I am using a mail 
kiosk-type service which allows me to enter a subject, my return 
address, a to address, and the body of my mail.

 > If not, assuming you won't configure an email client, you should use 
company's webmail server.

That's not an option, and nor can I configure what e-mail server is 
being used.

 > You are not going to store your userid/password at an
unknown box, are you?

No, of course not.  And they don't ask for that.  The mail message 
doesn't go out through my normal e-mail channels, and that's just 
exactly the point.

 > Thus, you should connect to your outgoing server
in the same way that you connect to your incoming one.

Again, that's not one of the options available.

When you're travelling on a ship, understandably they want to have you 
send your mail through the ship's own outgoing mail server, since that 
minimizes the time they have to keep the (very expen$ive) satellite 
channel open.

 > > Another example is where a small company also uses a company domain
 > > name, although they might use very different mail handling for their
 > > outgoing staff e-mail messages (for example, which might go through a
 > > nearby ISP, often for historical reasons) as compared to their
 > > automatically generated e-mails (example: invoices, price quotations,
 > > EFT transfer notices, and the like) generated by their back-office
 > > accounting systems... which might be sent directly by outgoing mail
 > > servers inside their NAT router.

 > Same comments as above apply. However, for vanity addresses the
company's MX just forwards to each employee's actual address. In that
case, outgoing mail should also originate from each employee's ESP.
The company's SPF record, if any, should take that into account.

And again, that's okay, WHEN THEY ARE MAILING FROM IN-HOUSE.  When they 
are not, is when the problem turns up.

 > The historical ISP habit to allow relaying from their own IP addresses
since clients already authenticated on connecting, has had its day.

That's not really the issue.  The issue is that people occasionally have 
very legitimate need to send mail other than through their normal 
channels, PARTICULARLY when away from the office (at home, perhaps, 
although sending a mail that's work-related;  from a library or airpport 
public access terminal;  at a customer location;  and particularly when 
traveling out of the country.)

 > > We've several times been hurt by stupid antispam approaches which 
refuse
 > > perfectly legitimate e-mails because they don't like the IP address 
they
 > > are coming from.
 > >
 > > Another problem we have had is when we were sending company E-mails
 > > through the outgoing mail server provided by our domain hosting 
company,
 > > and one of the (tens of thousands) of companies they were hosting
 > > domains for apparently became infected and began sending messages
 > > containing a virus or something.  The result was that ALL the 
companies
 > > forwarding through that outgoing mail server became blocked, even 
though
 > > our company (and, I'm sure, most of the companies using that same 
shared
 > > outgoing mail server) was never infected or compromised.

 > Obviously there are the same problems when sharing cars, buildings,
and sex mates: whoever catches accidents or infections affects
everybody else...

In this case, however, the overly-broad-brush of poisoning ALL traffic 
transiting an IP address just because it has sent "some" unwanted or 
malicious mail can create a GREAT deal of serious collateral damage.

 > > While we're talking about the issue of antispam nuisances, another is
 > > the situation where a spam blocker inadvertently serves as an "IP
 > > address laundering agent" when they bounce back a message detected as
 > > containing spam, or a virus.  It is particularly stupid to bounce 
back a
 > > message because it is detected to contain a virus WHICH IS KNOWN TO
 > > FALSIFY OR COUNTERFEIT THE RETURN ADDRESS!

 > Correct. The anti-virus filter should just swallow the message with no
complains nor notices. I don't know what RFC blesses that behavior,
though.

It is very frustrating to get (sometimes hundreds a day) bounce messages 
that come back to my domain (catch-all address mailbox) for e-mail 
messages which *I* NEVER SENT, just because the spammers' From: address 
used a counterfeit/bogus e-mail address forging one of my domains.

-- 

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 11 Jan 2009 22:39:23 -0000

>address, a to address, and the body of my mail.

Yeah, it's just one more way that the bad guys have screwed up mail
for everyone else.  The trickle of mail with random to and from
addresses coming out of a mail kiosk is pretty much indistinguishable
from a zombie, so it's not surprising that they have trouble getting
mail through.  Poorly conceived path authentication systems like SPF
don't help, since they encourage people to claim that their mail can
only come from their usual server.

Assuming DKIM gets traction, I can see that kiosk vendors will sign
all their mail  with the kiosk's domain which will, with luck, get
a good enough reputation that receivers will say, oh, that's KioskCo,
their mail is OK.  (This is an example, by the way, of the reason that
finer grain reputation is not always better.)

In the meantime, if you want to send mail while you're on the road,
you better either get a laptop with a MUA configured to relay through
home, or web mail.

>That's not an option, and nor can I configure what e-mail server is 

Too bad.  I think it would be clearer to say that whoever runs your
mail system doesn't consider the problem of sending mail on the road
to be serious enough to fix.

>malicious mail can create a GREAT deal of serious collateral damage.

Quite true.  See comments above.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Jan 2009 11:58:32 +0100

John Levine wrote:
>> That's precisely the point.  I am not using my habitual mail
>> client, nor am I using my own familiar webmail service.  I am
>> using a mail kiosk-type service which allows me to enter a
>> subject, my return address, a to address, and the body of my
>> mail.

It must be noted that being able to write but not to read one's mail 
_is_ an abnormal situation, subject to severe restrictions. For one, 
it breaks any address checking scheme.

>  a good enough reputation that receivers will say, oh, that's
> KioskCo, their mail is OK.

However, anyone can write "Gordon Peterson <[email-masked]>" on
that box's return address field. Do we really want that to be signed?

Gordon Peterson wrote:
>> When you're traveling on a ship, understandably they want to
>> have you send your mail through the ship's own outgoing mail
>> server, since that minimizes the time they have to keep the (very
>> expen$ive) satellite channel open.

Nowadays there are satellite links whose costs are comparable to ADSL. 
I'd reckon broadly available MSAs is the way to go.

A somewhat similar deceptive saving occasion used to be office MTAs. 
Since most of the traffic is embodied by office-to-office messages, 
one reasoned, it is a waste to route it through an external MTA that 
requires a (possibly encrypted) leased connection. That's changed too.

Actually, most of the traffic is spam, and keeping ill-conditioned 
mail transfer habits is not going to reduce it. Using the right MSA 
for each return address allows SPF and DKIM (or other signing scheme) 
to reliably authenticate messages at their respective protocol entry 
points. That way, use of false identities will eventually be 
eliminated, and zombies with it, for the sake of real savings.

--
"The best way of dealing with change is to help create it."

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 12 Jan 2009 11:37:14 +0000

--On 11 January 2009 15:57:07 -0600 Gordon Peterson <[email-masked]> 
wrote:

>  > > want to put a return address on my mail that would be connected with
> the
> am I using my own familiar webmail service.  I am using a mail kiosk-type
> service which allows me to enter a subject, my return address, a to
> address, and the body of my mail.

So, what's to stop me using your email address as the return address in 
that kiosk? That sort of service should not be used, except with very low 
expectation of delivery. The recipient should not trust the content of the 
email.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 12 Jan 2009 11:52:32 -0000

>that box's return address field. Do we really want that to be signed?

Signed by KioskCo?  Of course.  It really did come from their kiosk.
The whole point of DKIM is that that people can reliably take
responsibility for the mail that passes through their systems,
independent of the addresses in the visible headers or the SMTP
envelope.  I have no idea what kind of anti-abuse techniques KioskCo
might use, but if they're effective, why shouldn't people accept their
mail?

My point was that if all of KisokCo's kiosks apply the same signature,
that will be a large enough mailstream that recipients can form an
opinion of how good it is, even though the stream from each individual
kiosk would be too small.

R's,
John

---

From: John Levine <[email-masked]>
Date: 12 Jan 2009 11:52:32 -0000

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Jan 2009 13:44:53 +0100

John Levine wrote:
> Signed by KioskCo?  Of course.

Hm.. I'm not much into DKIM. It technically allows to sign false 
identities, but doesn't (or shouldn't) it semantically imply that the 
signers must have some (possibly small but still positive) degree of 
trust that what they sign is correct? In that case the question is 
whether KioskCo would really want to sign that, and publish their 
slyness in their policy.

> kiosk would be too small.

Although a critical mass is a common requirement of most anti-spam 
measures, requiring some kind of threshold for each single sender is 
more of a weakness.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 12 Jan 2009 07:49:24 -0500

> traveling out of the country.)

All the more reason why operations that have such a need should plan
and build to meet it: webmail clients are accessible from almost
anywhere, and decent open-source ones are free and not particularly
difficult to set up.  Yes, this leaves out the tiny number of
people in odd situations like cruise ships, but that's an edge case.
(And surely someone who can afford a cruise can also afford a satellite
link or similar if email is REALLY that important to them.)

The days when we could freely forge our own addresses into the envelope
for convenience are coming to an end.  I don't like it much, but
it's just another aspect of the damage caused by spammers.

> malicious mail can create a GREAT deal of serious collateral damage.

1. There's no such thing as "collateral damage" because there's no such
thing as "damage" in this context.  Please review the archives of this
list from spring 2008.

2. If an address is emitting abuse, then why should anyone accept
*anything* from it, until that situation has been addressed?  (Which
includes not just fixing the immediate problem, but taking steps to
avoid a repeat occurence, and, I think, issuing a public apology
and explanation.  It's the least that people responsible for such
huge amounts of damage [1] can do.)

> complains nor notices. I don't know what RFC blesses that behavior,

Incorrect.  The receiving MTA should reject with an appropriate error
message.  While it's much more likely that a malware filter will generate
a FN than a FP, it's still possible, and an error message will be helpful
in tracking down such situations.  It might -- and I may be over-optimistic
here -- also help notify the originating site that it has a problem,
if they're paying attention to their own logs, and if they're not
doing it on purpose.

The more general principle here is that mail should never disappear into
a black hole.  (This is one reason why I've argued strongly against
quarantines, which I consider a fundamentally broken concept.)  We all
make mistakes, the systems we deploy make mistakes, routers break,
DNS fails, etc., and the best way to give ourselves a fighting chance
of diagnosing such problems is to generate appropriate error messages.
The costs of doing so are tiny, and the potential savings in wasted
human effort are large.  (Yes, I know that some horribly-broken systems
mangle carefully-generated error messages.  <sigh>)

> used a counterfeit/bogus e-mail address forging one of my domains.

This is backscatter spam, which results when improperly-configured mail
systems run by incompetent mail system administrators fail to reject and
instead bounce them to the putative sender.  Some DNSBLs will list hosts
for backscatter -- as they should, as it's just another variety of spam.
You might consider using one of those (if you're not already), and you
should definitely consider disabling all catch-all addresses, as they're
likely targets for DDoS attacks.  [2]

---Rsk

[1] I think one reasonable metric for the monetary value of damage
can be constructed by considering junk fax statutes.  Here in the US,
a single junk fax is valued at $500, amount tripled under some circumstances
(and doubled again in California).  If we consider a mail server
compromised for a brief period of time (one hour) and emitting messages
at a very low rate (1 per second to 1 user each), that's a minimum
of $1.8M in damages.  More realistic estimates easily reach into 9 figures.

[2] I don't know if there's broad community consensus on this, but I've
been routinely disabling all catch-all addresses anywhere I've been for
over a decade.  Given the huge amounts of spam being sent to never-existed
and no-longer-existing addresses, it's not only a good way to deflect a
fair amount of junk mail, it can also be useful in detecting spammers.
(The failure of some purportedly-legitimate senders to display rudimentary
mailing list management skills -- that is, to remove recipients after
a sufficient number of rejects/sufficient period of time -- is quite
annoying.  I've observed that most, but not all, "amateur" mailing lists
perform far better in this regard than supposedly-"professional" senders.)

---

From: Steve Atkins <[email-masked]>
Date: Mon, 12 Jan 2009 07:42:11 -0800

On Jan 12, 2009, at 4:44 AM, Alessandro Vesely wrote:

> identities, but doesn't (or shouldn't) it semantically imply that  
> the signers must have some (possibly small but still positive)  
> degree of trust that what they sign is correct?

No. The signature only means that the message you received was the one  
signed by the signing identity.

> In that case the question is whether KioskCo would really want to  
> sign that, and publish their slyness in their policy.
>

Any mail system that only allows mail to be sent one at a time, and  
requires that the mail be hand-typed (rather than stored in a  
signature or pasted in) and which charges for the service via a credit  
card is going to be a negligible source of abusive email.

KioskCo is definitely going to want to sign the outbound mail with  
their identity, as that identity is unlikely to get a bad reputation  
and will likely get a good reputation over time.

Worst case, DKIM signing the mail will have no effect. More likely it  
will have some positive effect at some recipients. It's a nice example  
of why DKIM signing even low volume sources of mail can be a good  
idea, if they have the resources to actually do the signing.

Cheers,
   Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Jan 2009 17:03:37 +0100

Rich Kulawiec wrote:
> in tracking down such situations.

Rejecting has been my first approach when I first installed an 
avfilter. When I realized the number of infections I was causing that 
way, I started to drop rather than reject. Since 2001, I've had a 
couple of FNs and no FP that I'm aware of. (I'm talking specific virus 
detection, not heuristic anti-malware filters.)

> It might -- and I may be over-optimistic

I have in front of me the latest instance of W32/Netsky-D I received. 
(I still dump viral messages in a system folder not readable by 
users.) It is a bounce, so in this case I could have rejected it with 
less worries. What reaction would the remote postmaster have had? I 
have difficulties in estimating the worthiness of amending my software 
so as to reject rather than drop in case the envelope sender is void.

For regular messages, rejection causes viruses to be delivered to end 
users, which is wrong because it spreads them. I don't think virus 
writers spread their original copies via their own MTAs; that is to 
say, IMHO MTAs are not doing it on purpose. However, I assume the 
remote MTA has no avfilter, otherwise it wouldn't relay viruses. Most 
probably, on rejection it will attempt to deliver a bounce. Failure to 
do so would result in the same net effect as dropping; so let's 
consider only infected bounces that are successfully delivered to end 
users: what are the chances that one of them results in an alert 
rather than yet another infection? Let's over-optimistically estimate 
we can get 1 alert for every 10 new infections. I don't deem that is 
anywhere near a desirable outcome. If I were a judge I would condemn 
postmasters wittingly doing so.

> a black hole.

Agreed. A virus should be caught right after the client submits it. 
Reject vs. drop has a different meaning in this case: diagnosing an 
infected client should sound all available whistles and bells in 
either case.

For relayed infected stuff, feedback loops may be a valid alternative 
to the black hole. However, zombie detection is not a topic restricted 
to email management.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 12 Jan 2009 08:27:20 -0800

Steve Atkins wrote:
>> trust that what they sign is correct?
> 

Not quite right.  Or rather, not quite complete.  And I'm compelled to pick this 
nit, since it is fundamental to discussion about DKIM's purpose.

What you've described is a data integrity function.  Yes, DKIM performs that on 
the portions of the message it lists in the DKIM-Signature: header field. 
However, data integrity is a side-effect of DKIM and not it's actual purpose.(*)

It's purpose is:  "DKIM allows an organization to take responsibility for 
transmitting a message, in a way that can be validated by a recipient. "

So the requirement on the signer is to choose naming granularity and use that 
will provide the recipient with a stable label of a message stream.

The receiver is supposed to take the identifier being proffered by the signer 
and run it through an assessment process.

Presumably, a fake or transient or new identifier is likely to get far less 
trust than one with a track-record.  As noted, the intended benefit of DKIM is 
across a message stream, with the identifier being used to label that stream 
consistently.

d/

(*)  In fact, one can argue that DKIM doesn't perform data integrity all that 
well, to which the response is that that's ok, it does it well enough for 
validating the use of the identifier.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Jan 2009 17:30:52 +0100

> signed by the signing identity.

Thanks for the clarification.

> requires that the mail be hand-typed (rather than stored in a signature 
> or pasted in) and which charges for the service via a credit card is 
> going to be a negligible source of abusive email.
> 
> KioskCo is definitely going to want to sign the outbound mail with their 
> identity, as that identity is unlikely to get a bad reputation and will 
> likely get a good reputation over time.

Wouldn't then make more sense to just sign, say, the date and the 
message-ID?

Besides malicious abuses, typos are also a possible source of 
confusion for end users. Considering that perhaps one day it will be 
possible to read the correct email address from the payment card, if I 
were KioskCo, I would avoid to sign From headers I don't trust, unless 
specifically required by DKIM or related BCPs.

[N.B. "KioskCo" in this thread is understood as an example name, not 
related to possibly existing companies bearing the same name.]

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 12 Jan 2009 12:14:22 -0500

On Mon, Jan 12, 2009 at 05:03:37PM +0100, Alessandro Vesely wrote:
> Rejecting has been my first approach when I first installed an avfilter. 
> When I realized the number of infections I was causing that way, I 
> started to drop rather than reject. 

I'll probably have more to comment on in your message, but I stopped
here because I'm confused and puzzled, and could use some clarification
on what you mean by "infections...[you were] causing".  I don't understand
how issuing an SMTP reject could cause an infection; wouldn't doing so
be the equivalent of telling an already-infected host "you're infected"?

Could you expand on what you mean by this?

---Rsk

---

From: der Mouse <[email-masked]>
Date: Mon, 12 Jan 2009 12:42:59 -0500 (EST)

>> avfilter.  When I realized the number of infections I was causing
>> that way, I started to drop rather than reject.
> [I] could use some clarification on what you mean by
> "infections...[you were] causing".  I don't understand how issuing an
> SMTP reject could cause an infection; wouldn't doing so be the
> equivalent of telling an already-infected host "you're infected"?

Well, I didn't write it.  But I interpreted it as, basically, this
scenario:

- Malware goes out, addressed to A, (forged) envelope-from B.  Sending
   channel ends up emitting it from a normal MTA, M.

- A's MX host rejects it at SMTP time.

- M generates and sends a bounce to B.

- B receives bounce with embedded malware.  Somehow - perhaps B's MUA
   aggressively looks for and executes live content; perhaps B clicks
   on the wrong thing; perhaps something else - this ends up with a
   malware infestation on B's machine.  (Cue xkcd #350.)

If A's MX host had silently swallowed the mail, nothing would have
happened to B - or, at least, not on account of this message.  (This is
not to say that _I_ think it's fair to say that A's rejection caused B
to get infected.  Just that this is what I think Alessandro meant.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Mon, 12 Jan 2009 10:04:45 -0800

On Jan 12, 2009, at 8:30 AM, Alessandro Vesely wrote:

>> No. The signature only means that the message you received was the  
>> one signed by the signing identity.
>
>> signature or pasted in) and which charges for the service via a  
>> credit card is going to be a negligible source of abusive email.
>> their identity, as that identity is unlikely to get a bad  
>> reputation and will likely get a good reputation over time.
>

Yes, absolutely it would...

... except for replay attacks.

DKIM is intended to allow the recipient to reliably identify the  
signer of the message they receive. (It intentionally differentiates  
between "signer" and "sender".)

Defining "the message" is important. Anyone can take a signed message,  
and modify any part of the content that wasn't signed, and resend the  
modified message and it will still be validly signed by the original  
signer. For example, if my bank only signed the date and message-id  
then I could take legitimate mail they sent me, replace the body of  
the message with a phish and send it out, and it would still appear  
validly signed by the original signer (the bank).

That's why DKIM (when used correctly, anyway) is also used to  
demonstrate that important recipient-visible parts of the message  
(such as the body and the subject line) haven't been modified since  
the message was signed. (There are other possible ways to avoid replay  
attacks, but DKIM chose - for good reasons, I think - to use this one).

> possible to read the correct email address from the payment card, if  
> I were KioskCo, I would avoid to sign From headers I don't trust,  
> unless specifically required by DKIM or related BCPs.

I suspect that KioskCo would just sign the entire message - but the  
reasons for that are long, vague and not terribly interesting.

> related to possibly existing companies bearing the same name.]

Yup.

Cheers,
   Steve

---

From: Franck Martin <[email-masked]>
Date: Tue, 13 Jan 2009 08:03:39 +1200 (FJT)

I have run a series of tests, where I sign a message (sent by me) but with only the Return-path containing my domain (DKIM does not sign the return-path as recommended in the spec).

I used the DKIM reflectors on www.dkim.org

and the assessment I got was: neutral (none of the signed field contain the domain of the signer).

like if it is wrong.

I think it should be a pass. I fear that many people that verify DKIM make the same mistake.

I'm thinking of adding an X-header that will contain my domain and sign it via DKIM and see if the reflectors are happier.

----- Original Message -----
From: "Dave CROCKER" <[email-masked]>
To: "Anti-Spam Research Group - IRTF" <[email-masked]>
Sent: Tuesday, 13 January, 2009 4:27:20 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the message originated

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Mon, 12 Jan 2009 12:24:24 -0800

> I think it should be a pass. I fear that many people that verify DKIM make the same mistake.

   Note that this not about DKIM but about SSP/ADSP and Authentication-Results.
   I believe that the SSP/ADSP result should be neutral, but that the DKIM
   result is "pass". A lot of the reflectors haven't been updated for quite a
   while, and the earlier drafts of Auth-Res didn't make a distinction between
   DKIM and SSP/ADSP. So, true to form, differing implementations did differing
   things in the face of the ambiguity.

> I'm thinking of adding an X-header that will contain my domain and sign it via DKIM and see if the reflectors are happier.

   I _think_ that my reflector does the right thing in that it separates out the
   dkim results from the ssp results, but I'm pretty sure that it's out of date
   wrt both the new auth-res draft and the adsp draft.

   In either case, an X-header isn't going to change anything. The ADSP part is
   always keyed of of the real live From address.

		Mike

---

From: Franck Martin <[email-masked]>
Date: Tue, 13 Jan 2009 08:51:20 +1200 (FJT)

I'm curious when you say ADSP is always keyed of the real live From address? You talk about the From: and not the Mail From: (Return-path)?

as a side note, all this SSP/ADSP processing looks like a blackbox (or black magic) to me. There is no recommended practices and no one explain what they do to filter mail. like in the statement "AOL will use DKIM to do build reputation based on domain", what does it mean?

We know well about spamassassin, DNSBL, DCC but this is about it. I thought security by obscurity was a bad idea? ;)

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Anti-Spam Research Group - IRTF" <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, 13 January, 2009 8:24:24 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the message originated

		Mike

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 12 Jan 2009 13:15:25 -0800

Franck Martin wrote:
> I have run a series of tests, where I sign a message (sent by me) but with
> only the Return-path containing my domain (DKIM does not sign the return-path
> as recommended in the spec).

DKIM has nothing to do with the rfc5321.MailFrom address or anything else in 
SMTP.  It is a message-level mechanism, not transfer-level.

The dkimbase signing specification's reference to return-path cautions *against* 
including it as part of the signature data.

What are you referring to about "as recommended in the spec"?

d/

-- 

   Dave Crocker

---

From: Franck Martin <[email-masked]>
Date: Tue, 13 Jan 2009 09:20:50 +1200 (FJT)

yes, that part, dkimbase reference to not include return-path as part of the signature data, because it is likely to be modified during transit.

----- Original Message -----
From: "Dave CROCKER" <[email-masked]>
To: "Franck Martin" <[email-masked]>
Cc: [email-masked], "Anti-Spam Research Group - IRTF" <[email-masked]>
Sent: Tuesday, 13 January, 2009 9:15:25 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] where the message originated

d/

-- 

   Dave Crocker

---

From: "Robert Barclay" <[email-masked]>
Date: Mon, 12 Jan 2009 15:37:52 -0700

On Mon, Jan 12, 2009 at 1:51 PM, Franck Martin <[email-masked]> wrote:

> I'm curious when you say ADSP is always keyed of the real live From
> address? You talk about the From: and not the Mail From: (Return-path)?

 Yes, the A is for Author. ADSP is built on top of DKIM and allows domain
owners to specify that they sign some or all mail using a specific domain in
the From: address

>
>
> as a side note, all this SSP/ADSP processing looks like a blackbox (or
> black magic) to me. There is no recommended practices and no one explain
> what they do to filter mail. like in the statement "AOL will use DKIM to do
> build reputation based on domain", what does it mean?

It means they are going to start establishing reputation for DKIM domains
based on the DKIM signed mail passing through their systems. This isn't any
more of a black box than their existing reputation systems.
As for recommended practices I'm not sure there's enough operational
experience is most situations to have anything useful to recommend yet. I
would be pleased to be wrong here but suspect that we may be starting to get
there for some uses of DKIM and are a long way away from that with ADSP.

> security by obscurity was a bad idea? ;)

Not sure this qualifies for security by obscurity. It's pretty
straightforward how all these technologies work. How people make use of the
data these technologies provide, that only seems obscure because people are
still figuring it out themselves. Compare this to how people use IP
addresses there's a pretty wide variety there and a lot of those uses would
qualify as "obscured" from outside users too.

> > I have run a series of tests, where I sign a message (sent by me) but
> with only the Return-path containing my domain (DKIM does not sign the
> return-path as recommended in the spec).
> >
> > I'm thinking of adding an X-header that will contain my domain and sign
> it via DKIM and see if the reflectors are happier.
>

---

From: John Levine <[email-masked]>
Date: 13 Jan 2009 00:43:41 -0000

> So, what's to stop me using your email address as the return address
> in that kiosk?

Technically, nothing.

In practice, it's a pretty poor way to defame people or send spam,
particularly if it's the kind of kiosk where you pay with a credit
card so there is an extremely reliable audit trail should someone take
offense.

Keep in mind that any kind of security is a tradeoff, and in this case
the tradeoff sure looks like a kiosk will send send mail that people
people want, not spam.

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 13 Jan 2009 08:49:26 -0500

> to get infected.  Just that this is what I think Alessandro meant.)

Ah, gotcha.  I agree that silently swallowing the message might have
spared B a possible infection, but I'm reluctant to blame A's MX for
this: it didn't originate, accept or transfer the malware-laden message.
I think responsibility lies with M, and/or with whatever system passed
the message to M (presuming the message didn't originated on M).

While this is a less-than-desirable outcome, I think it may be the best
we can do -- we can't block something before we see it, we can only do
our best to reject outright spam/malware/junk traffic at the earliest
available opportunity.  (One of the ways I've expressed this elsewhere
is that the best place to stop spam is as near its source as possible.
The farther it gets from the origin, the trickier detecting it gets,
and the greater the possible consequences.)

---Rsk

---

From: Dotzero <[email-masked]>
Date: Tue, 13 Jan 2009 09:11:55 -0500

> card so there is an extremely reliable audit trail should someone take

Given the amount of CC information floating around at relatively low
cost to people with ill intent, I would not rely on "an extremely
reliable audit trail". It will take you to a p0wn3d person in an
extremely reliable way.

> the tradeoff sure looks like a kiosk will send send mail that people

I don't have enough experience with mail kiosks (I've never used one
in my life and haven't noticed receiving from one - and yes, I do tend
to look at headers) to make an assertion one way or the other
regarding people wanting mail from kiosks. What do you base your
assertion on John? Not meaning to be combative, actually looking for a
data point.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Dotzero <[email-masked]>
Date: Tue, 13 Jan 2009 09:24:10 -0500

On Mon, Jan 12, 2009 at 10:42 AM, Steve Atkins <[email-masked]> wrote:
>
>
> Any mail system that only allows mail to be sent one at a time, and requires
> that the mail be hand-typed (rather than stored in a signature or pasted in)
> and which charges for the service via a credit card is going to be a
> negligible source of abusive email.
>
> Worst case, DKIM signing the mail will have no effect. More likely it will
> have some positive effect at some recipients. It's a nice example of why
> DKIM signing even low volume sources of mail can be a good idea, if they
> have the resources to actually do the signing.
>

Steve,

You assume the integrity of the KioskCo environment. That is not
necessarily a safe assumption to make. I will grant you that KioskCo
MIGHT be aggressive in responding to it's hosts being subverted. On
the other hand it may not. If blocking or discard of mail originating
from KioskCo is in effect, even for a short time, the individual using
that kiosk to send mail well may suffer the consequences of using a
mechanism with unknown security standards.

Just a thought.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Jan 2009 17:22:16 +0100

Rich Kulawiec wrote:
>> happened to B - or, at least, not on account of this message.
> 

A's MX knows that M lacks effective anti-virus filtering. Hence, 
through inaction, it allowed a human being to come to harm. That 
obviously breaks the first law.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 13 Jan 2009 12:53:50 -0500

On Tue, Jan 13, 2009 at 05:22:16PM +0100, Alessandro Vesely wrote:
> A's MX knows that M lacks effective anti-virus filtering. Hence, through 
> inaction, it allowed a human being to come to harm. That obviously breaks 
> the first law.

But none of this is necessarily true.

	- While I'm not overly conversant in the nuances of anti-virus
	systems (I prefer to use operating systems relatively unaffected
	by them) I'm under the impression that there's wide variability
	in the detection of various strains by different AV products.
	So it might not be the case that M lacks effective anti-virus
	filtering; it may well be the case that A's MX was simply fortuitous
	enough to be presented with a specimen that it detected while
	M did not.  It may even be the case that this is the exception
	to the rule -- that is, that M's virus detection is in fact
	markedly better than that at A's MX, but the latter simply got lucky.

	- Add to the discussion above the dependency of many (most?)
	anti-virus products on signature databases which must be updated
	rather frequently in order to deal with fast-propagating malware.
	It may be the case that M is in fact running the same anti-virus
	product as A's MX, but is mere minutes behind in updating.

	- A human being won't necessarily be harmed by this.  For starters,
	there's no way to know that the message will be delivered.  If the
	putative sender is elsewhere, then the mail system there might
	detect and reject the message.  The putative sender's mail client
	may be using an anti-virus product that detects it.  Or the putative
	sender may never "open" the message (which seems to effectively
	defuse most, but not all, of these problems).

	- Or the putative sender may not be running a mail client that's
	easily hijacked by malware or may not be running an operating system
	that's so brittle.  (e.g.: mutt on OpenBSD.)

There are still more variables in play here, but I think this is enough to
illustrate why attempting to guess at them is futile.  It's best to just
reject the message and content yourself that (a) you've done all you can do
(b) you've emitted a reasonable diagnostic message in case this is a goof
(c) you've minimized the amount of SMTP traffic you're emitting -- a key
factor and (d) you've done something that passes the "what if everyone
did this?" test, another key factor.

---Rsk

---

From: David Wilson <[email-masked]>
Date: Tue, 13 Jan 2009 18:17:53 +0000

On Tue, 2009-01-13 at 12:53 -0500, Rich Kulawiec wrote:
>   It's best to just
If by "reject" you mean "give a 5xx response to the data from the SMTP
client, the problem with that is that, as previously discussed, the SMTP
client server may generate a DSN or similar which returns the infected
message. It does not know that the reason for non-delivery was the
suspect message content. You do. So the only safe responses are:
- discard the message (i.e. accept it over SMTP and then throw it away
with no further processing, apart from possible archiving).
- send a DSN or similar which suppresses return of content.

In the old days you could get messages which contain inadvertently
infected attachments (e.g. in the days of Word macro viruses). I would
think that the fraction of infected messages which are like this is
negligibly small. So, no-one needs to know that the message is being
non-delivered, so discarding the message is the best policy.

David

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 13 Jan 2009 15:22:46 -0500

> obviously breaks the first law.

A's MX didn't generate _any_ virus-laden email.  It just 550'd.  The
originator did, and M's mailer is complicit by constructing a new email
(the bounce) that contains the virus-laden email.

A knows its filtering isn't perfect and that every rejection is a
potential FP.  So, the rejection is the best way to ensure that the
appropriate party (if any) is notified.  Blackholing would violate the
first law.

M _should_ know that best practise is now to ensure that the recipient
of the bounce knows enough to know what email bounced, and should
truncate the email to that minimum.  Eg: original recipient, sender (the
recipient of the bounce), date, subject, and perhaps a few other
snippets.  A very large proportion of MTAs now do that by default.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 13 Jan 2009 15:36:42 -0500

> - send a DSN or similar which suppresses return of content.

I've got serious problems with both of those.

In the first case, you're telling the sending server one thing and
doing another.  I don't think that's a good idea on two levels:
at a philosophical level, this seems like a bad way to run an Internet.
At a practical level, doing so fails to alert the sending site that
they may have a problem.  (Yes, I'm presuming that they're paying
attention to their own logs...or that they will be more inclined to
do so when they notice 86,000 5xx error messages in them.)

In the second case, generating DSNs is a bad idea in general [1],
but it's a REALLY bad idea as a response to spam/virus messages.

Look, I understand the motivation, and it's very noble, but it's
also pointless.  A hypothetical virus relying on this method of
propagation will also have many other -- many other SIMPLER --
ways of delivering itself to the very same targets.  The best that
anyone external can do is (a) don't propagate the problem further
(b) communicate via appropriate use of SMTP that there's a problem
and (c) don't make the problem worse or more complicated or more obscure.

---Rsk

[1] It's not that hard to engineer mail architectures -- including
distributed and multi-tier architectures -- that always reject and
never bounce.  Yes, there are always edge cases to be dealt with,
but making them exceptions and not the rule makes it easier to
then minimize the occurence/duration of those exceptions.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: David Wilson <[email-masked]>
Date: Tue, 13 Jan 2009 22:38:02 +0000

> then minimize the occurence/duration of those exceptions.

I'm not sure what you are saying should be done. If you reject from an
SMTP MTA (not a submitting UA) using a 5xx response, what is that MTA
going to do: generate some kind of non-delivery message. Normally, that
includes the message which was non-delivered, which the rejecting MTA
knows to be malicious. In order to prevent that, we need a status code
which means "I am not receiving this message because it has a content
which is dangerous". SMTP does not have such a status code.

(We are not talking about spam here, which is a different case, we are
talking about infected messages.)

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 13 Jan 2009 20:38:02 -0500

> which is dangerous". SMTP does not have such a status code.

Yes, I know.  (And while I recognize that having such a status code
might help solve some problems, it would also open others.  Among other
things, "malicious" isn't universal.  And anti-virus software does not
have a 0% FP rate.)

What I'm saying is that the recipient MTA should just 5XX the message
and hang up.  [1] That's all it can do without either (a) making the problem
worse and/or (b) redirecting the problem and/or (c) doing something
very broken like claiming to accept a message and then /dev/null'ing it.

There's no way to "fix" the presenting MTA, if we agree for the sake
of argument that it's broken.  There's not even any way, with the limited
information available during the SMTP conversation, to figure out *how*
it's broken.  Maybe it's an open relay; maybe it's not but is relaying
a virus from an already-infected user; maybe it itself is infected;
maybe a kazillion other things.

So the best course of action is that which contains the damage, doesn't
break anything else, minimizes SMTP traffic: 5XX it and move on.  There's
no way to know what the consequences will be on the presenting side --
maybe none, maybe some, maybe a lot -- so there's no point in guessing.
At least the 5XX gives the presenting side a "heads up", if they're
paying attention, that something's amiss.

---Rsk

[1] If the problem repeats incessantly or rapidly, maybe 4XX'ing
everything for a while would be in order.  In some cases, refusing
the incoming connection might be appropriate.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: David Wilson <[email-masked]>
Date: Wed, 14 Jan 2009 09:24:45 +0000

On Tue, 2009-01-13 at 20:38 -0500, Rich Kulawiec wrote:
>   And anti-virus software does not have a 0% FP rate.)
> 
I would be interested to know what actual numbers for, or perhaps some
specific instances of, FP from anti-virus.

I would be surprised if a non-malicious message would fall foul of AV
software unless it contained some kind of executable content. It should
not be surprising that a message with executable content runs into
problems.

FN rates for AV are non-zero, particularly in the few hours after the
appearance of a new variant, when the different AV folk are updating
their signatures, and the users are downloading them. So it is sometimes
not surprising that one MTA finds a virus in a message from another MTA
which is doing AV, but the message just hit it in a unfortunate window.

---

From: John Levine <[email-masked]>
Date: 14 Jan 2009 12:01:55 -0000

>not be surprising that a message with executable content runs into

When I catch a virus and the sending IP is one for whom I have a known
contact address, I send off an autoreport with the first 50 lines of
the virus (in case they're wondering what virus it is), and the first
line of the base64 of the virus denatured with xxxx so that even if an
overenthusiastic Windows MUA were to try to run it, it wouldn't start.

Nonetheless, I have problems all the time with my reports being
rejected by poorly written virus filters.  In one case they've been
adding me to a virus sending blacklist, telling me that even though
they know I'm not sending viruses, their AV detects it so it must be
my fault.  Sheesh.

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 14 Jan 2009 08:50:57 -0500

> specific instances of, FP from anti-virus.

As more and more AV packages are being (incorrectly, in my opinion)
taught how to recognize phishes, I'm seeing more and more FP rejects
of *discussions* of phishes.

Like John, I've seen rejects based on partial virus-related content -
in some cases, apparently based on string matches.

But it is axiomatic that all anti-virus (and anti-spam) systems have
nonzero FP and FN rates (with the exception of the edge cases "reject all"
and "accept all").  Given that we know we will make these mistakes,
we need to consider how we can make them visibly, so that we give
ourselves and everyone else a reasonable chance of observing and
correcting them.

---Rsk

---

From: SM <[email-masked]>
Date: Wed, 14 Jan 2009 07:56:34 -0800

>the virus (in case they're wondering what virus it is), and the first

[snip]

>they know I'm not sending viruses, their AV detects it so it must be

You also get that kind of reply (if detectors says so, then it must 
be true) about spam.

>not be surprising that a message with executable content runs into

The usual document formats (PDFs, .doc, etc) are also scanned for 
viruses nowadays.  They can fall foul of Anti-virus software.  The 
report (see first paragraph above) would have helped in identifying 
problems if the postmaster actually cared about mail delivery.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Jan 2009 18:12:23 +0100

Can we draw any conclusions from that thread?

Rich Kulawiec wrote:
> might help solve some problems, it would also open others.

599 Bounce to postmaster. What would be wrong if it existed? (I mean, 
besides how hard it would be to reliably introduce it now.)

> Among other things, "malicious" isn't universal.  And anti-virus software
> does not have a 0% FP rate.)

I agree it cannot be 0%, but better than 0.000001% is expected. See 
e.g. http://www.sophos.com/support/knowledgebase/article/35504.html. 
It is also false that any executable content is likely to be reported 
as infected: the same AV software is used to scan hard disks, looking 
at executables only. (I'm not saying the same reliability cannot be 
reached for phishing or spam, though.)

Chris Lewis wrote:
> Our experience, issuing 55x at levels of 250,000-1,300,000 per day since
> 1997 indicates exactly the reverse. [...] Silently dropping emails would
> mean that those dozen or so FPs would go unnoticed by anyone.

A dozen at those levels is more than 0.001%. It seems very poor. What 
AV/config do you use? Perhaps, at that percentage I would do the same. 
The reliability I experience reliefs me when I violate the SMTP 
protocol by dropping messages. Since I have to err, I try and minimize 
damages.

Curiously, some viruses (e.g. Netsky) directly produce a bounce. 
Possibly, their authors reasoned that since there are brain damaged 
MUAs that conceal the body of DSNs but not the attachments, an 
attachment in a DSN has better probabilities of being opened. As a 
matter of fact, some virus variants have been surviving autonomously 
for years, which suggests that that reasoning was correct.

Bounce addresses are extremely likely to be spoofed. Sending 
disinfected bounces is hardly an option. At any rate, even when it is 
not spoofed, the author of a message is not always the right recipient 
for a technical report. Besides malware, SPF or DKIM rejections are 
difficult to understand and impossible to fix for end users.

MTAs strive to only produce bounces for messages that they have 
accepted for relay from their legitimate users. However, in some cases 
that's not possible. Forwarding comes to mind. Also, rfc5321 mandates 
no AV filter, thus the much exemplified virus-relaying MTA is 
perfectly legal.

Why don't we have a meta channel for those cases? Some bounces should 
be sent to postmasters, who can then send more meaningful DSNs, 
possibly after seeking the relevant message-ID in their logs, and fix 
the problem. I don't think sending to <[email-masked]> would 
make much sense, there ought to be a better mechanism...

---

From: Franck Martin <[email-masked]>
Date: Thu, 15 Jan 2009 06:45:06 +1200 (FJT)

I block a number of file extensions (all of which could contain a payload). I'd like to block doc attachments but they are a bt everywhere. I advice people to send as pdf (internally we usually don't do much than print/or read external documents) or to rename the extension. At least there is a not straight forward process, whihc gives an extra 5picosecond for people to think if it is a virus or not.

----- Original Message -----
From: "SM" <[email-masked]>
To: "Anti-Spam Research Group - IRTF" <[email-masked]>
Sent: Thursday, 15 January, 2009 3:56:34 AM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] virus detectors, was where the message originated

[snip]

Regards,
-sm

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 15 Jan 2009 10:45:25 -0500

> besides how hard it would be to reliably introduce it now.)

I think -- even if there was widespread concurrence that it's a great
idea -- "years" would be the timeline.

And I'm not sure it's advisable or even worth it.  Let me explain:

I tend to loosely group mail system operators into two ad hoc categories:
the first read "postmaster" mail, examine their inbound/outbound logs,
run statistics on them, note anomalies, investigate them, and are pretty
much invisible to me because their system are rarely, if ever, a problem.
The second don't have a working "postmaster" address, pay no attention to
their logs, complain vociferously when [correct] allegations of problems
are made, and as a consequence, are a major irritant.

Those in the first group are likely to know before you need to
tell them.  They'll note an unusually high number of 5XX responses
to outbound traffic, investigate, and figure it out.  Those in the
second group will ignore you (most likely) or deny the facts,
or accuse you of some malicious act, or something less pleasant.

So there's little need to tell the first and little point in telling
the second.

> I agree it cannot be 0%, but better than 0.000001% is expected.

I think that's hopelessly optimistic in real-world settings.  I routinely
see a handful of FP's every month -- then again, I tend to send out mail
talking about spam and phishes and so on, which most people don't.
Also see Chris's excellent explanation, which I think is roughly
typical of that at many large sites (it's certainly similar to the
large sites I've worked on).

Besides: AV vendors issue incorrect signatures, people misconfigure
their mailers (I've seen multiple instances of reversed tests), networks
fail, routers hiccup, DNS botches, and so on.  There are so many things
that go wrong that our only chance at diagnosis and repair relies on
appropriate error messages.

> Why don't we have a meta channel for those cases? Some bounces should be 
> sent to postmasters, who can then send more meaningful DSNs, possibly 
> after seeking the relevant message-ID in their logs, and fix the problem. 

Bounces are a bad idea because they add still more SMTP traffic, they
can easily be abused to conduct DDoS attacks, and because of the
situation outlined above.

---Rsk

---

From: David Wilson <[email-masked]>
Date: Thu, 15 Jan 2009 16:37:28 +0000

> situation outlined above.

Something on which we are agreed!

However, what I have been saying is that rejecting using 5xx will
generate a bounce if the reject is sent as a response to an intermediate
MTA.

If the message is very likely to be dangerous, rather than just
inconvenient, any bounce containing the message is itself dangerous. No
doubt, most such dangerous messages come directly from some compromised
PC, and a 5xx response will not give a bounce. But there will be some
proportion which come via an intermediate MTA, which will.

---

From: David Wilson <[email-masked]>
Date: Thu, 15 Jan 2009 16:56:50 +0000

> large sites I've worked on).

If I read Chris' message, then I believe that he is not giving evidence
for AV false positives. He does not trust AV software, so the rejects
quoted are for *all* filtering (presumably various kinds of anti-spam,
as well as AV scanning) and the false positives quoted are for reports
he gets back from rejects (many of which I suspect are seen by the user
in a bounce generated from the MTA which received the reject). So there
is actually no data here on specifically AV false positives, they are
data on false positives from the overall filtering system.

If someone discusses the nature of spam messages or phishing messages
via email, I would think that false positives are not surprising;
annoying, but not surprising. After all, one can be sending a message
containing precisely the kind of thing filters are attempting to detect.
So, I would say that there is a class of positives which should not
count against the detection mechanism.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Jan 2009 19:38:17 +0100

> idea -- "years" would be the timeline.

Yup, that's why I said "if it already existed".

> [attentive vs. lame postmasters dissection dissertation]

Yet, attentive postmasters are not omniscient. They need a data feed.

> I think that's hopelessly optimistic in real-world settings.

Not for an AV filter. People routinely scan their hard disks with AV; 
perhaps they miss some viruses, but no legitimate software is 
quarantined. Obviously bugs exist, and FPs are a particular kind of 
bug for an AV package. I never saw one, but each AV vendor should have 
a list of open issues, and possibly also of the closed historical records.

SMTP implementation also have bugs. However, when discussing the 
protocol we take it for granted that they can be fixed.

> large sites I've worked on).

Chris said their filter is not able to distinguish viruses from 
generic malware. Otherwise, for viruses they could issue a "599 Don't 
bounce this dangerous content to the user" after data transfer, if 
that code existed...

> appropriate error messages.

Having an appropriate error message is not enough. It is also 
necessary to deliver that message to the right operator. Delivering 
error messages to end users may be counter productive. For a non-viral 
example, what can users do if their mail is bounced because of bad 
DKIM signatures?

> situation outlined above.

That's exactly why I proposed a meta channel: to direct error messages 
  to someone who can act appropriately.

Some large sites have established feedback loops whereby a message is 
"bounced" to some postmaster. Apparently, they are mainly meant for 
"this is spam" actions. However, the ARF format (quite similar to DSN) 
provides fields for reporting bad DKIM signatures. I don't know at 
what level such bounces could be generated. It is technically possible 
to generate them right after the data transfer, just like for viral 
content. If we recognize that viruses are a problem, don't they 
deserve using that meta channel as well? This leaves us wondering how 
can such a meta channel be established for small and medium sites as 
well...

---

From: SM <[email-masked]>
Date: Thu, 15 Jan 2009 10:52:51 -0800

At 09:12 14-01-2009, Alessandro Vesely wrote:
>599 Bounce to postmaster. What would be wrong if it existed? (I 
>mean, besides how hard it would be to reliably introduce it now.)

There was a discussion about enhanced error codes where having a code 
conveying the reason for rejection was proposed.  The idea was rejected.

Regards,
-sm

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 15 Jan 2009 15:47:22 -0500

> Yet, attentive postmasters are not omniscient. They need a data feed.

It's called "their own log files".  Those who do not pay attention to
what's in them are highly unlikely to pay attention to anything else.

> Having an appropriate error message is not enough. It is also necessary 
> to deliver that message to the right operator. Delivering error messages 
> to end users may be counter productive. For a non-viral example, what can 
> users do if their mail is bounced because of bad DKIM signatures?

Nothing.  Again, it's up to mail system administrators to read their
own log files and act (if necessary) on what they find.  I would
think a log file full of SMTP rejects with "Hey, your DKIM signature
is wrong" would get their attention.  If not -- hey, if they don't care,
why should anyone else?

> to someone who can act appropriately.

But there's no point in going through all the debate and design
and implementation and deployment effort associated with this.
The same people who are presently ignoring their own log files
will ignore this too.

A much easier way to reach that subset of postmasters who are actually
paying attention is to use appropriately verbose messages in rejection
messages.  For example:

	message rejected

isn't nearly as helpful as

	message rejected; our antivirus scanner detected Blottosplang; contact [email-masked] if you believe this is an error and reference case 1234abcde

where of course [email-masked] is unfiltered and forwards to the
mailbox(es) of the right people.  It also changes periodically because
not only will it be harvested by spammers and targeted, but because
every now and then someone's truly broken system will spew a backlog
of several hundred no-longer-relevant messages at it.

This is a better method because (a) it avoids generating more SMTP
traffic (b) it's much harder to game and (c) it caters the most to
the people who are paying the most attention: those who are monitoring
their mail server logs in real time and (d) it utilizes what we already
have without the need to invent or deploy new technology.

There *are* issues with it: for example, information leakage (do you
really want to tell the world *which* virus scanner you're running?) and
non-standardization of error messages, for starters.  But the former
is addressed by some judicious local choices, and the latter with Perl.

---Rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 15 Jan 2009 15:50:52 -0500

> generate a bounce if the reject is sent as a response to an intermediate

And what I've been saying is that this is an insignificant issue in reality.

"Intermediate" MTAs, in the sense of MTAs _other_ than the sender's or
recipient's perimeter/internal servers are insignificant in the scheme
of things.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 15 Jan 2009 16:04:40 -0500

David Wilson wrote:
> for AV false positives.

That wasn't my point.  My point was directly as to the "hazard" of
550-rejecting viruses.  In that, despite having 550-rejected millions of
viruses (1.3M Mydooms/day at peak), we haven't, in 11 years, heard of
_one_ virus bounced by a MTA receiving one of our 550's landing in
anyone's lap, let alone infecting anyone.

That even if somehow blaming a virus on us for a 550 is extremely
unlikely, that out of 10's of millions of real viruses being rejected,
we would have heard of at least _one_.  But we haven't.

Thus, the hazards of 550'ing viruses are vastly overblown.

Furhermore, since virus-intended rules aren't FP-free, the hazard of
losing the DSN on a FP is far higher than the largely non-existent
hazard of 550-ing a virus.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 15 Jan 2009 16:17:31 -0500

Alessandro Vesely wrote:

> generic malware.

That should be read to mean "not in general", as opposed to "never".

> necessary to deliver that message to the right operator.

Thus becoming a DDOS vector.

> can such a meta channel be established for small and medium sites as 

Thus becoming a DDOS vector.

Went through this conversation on another list recently.

It is technically possible (in fact trivial in many cases) to instrument
a MTA to automatically generate and send ARF in real time.  Even
assuming that the MTA can figure out the _right_ place to send the ARF,
it becomes a WMD.

Imagine, if you will, everybody did it.  Some moderately sized site gets
a reasonably prolific (single) infection, and spews out a few million
viruses.  You're expecting the site's MTAs to handle a few million ARFs,
when only one _should_ suffice.

If broadly implemented, it'd cause global meltdown.

God help us all if the site receiving the ARF somehow doesn't recognize
it as ARF, and replies with its own ARFs.  Or, if the virus writer
figures out a way to get the ARF generators to send it to the wrong
place - believe me, they'd be trying...

ARF is good stuff.  But only insofar as there is limitations on how it's
emitted/deployed.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Franck Martin <[email-masked]>
Date: Fri, 16 Jan 2009 09:42:52 +1200 (FJT)

Well, any way to modify SMTP to still send ARF reports without taking down the whole Internet?

Speaking out loud, a new capability in ESMTP, that would advertise the reception of ARF report, or a special mailbox standard on all MTA to accept ARF reports. We have postmaster, abuse, why not ARF?

Or may be send this ARF report to a DNSBL service? After Authentication, it would place the original sender in a DNSBL stopping other from receiving further infected emails?

Cheers

---

From: Seth <[email-masked]>
Date: Thu, 15 Jan 2009 18:39:54 -0500 (EST)

"Chris Lewis" <[email-masked]> wrote:

> It is technically possible (in fact trivial in many cases) to
> instrument a MTA to automatically generate and send ARF in real
> time.  Even assuming that the MTA can figure out the _right_ place
> to send the ARF, it becomes a WMD.
>
> Imagine, if you will, everybody did it.  Some moderately sized site
> gets a reasonably prolific (single) infection, and spews out a few
> million viruses.  You're expecting the site's MTAs to handle a few
> million ARFs, when only one _should_ suffice.

If one suffices, then the site immediately closes or blocks the
infected machine, and it doesn't get all that many notices.

> If broadly implemented, it'd cause global meltdown.

For a value of "global" closer to "sites that don't react to their
infections in a sufficiently timely manner".

> God help us all if the site receiving the ARF somehow doesn't
> recognize it as ARF, and replies with its own ARFs.

It would be better to create a new protocol for the ARF responses
(even if it's just email on a new port, though I'd include some
extensions to allow for "Report of virus emitter on <IP>" "I already
know" "QUIT")

Seth

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Jan 2009 12:10:28 +0100

>> to send the ARF, it becomes a WMD.

Yeah, standardizing [email-masked] can generate much confusion...

> infected machine, and it doesn't get all that many notices.

If I understood Chris' point, there would be a few millions different 
MTAs that have been reached by the site's fallout. None of them knows 
whether anyone else already reported that notice. However, the number 
of notices is linear with the number of viral messages sent. If the 
site has been able to send so many messages, it might (should?) also 
be able to receive so many notices. Unlike DSN (which existed before 
their format was standardized), the response should be machine readable.

Reporting to a DNSBL service, as Franck suggested, might overcome that 
risk. In facts there are monitoring services that do such kind of 
service. However, the server may submit its report to a different 
organization than the one(s) subscribed by the client. Unless they 
exchange data, thus forming a global distributed organization, report 
delivery would be at stake. Unfortunately, RIRs don't do that.

> extensions to allow for "Report of virus emitter on <IP>" "I already

"I already know" requires a strong standardization of the reasons. 
Probably keying on faulty IPs can drastically reduce the number of 
repeated messages. For ARF reports, the receiving site doesn't have to 
reject or bounce what it doesn't want. Having two DATA commands, one 
for the machine readable part and a rejectable one for the original 
body, can save bandwidth; but currently ARF does not provide for that.

Something new is required in order to let the client and server MTAs 
become aware that they both support ARF reporting. Perhaps they should 
negotiate what reports they are interested in, which ones with full 
bodies, for which types they only want one, etcetera.

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 23 Jan 2009 08:56:59 -0500

> count against the detection mechanism.

I don't agree.  If the anti-X filter is so poorly written that mere
discussions about X trip it, then that's a FP by definition.

This is one of the many reasons why I largely eschew content-based filters,
and why I try to use them only after all other methods have been tried:
it's very hard to get them right.  And it's also one of the reasons why
I think anyone who's using them should be prepared not just for FNs,
but for FPs -- which I believe Chris's operation is, based on what they
return in reject messages.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 23 Jan 2009 09:02:15 -0500

> extensions to allow for "Report of virus emitter on <IP>" "I already

This is a good point (as are others you made, which I've elided).

But I'll argue that before we set about the difficult work of inventing
and implementing another protocol, we should use the ones we have.

SMTP rejects of malware-laden mail messages are one way of signalling
emitters that they have problem, without allowing the problem to cause
the external system to generate more outbound traffic.  Should we be
doing HTTP rejects?  FTP rejects?  And so on?

And if we do, what are the benefits and risks?  Can we make the FP rate
low enough that we don't end up creating a secondary problem that's worse
the one we're trying to solve?  Can we avoid attempts to game the system
and thus conduct DoS-by-proxy attacks?  And so on.

---Rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 23 Jan 2009 12:31:02 -0500

> This is one of the many reasons why I largely eschew content-based filters,

Many of us in the biz remember when AOL hit the media for trying to
block porn spam by filtering on the word "breast".  One of the highest
FP rates I've _ever_ seen was on the four letter word starting with "f"
(no, it wasn't my idea, but the FP rate gave me the argument to kill the
rule).

> return in reject messages.

Serious spam filtering environments have to put a lot more effort into
dealing with FPs than FNs.  FNs are forgivable.  Unrecoverable FPs are not.