[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] Feedback to MTA
At 12:18 AM +0200 5/27/04, edgar at edgarschwarz.de wrote:
Hi,
I recently subscribed to this list because spam is increasing. Some
weeks ago some
idiots started sending mails to johndoe at <mydomain>. Now about 50 to 100
per day. Easy to filter these invented addresses but nevertheless my money
as long as I don't have a flatrate.
Please apologize if I have wrong ideas sometimes because I'm just beginning
to have a look at this whole mail problem.
"Walter Dnes" <waltdnes at waltdnes.org> schrieb:
In my case, it's a 550 reject message *TO THE SENDING MTA, NOT AN
INNOCENT THIRD-PARTY WHOSE ADDRESS HAS BEEN FORGED IN ENVELOPE_SENDER*.
I recently was also thinking along these lines to give feedback because AFAIK
the IP of the sending MTA is nearly the single information in a mailheader I
can trust.
I thing you misunderstand what Mr. Dnes is saying. The 550 reject
message is part of the transport protocol, sent back before three is
an header attached with the sending MTA's IP address in it, very
often even before the receiving MTA has seen any of the message data.
OTOH it's probably not enough. If this is a zombie the reject will go to the
zombie which doesn't care.
Perhaps every mail should have a <abuse-to> field which must contain an
"abuse" MTA name which I can report abuse to. And to make things for spammers
harder this MTA must match the sending MTA in the first 3 octets.
That is really thinking small. Even if you ignore the fact that the
largest ISP's have enough functionally equivalent MTA's that they
can't all fit in a single /24 network (i.e. first 3 octets identical)
thre is the issue that even for moderately sized non-ISP businesses
and small ISP's it is quite common to have inbound and outbound mail
quite separate, sometimes even outsourcing one or both to external
service providers.
And if I reject a valid mail because it doesn't has a valid <abuse-to> this
will go back to the real sender who can then select an ISP which follows this
protocol.
Well that comes down to the core problem with the idea: how can
anyone really know that the extra header isn't itself a fraud. Every
day I see spam coming from zombie machines which are being driven in
such a way that they introduce themselves in SMTP with valid names
and pass along Received headers which are credible in almost every
detail, claiming to document the passing of mail from some other
machine to the zombie. Occasionally those Received headers even
describe mail transit that could have happened, were it not for the
fact that the zombie machine is not actually accepting mail by any
normal method.
Spam headers are forged NOW so as to give the impression of being the
legitimate product of machines which have been compromised for use as
spam zombies. Nothing in your idea would prevent similar forgery.
And in addition governments could set up some let's say <federal-to> addresses
to which a spamreport (Being spam decided by the receiver) which
consists just of the
header data, will go.
The US FTC had one of those for a long time. It may still be in
operation for all I know. It serves no real purpose in the absence of
laws regarding spam and a will to enforce those laws that do exist.
--
Bill Cole
bill at scconsult.com
_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg