On 03/04/14 00:44, Marcus MERIGHI wrote:
as I read this (thanks for the link) there is no real solution to the
problem. Under "Reducing the problem" it says:
Checking bounce recipients
Mail servers sending email bounce messages can use a range of measures
to judge whether a return address has been forged.
Testing the recipient of the bounce is all well and good but it may be
hard to check a message on if the message was forged well or sent poorly
since the only way we could make the determination on if the recipient
is valid is look in the envelope on where it came from, connect back,
and hope to whatever diety you belive in the remote end supports/hasnt
turned off due to spam abuse verify. Even then if the recipient is valid
its a personal choice if you want to send back the full messages to a
stranger on the internet which honestly id prefer not to.
Which "range of measures" is this referring to?!
What I want to stress is that this discussion is about working around a
problem some mail providers pose. Where is this going to end? I have a
nationwide mail provider here in austria that throttles inbound mail
after some number of messages. Could we work around this as well,
please?
BTW, the proposed workaround of bouncing without content is not
suggested in the above link.
It is not suggested there but a wiki article is not the end all be all
of solutions, neither is an RFC, the option of dropping messages,
returning headers only and stripping the bodies, or returning full
messages is a common practice since there is no standardized solution
that prevents back scatter and all three of thoose options have their
place in a valid mail transaction based on your trust of the remote end.
This isnt just working around a single provider problem, its actually
working around a spam problem there is a reason the backscatterers RBL
exists. Where does it end it ends some where around you being facetious,
this is actually a solution to this problem since it keeps the features
of notifying the remote end about issues but allows the user to make the
choice of their trust level on how to do it, and has proven to
discourage spammers from doing this on servers where it is implemented.
P.S. you can use PF and a host of other things that will fix your single
issue problem with your austrailian ISP so your solution already exists.
Bye, Marcus
Later
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
