sethg at GoodmanAssociates
Apr 30, 2004, 6:42 AM
Post #22 of 64
(6621 views)
Permalink
|
> From: Meng Weng Wong
> Sent: Thursday, April 29, 2004 5:22 PM
<...>
> If a spammer can get his hands on the return-path, SRS makes the sender
> vulnerable to spam directed to that return-path, yes.
>
> But SES makes the sender vulnerable to spoofing --- a spammer could send
> mail *as* that SES address to a bazillion recipients. You'd have to
> dynamically invalidate the SES address and hope enough people do CBV.
That is true. It is equally true, however, for unsigned mail coming from
any host, and you don't even need to harvest a signed address to perpetrate
the spoof. Even if a domain publishes an SPF record, the only thing that
stops joe-jobs is if enough other people do SPF checks. Both SPF and SES
depend on the recipient to do the appropriate check. If they don't, neither
method will prevent forgeries.
In terms of dynamically invalidating an SES address that has been harvested,
one way to mitigate the damage that would normally do is to include a hash
of the body (and a few headers) in the SES address. If the hash had enough
bits (considering the birthday bound, you would roughly double the number of
bits needed to represent the daily outgoing traffic of the MTA), this would
effectively act as a message ID and the signed return path is now message
specific. Any SES host would reject such messages after DATA since the body
hash would not pass. This would be a big disincentive to even try this
spoof. Similarly, in an SPF world, people can still spoof domains that
publish SPF records, but it is largely a waste of time.
If you did have to invalidate a single message return-path, you would only
be giving up the possibility of receiving a valid DSN for that one message.
In fact, this causes no harm whatsoever. As Wayne pointed out, the likely
method of harvest would be from a general sales account for a large company.
If someone at a particular address harvests your signed return path, the
message was delivered and there will be no DSN, so you give up nothing by
disabling that return path signature.
Since the spammer must use that harvested SES address in a joe-job, the full
signed return path would be in the MTA log files of the spam targets. That
return path identifies the outgoing message and tells you exactly what
address harvested your return path, even if they used a compromised
broadband box (that doesn't have log files) to deliver the spam while hiding
their identity. That is something we cannot trace today: the remote
control source behind the broadband box spewage. You could then get the
spammers domain on RHSBL's, get all of their MTA's listed on IP DNSBL's and
get them listed in SpamHaus. Now we're getting somewhere in fighting these
dirtballs. If you then used the blacklists to check the destinations of
outgoing mail as well as incoming, you should be able to greatly reduce your
chance of having your address harvested.
Summarizing, if we put a body hash which also doubles as a message ID into
the MAIL FROM:, recipients have a method, albeit at the end of DATA, to
detect spoofs due to harvested SES addresses. Furthermore, as domain owners
and abuse desk personnel, now gain the ability to find out who harvested the
address, which identifies the actual spammer, who currently hides behind a
farm of zombie mailers that anonymize him.
--
Seth Goodman
|
1
