[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