RE: Time to check the rate limits on your mail servers

..or a cost issue. Most of these users are people who have
decided not to spend the $40 to defend their machine at home.

-M<

So you educate them as to why it would be a good idea to keep
  their computer secure.

  But in the meantime, their machine is spewing garbage -- which,
  as many have said, is the operational issue at hand.

How about using SMTP AUTH and verifying the envelope MAIL FROM to match
the actual user authenticating? This will make SPAM traceable and
hopefully ultimately users aware that their PC is sending junk.

Adi

How about using SMTP AUTH and verifying the envelope MAIL FROM to match
the actual user authenticating?

that doesn't work if you have more than one email address.

This will make SPAM traceable and
hopefully ultimately users aware that their PC is sending junk.

auth is sufficient to make email traceable to your own customers.

How about using SMTP AUTH and verifying the envelope MAIL FROM to match
the actual user authenticating?

that doesn't work if you have more than one email address.

Wouldn't address resolution take care of that if properly
configured? Some implementations allow you to specify what
email addresses the user is allowed to send from, that's
something that needs to be managed carefully.
-GSH

Date: Thu, 3 Feb 2005 15:41:34 -0800 (PST)
From: Joel Jaeggli

> How about using SMTP AUTH and verifying the envelope MAIL FROM to match
> the actual user authenticating?

that doesn't work if you have more than one email address.

The words "overreaching" and "fallacious" come to mind.

auth is sufficient to make email traceable to your own customers.

End users also would appreciate the ability to _know_ a message is not
forged. Alas, I doubt much has changed since last October's BCP38
discussions, so perhaps I should not hold my breath.

Eddy

Solutions through diligent use of add-on products is not 100%. Many
users spend $40 and diligently apply prophylactics, but still are
compromised. Reinstalling over an existing installation does not ensure
removal. Either way, this returns the OS to a vulnerable state, while
costing several frustrating hours. Using a CD-ROM OS/App suite, such as
Knoppix, sounds promising for this headache. It should be difficult to
corrupt an OS or application when on Read-Only media. :slight_smile:

The number of zombies ensures rate limiting will not be effective
either. Providers keeping their house in order in the face of this new
strategy may be assisted by domain signed mail. This could serve to
block compromised accounts with help from the provider themselves.
Rejections from a third party will tell their clients they need a
disinfectant.

http://mipassoc.org/mass/

The wack-a-mole game needs a more agile mallet.

-Doug

How about using SMTP AUTH and verifying the envelope MAIL FROM to match
the actual user authenticating? This will make SPAM traceable and
hopefully ultimately users aware that their PC is sending junk.

Ouch .. Then spammers may start using a From: matching the SMTP auth
user, and effectively joe-jobbing the user.. Ick..

> How about using SMTP AUTH and verifying the envelope MAIL FROM to match
> the actual user authenticating? This will make SPAM traceable and
> hopefully ultimately users aware that their PC is sending junk.

Ouch .. Then spammers may start using a From: matching the SMTP auth
user, and effectively joe-jobbing the user.. Ick..

And that would be marvelous! At the very least it would give the user an
incentive to clean up his PC. Alternately the email account could be
revoked.

Adi

> How about using SMTP AUTH and verifying the envelope MAIL FROM to match
> the actual user authenticating?

that doesn't work if you have more than one email address.

You should know all your users email addresses. It shouldn't be too
difficult to match the 'mail from' address with the user account. The only
caveat would be that joe@hotmail.com would actually have to use the
hotmail smtp server to send mail.

> This will make SPAM traceable and
> hopefully ultimately users aware that their PC is sending junk.

auth is sufficient to make email traceable to your own customers.

And how is that? There isn't necessarily anything in an email indicating
that it originated from an SMTP AUTH authenticated user. While a header
could be added, it isn't a mandatory thing.

Adi

* adil@adis.on.ca (Adi Linden) [Fri 04 Feb 2005, 03:17 CET]:

You should know all your users email addresses.

You have got to be kidding.

  -- Niels.

Date: Thu, 3 Feb 2005 20:37:29 -0500
From: Jason Frisvold

Ouch .. Then spammers may start using a From: matching the SMTP auth
user, and effectively joe-jobbing the user.. Ick..

Exactly. The user then loses mail sending ability, but other services
remain functional.

Eddy

The only way to be sure is via cryptographic signature. Barring that level
of immediate traceability, SPF provides a very useful data point to that
end (as its *only* purpose is curbing forgery).

Attempting to detect spam trickled through thousands of compromised
systems sent through the ISP's mail servers, SPF does nothing, and could
actually damage the reputation of those domains that authorize the
provider for their mailbox domain using SPF. These records can be read
by the spammers and then exploited. Repairing this reputation could be
next to impossible.

With respect to forgery, authorization is not authentication. There is
no consensus which mailbox-domain is checked, SPF (MAILFROM or HELO),
Classic (MAILFROM or Other and HELO), or Sender-ID (PRA), so it is
uncertain which mailbox-domain may have been checked for authorization,
if any. False assurances could be worse than no assurances.
White-listing for forwarded accounts or mailing lists to allow an SPF
rule-set bypass means there is no certainty a check was ever made.

-Doug

> You should know all your users email addresses.

You have got to be kidding.

Not kidding.

I have a mail system that handles mail for the example.com domain. I use
SMTP AUTH as the only means to relay through the server. My expectation
user@example.com communications. This means the mail server has knowledge
of all 'mail from' addresses my users are allowed to use.

Who says that Joe ISP has to provide an open SMTP relay to all customers
on his IP space? Let's face it, it doesn't work! Even with throttling some
SPAM will make it thorough and tha mail server will be black listed and
unable to deliver mail to many destinations in no time. It's only a matter
of time before owned PCs aquire the 'intelligence' to utilize SMTP AUTH to
relay mail.

So to clarify my position, my SMTP server handles mail for my users and
noone else. My users are identified by their email address(es) on my mail
server. Therefore, I can enforce that may mailserver reject relayed mail
that does not have a 'mail from' address that corresponds to one of the
valid email addresses for an authenticated users.

I am addressing the dilemma with the average home user. If you own a bunch
of domains you're in a whole different class. Make arrangement with your
ISP to handle your mail, run your own mail server or buy hosting with
email accounts. Point is, if you own a bunch of domains you're not the
average home user that floods the world with crap without their knowledge.

Adi

Attempting to detect spam trickled through thousands of compromised
systems sent through the ISP's mail servers, SPF does nothing,

  Nor is it purported to. Domain-based authentication schemes
  are intended to handle an entirely different problem.

and could
actually damage the reputation of those domains that authorize the
provider for their mailbox domain using SPF. These records can be read
by the spammers and then exploited. Repairing this reputation could be
next to impossible.

  You touch on some basic realities here:

    1. spam coming out of your network will affect your
       reputation.

    2. spam coming out of your own mail machines will affect
       your reputation even more immediately.

  Neither are affected by any of the domain authentication schemes
  currently in play (SPF, SenderID, DomainKeys, etc.) The spam
  itself may include forgeries, but that's a different issue.

Date: Fri, 4 Feb 2005 09:53:07 -0500 (EST)
From: Todd Vierling

The only way to be sure is via cryptographic signature. Barring that level

False. You imply that a crypto signature is a perfect guarantee, and
that nothing else can provide equal assurance.

of immediate traceability, SPF provides a very useful data point to that
end (as its *only* purpose is curbing forgery).

SPF says "mail from this domain should only come from these MXes". It
doesn't stop someone from forging a random @domain.tld address from an
SPF-blessed Everquick MX. Now, let's say it's known that Everquick MXes
authenticate users and only allow whitelisted "From: " email addresses.

Step 1: SPF [or similar/better] confirms that the MX is allowed to send
email on behalf of the claimed sender address. Discard message if it
comes from a bogus MX.

Step 2: The MX confirms that the user was authorized to use the claimed
sender address. The message would never have been transmitted had the
user not authenticated with the trusted MX.

Please explain how the "trust chain" does not verify the sending user.
"Malware will steal username/password" is not a valid answer, as the
same can apply equally to crypto keys.

Eddy

Please explain how the "trust chain" does not verify the sending user.
"Malware will steal username/password" is not a valid answer, as the
same can apply equally to crypto keys.

Now that we have established a "trust chain" an verify the sending user we
have an easy way (shuffling through mail logs is by no means easy in my
books) for support people to address SPAM complaints.

Even better, due to the verified sender we can now send bounce messages
and notifications to originator. Sure, it'll result in "I never send
this..." type support calls but support can now say "Sure, your computer
did behind your back...".

Adi

Hi
A cryptographic signature would be a perfect guarantee as it can be used for direct identification and authorisation if you were guaranteed that the only user of the signature was infact you and not the spyware on your machine. The implementation is everything.
To prevent spyware using your signature you can for example use some sort of local signature engine and a fingerprint reader. It isn't possible to steal the private key because only the engine can decode it. Emails can only be signed with that signature by the engine, and the engine needs your fingerprint first. But who really wants to stick your thumb in the reader for every email you send?
And I definatly don't want to start using rsa secureid for each email I send. By only having a signature engine you could atleast limit the amount of signed emails permitted to pass through to something like 1 for every 5 minute etc.. If you dont pass the email through the engine it won't be signed. So why would I want to use this engine then? Perhaps if Microsoft removed the existing way of signing emails with outlook and replaced it with this one. So, my point is that a cryptographic signature/SMIME would in fact work for the purpose it was made for on workstations depending on the implementation.

Now that you are identified and authorised - I can still send you spam! How can I stop you from doing it? I can remove your authorisation. I can go visit you and beat you up. But its too late I already got your spam! If you have a default deny-all policy on your mailbox you might loose that $10m contract because you didn't reply in time to that email since it wasn't authorised. Can we afford the deny-all default policy then? It is your choice. If yes, then you really need something to send/receive authorisation requests if the recipient does not have you on its accept list. And I am pretty sure some smart spammer will abuse this service to send the actual spam with it if you permit text data from user-input.
If you want something to be used globally it should also be possible to implement globally. Newsletters and similar emails generated by automated systems would be a problem. You just have to trust them to not spam you excessivly.

Joergen Hovland

Date: Sat, 5 Feb 2005 13:11:11 -0600
From: Adi Linden

Now that we have established a "trust chain" an verify the sending user we
have an easy way (shuffling through mail logs is by no means easy in my
books) for support people to address SPAM complaints.

Note that I'm ignoring SMTP proxies that may munge headers.

Even better, due to the verified sender we can now send bounce messages
and notifications to originator. Sure, it'll result in "I never send
this..." type support calls but support can now say "Sure, your computer
did behind your back...".

I hadn't thought of setting "Return-Path:" based on authenticated user...

Eddy