Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM)

From: Gordon Peterson <[email-masked]>
Date: Sat, 10 Jan 2009 21:18:34 -0600

It is important to remember that many individuals and many small 
companies use personal or "vanity" domain names.

These domain names appear in their "From:" and "Reply-to:" addresses on 
their outgoing e-mail messages, but SHOULD NOT be presumed to indicate 
where the e-mail in question is arriving from.

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.

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.

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.

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!  In that case, the spam 
blocker sending the 'bounce'/refused message does not know where the 
original message was ACTUALLY sent from;  commonly they will send the 
bounce message to the COUNTERFEIT "from" address (n.b. the address the 
original spammer ACTUALLY wanted to send the message to!) only now, it 
arrives from a "clean" IP address (i.e. the IP address of the antispam 
blocker which "bounced" it) rather than from the IP address actually 
originating the message (which the actually intended recipient might 
have refused, based on the sender IP address).  So now the unwanted 
message arrives at its intended destination, having "reflected" off a 
spam reflector and thus now with a "reputable" IP address.  (True, it is 
now shown as an "undeliverable/spam/virus" bounce, but a lot of people 
DO open such messages).  ...ANYHOW, PARTICULARLY when a message is sent 
by a virus KNOWN to falsify origin addresses, it is NOT helpful to send 
a bounce message back to the "bogus" "origin" address indicated in the 
message.

I have a folder here with probably something approaching a hundred 
thousand such bounces, caused by spam messages which were sent using 
bogus/falsified addresses but counterfeiting one of my domains, and 
where these messages did not originate from any of my systems.  The 
point is that there is NO value in sending back a bounceback/refused 
message unless you are SURE you know where it should be sent back to 
(i.e. who actually sent it).  It's NOT enough to just believe the 
"From:" address.

> Subject: Re: [Asrg] where the message originated (was: DKIM role?)
> To: Anti-Spam Research Group - IRTF <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> At 13:05 08-01-2009, Franck Martin wrote:
>> on 4) for information there is this blocking list:
>> http://www.uceprotect.net/en/rblcheck.php?ipr=202.170.42.206
>>
>> but it tends to block by AS number and in the above case, AS9241 is 
>> the whole country of Fiji.
> 
> That shouldn't be a problem if you don't communicate with people from Fiji. :-)
> 
>> Also as a note, I think dealing with high volume mail sender is not 
>> the issue, they are known, we know their technics, etc... it is more 
>> to deal with the long tail of little companies, organisations, small 
>> ISPs, etc..
> 
> Some receivers may view these small organizations as statistically 
> insignificant.  These small organizations generally adopt antispam 
> policies without analyzing whether such policies can have a negative 
> impact on them in future.
> 
> At 09:44 09-01-2009, Douglas Otis wrote:
>> White-listing based upon a domain would be dangerous without also
>> including the IP address of the SMTP client and message tracking.
>> There are companies currently providing this service, particularly
>> needed where spam remains largely unmanaged.
> 
> The question was whether it is important to note where the message 
> came from.  I take it that your answer is yes.
> 
>> The algorithm can remain oblivious to who owns the SMTP client.  It
>> determines whether a conversation was observed, while also allowing
>> also users to submit corrections.
> 
> That only works as long as the two end-points for the conversation 
> are static.  Such a constraint is only acceptable to users until they 
> move around and experience a communication failure.
> 
> Regards,
> -sm 

-- 

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: Alessandro Vesely <[email-masked]>
Date: Sun, 11 Jan 2009 09:43:45 +0100

> 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. If not, 
assuming you won't configure an email client, you should use company's 
webmail server. You are not going to store your userid/password at an 
unknown box, are you? Thus, you should connect to your outgoing server 
in the same way that you connect to your incoming one.

> 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.

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

> 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...

> 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.
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

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

--On 10 January 2009 21:18:34 -0600 Gordon Peterson <[email-masked]> 
wrote:

> 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.

You need to use your email service provider's Message Submission Service. 
That should be available to authenticating clients on port 587. 
Alternatively, use their webmail. If your Internet cafe is willing to relay 
your email, then they're willing to relay spam, too, and should therefore 
be blacklisted.

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

---

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

--On 10 January 2009 21:18:34 -0600 Gordon Peterson <[email-masked]> 
wrote:

> 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!

Actually, it occurred to me that we have mechanisms whereby domain owners 
can prevent abuse of their domains (SPF and DKIM). Therefore, we should 
feel free to bounce email to any domain owner the doesn't deploy SPF and 
DKIM - in order to encourage them to do so. Of course, bouncing email is 
also OK when you find an SPF or DKIM match.

---

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

> also OK when you find an SPF or DKIM match.

This is utter nonsense, of course.  It is *never* acceptable to deliberately
generate or redirect spam.  I'm appalled to find anyone recommending such
a clearly abusive course of action.

---Rsk

---

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

--On 12 January 2009 07:28:33 -0500 Rich Kulawiec <[email-masked]> wrote:

>>  DKIM - in order to encourage them to do so. Of course, bouncing email
>> is   also OK when you find an SPF or DKIM match.
>
> This is utter nonsense, of course.  It is *never* acceptable to
> deliberately generate or redirect spam.  I'm appalled to find anyone
> recommending such a clearly abusive course of action.
>

Well, I should clarify that I'm not recommending it, or doing it. However, 
I do think that it's time that domain owners started taking responsibility 
for the use of their domains. The technology exists, and it would have the 
direct benefit to them that collateral spam back to their domains was 
reduced.

In a world where you *can* prevent abuse of your domain, what's wrong with 
bouncing email?

---

From: Seth <[email-masked]>
Date: Mon, 12 Jan 2009 11:06:43 -0500 (EST)

Ian Eiloart <[email-masked]> wrote:

> Actually, it occurred to me that we have mechanisms whereby domain
> owners can prevent abuse of their domains (SPF and DKIM). Therefore,
> we should feel free to bounce email to any domain owner the doesn't
> deploy SPF and DKIM - in order to encourage them to do so.

And the recipients of the bounces should feel free to report your
bounces as spam.  And they should also feel free to cut your Internet
connection to block further spam from your site, to encourage you to
stop spamming.

Seth

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 12 Jan 2009 17:00:08 +0000

> connection to block further spam from your site, to encourage you to

Of course they could, but wouldn't they be better advised to take 
responsibility for their domains, thus preventing me from having to deal 
with spam sent "from" their domain?

---

From: Seth <[email-masked]>
Date: Mon, 12 Jan 2009 12:02:22 -0500 (EST)

Ian Eiloart <[email-masked]> wrote:

> responsibility for their domains,

They do: by not emitting spam.  That's what they're responsible to do.

They aren't responsible to sign up for Clever-Idea-Of-The-Week and
implement whatever makes your life easier.

> thus preventing me from having to deal 

It's not my responsibility to mediate the transaction between two
third parties, even if one of them lies about being me.

Seth

---

From: Graeme Fowler <[email-masked]>
Date: Mon, 12 Jan 2009 17:20:46 +0000

> connection to block further spam from your site, to encourage you to

I have a sneaking suspicion that there may be a terminology problem
here: Ian more than likely means "reject" when he says "bounce". The
thread becomes rather less argumentative if you do that replacement.

Of course, I may be putting words into Ian's mouth which he *didn't*
mean, but before anyone else replies I would like to see Ian clarify
whether he means "bounce" or "reject".

Knowing him at least a little in my professional capacity I would be
*very* surprised if he did intend to write "bounce", unless he was being
deliberately controversial...

Graeme

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 12 Jan 2009 12:41:31 -0500

> with spam sent "from" their domain?

Please describe a _practical_ way to deal with Russian or Ukrainian
virus/botspammers forging our domains in their spewage.

SPF?  DKIM?  We do SPF.  We may end up doing DKIM some day.  But it
won't make a significant difference to what is being _sent_.

This is vaguely reminiscent of the complainer who, when I pointed out
that our domain in his complaint was forged, replied with "well, you
must be doing something bad if they're forging you like that".

Splorf.  "Bad" for whom? ;-)
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

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

> However, I do think that it's time that domain owners started taking
> responsibility for the use of their domains.

If I, say, were to forge mail from your domain to, say, some ibm.com
user, would you take responsibility for it?  That's what you seem to me
to be saying.

> In a world where you *can* prevent abuse of your domain, what's wrong
> with bouncing email?

Depends on what that prevention requires.  ("Sure you can prevent abuse
of your domain.  You just need to enter into a bilateral agreement with
every receiving mailhost on the net.")

But that's not the world we have, so it's a moot question.

/~\ 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: Dotzero <[email-masked]>
Date: Fri, 16 Jan 2009 08:51:57 -0500

On Mon, Jan 12, 2009 at 6:33 AM, Ian Eiloart <[email-masked]> wrote:
> can prevent abuse of their domains (SPF and DKIM). Therefore, we should feel
> free to bounce email to any domain owner the doesn't deploy SPF and DKIM -
> in order to encourage them to do so. Of course, bouncing email is also OK
> when you find an SPF or DKIM match.
>

Ian, the correct way of phrasing it is that SPF and DKIM can MITIGATE
(my emphasis) certain types of abuse of their domains.

I would also point out that someone could deploy an SPF record with a
+all. How does that prevent anything?
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Jan 2009 10:21:04 +0000

> They do: by not emitting spam.  That's what they're responsible to do.

No, that's not taking responsibility for your domain, that's taking 
responsibility for your network. It's not the same thing, even if you think 
it's adequate.

> implement whatever makes your life easier.

But, primarily it make the domain owner's life easier. In two ways. First, 
they will get less collateral spam into their mailboxes. Second, they will 
find that their email becomes more deliverable.

> third parties, even if one of them lies about being me.

True. Just as it isn't your responsibility to prevent criminals from using 
your credit card details. However, you suffer when they do. Therefore you 
are well advised to take what security measures you can to prevent that.

Actually, it's something that the world has to collaborate on. We all have 
a collective responsibility. But maybe you don't care?

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Jan 2009 10:45:10 +0000

> virus/botspammers forging our domains in their spewage.

Practical. Well, you're doing more than many people do. What I'm suggesting 
isn't going to fix the problem overnight, and not for any specific 
individual. This is a political issue, now given that the technologies 
exist. To solve the political problem, we need to convince others to 
publish the records, and to respect them.

When enough people are respecting SPF records with strong policies, then 
spammers will stop using domains that publish those records. They need 
their spam to be deliverable. Of course, that doesn't mean that they'll 
stop spamming, just that they'll stop using your domain. You'll benefit 
from reduced spam blowback. You'll benefit from improved reputation. You 
can benefit now by respecting your own SPF records - thus preventing 
spammers from spoofing "internal" email.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 19 Jan 2009 11:08:32 +0000

> thread becomes rather less argumentative if you do that replacement.

No, actually I mean bounce. I mean "generate a new message". Domain owners 
are able to help the world detect forgeries. If they don't do that, then 
perhaps the rest of the world should not feel too bad about using SMTP in 
the way that it was designed by generating a bounce message.

> deliberately controversial...

Thanks. I am deliberately trying to generate discussion of the idea. I'm 
well aware, that it's not very nice to be on the receiving end of 
collateral spam. And have for some time thought that the solution is to 
argue that nobody should bounce email.

However it occurred to me recently, that actually you don't need to be on 
the receiving end of collateral spam. Rather than trying to persuade people 
to NEVER bounce an email, it might be better to let people know which 
emails can be bounced - those with proper SPF or DKIM matches.

There are at least two very good reasons for wanting to bounce rather than 
reject emails.

a) when a message has two or more local recipients, you can't have 
different policies for each recipient about what to reject. You reject for 
all or no recipients. There are some workarounds, but they're kludgy and 
cause their own problems.

b) when you reject a message you can try to explain why, but often the 
sending MTA will throw away some or all of your explanation. Usually, it 
will wrap your explanation inside it's own. The end result is that the 
recipient of the bounce message (if there is one) doesn't understand what's 
going on. If you generate a bounce, you have full control of what the 
bounce recipient sees. For example, you could include an explanation of why 
they should lobby their domain controller to publish SPF records.

---

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

> +all. How does that prevent anything?

It doesn't prevent anything. SPF records don't prevent anyone attempting to 
forge email.

Of course, if you publish an SPF record with +all, then nobody here is 
going to argue that I shouldn't bounce email into your domain, are they?

And, my guess is that domains with such records are going to find it hard 
to deliver email to anyone. In the end, it will be equivalent to publishing 
an SPF record with "-all".

And, it's not all or nothing. The more liberal your SPF record, the sooner 
you'll find that people stop accepting ANY email from you.

---

From: der Mouse <[email-masked]>
Date: Mon, 19 Jan 2009 10:24:40 -0500 (EST)

> different policies for each recipient about what to reject.

Sure you can.  You just need to push that information to your border so
you can 4xx all recipients whose rejection policies differ sufficiently
from those of the first 2xxed recipient.  (Where differing
"sufficiently" means differing in ways such that the SMTP body contents
could cause them to make different rejection decisions.)

> There are some workarounds, but they're kludgy and cause their own
> problems.

I implemented the above, once.  The only problem I saw was when
accepting mail from broken MUAs that tried to send not with SMTP but
with some ill-defined SMTPish protocol in which a 4xxed recipient meant
the mail had failed entirely.

Even if you have to accommodate such brokenware, all this means is that
you mustn't do differential recipient rejection for MUA submissions.
Unless you know of an MTA that misbehaves that badly?

> b) when you reject a message you can try to explain why, but often
> the sending MTA will throw away some or all of your explanation.

And that's your problem...why?  There are lots of ways that information
could get lost.  The end user could ignore the bounce, too, or may not
be competent to read the language you generate it in.

> If you generate a bounce, you have full control of what the bounce
> recipient sees.  For example, you could include an explanation of why

And you really think that anyone who doesn't already grok bounces is
going to have any clue what you're going on about?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Mon, 19 Jan 2009 10:32:58 -0500 (EST)

> But, primarily it make the domain owner's life easier.  In two ways.
> First, they will get less collateral spam into their mailboxes.
> Second, they will find that their email becomes more deliverable.

Will they?  Where are the numbers?

I suspect both may actually be false, given how spammers adopted SPF
with greater eagerness than other senders.  A practical statistician
without an axe to grind over SPF would see a positive correlation
between SPF presence and spamminess, causing senders with SPF to see
lower deliverability.  Less collateral spam is less clear, depending on
what counts as "collateral" spam, but I suspect the lower
deliverability from recipients who've noticed that SPF indicates higher
spaminess would outweigh the benefit from recipients who are using SPF
the way you seem to want it to be used.  (I suspect both effects are so
far down in the noise that it would require a huge sample size to tease
out which way the effects actually go.  If anyone has real measurements
either way, I'd love to see them.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Paul Russell <[email-masked]>
Date: Mon, 19 Jan 2009 16:45:31 -0500

> cause their own problems.

Perhaps that is true of your MTA, but we have been doing this with sendmail for
several years.  This is a supported feature which can be enabled or disabled by
any reasonably competent system administrator.  I would not describe it as a
'work-around' or a 'kludge', and it has not caused us any problems.

 > they should lobby their domain controller to publish SPF records.

Some mail servers add boilerplate text - sometimes accurate, sometime completely
inaccurate - to every inbound DSN.  How are you going to deal with that issue?
The fact is, you cannot control the operation of every mail server that might
handle your completely meaningful, easily understandable, and perfectly
hand-crafted 'bounce'.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 20 Jan 2009 10:39:04 +0000

--On 19 January 2009 16:45:31 -0500 Paul Russell <[email-masked]> wrote:

>> There are at least two very good reasons for wanting to bounce rather
>> than  reject emails.
>>
>> different policies for each recipient about what to reject. You reject
>> for  all or no recipients. There are some workarounds, but they're
>> kludgy and  cause their own problems.
>
> Perhaps that is true of your MTA, but we have been doing this with
> sendmail for several years.  This is a supported feature which can be 
enabled or
> disabled by any reasonably competent system administrator.  I would not 
describe it
> as a 'work-around' or a 'kludge', and it has not caused us any problems.

With SMTP, you have to give recipient specific defers before you see the 
body of the message. Either you defer everyone after the first recipient, 
or you split them into policy classes and defer everyone who isn't in the 
first policy class. The defers cause delays which may be severe when there 
are very many policy classes.

I guess the ideal solution would be an SMTP extension allowing MTAs to 
switch to LMTP if they're both capable. I think something similar exists.

They may even cause delivery failure. For example, I've seen an airline 
ticketing agency that failed to retry delivery of messages! However, we 
can't be expected to design around that kind of stupidity. However, if you 
defer a whole bunch of people, then reject the message for the first 
person, the sender might be forgiven for thinking that your rejection of 
the message is definitive.

> Some mail servers add boilerplate text - sometimes accurate, sometime
> completely inaccurate - to every inbound DSN.  How are you going to deal 
with that
> issue? The fact is, you cannot control the operation of every mail server 
that
> might handle your completely meaningful, easily understandable, and 
perfectly
> hand-crafted 'bounce'.

Really? That's crazy. However, the ALL do it to rejection messages.