[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mail-Transmitter RR
> Who is "you" in this case? My MUA? My MTA? I'm currently running
> sendmail on my laptop. My MUA just passes the mail on to there, and
> it gets forwarded appropriately. This is a nice feature because there
> are many times when I have better connectivity between my laptop and
> my recipient than I would going from laptop->home->recipient. Are you
> saying that instead of distributing the load of mail I now have to
> centralize mail delivery just because people are abusing the
> distributed nature?
I wouldn;t say 'have to'. If you have other ,ethods of authenticating your
mail (ie pgp etc), the receiving MTAs should be free to ignore the
MAIL-FROM RR if they can authenticate you that way.
The problem with that approach is that they would have to receive the
complete email first, *and* that they'd need the ability to do
authentication
which usually now is done in the MUA.
On the otherhand, this approach is *voluntary*, and no-one forces you to
publish your MAIL-FROM MX ifyoudon't want to use it.
>
>> So don't use MAIL-FROM if it doesn't work for you. I think this is
>> an unlikely problem, though. I use a remote mail drop for every
>> email message I send, and it has never caused me any inconvenience.
>
> Perhaps your definition of inconvenience and mine are different? But
> consider this: if not everyone is doing it, then what's the point? If
> it's not a ubiquitous solution, then it's not going to solve the spam
> problem. All it will do is prevent spammers from forging a valid
> email address to recipients that have agreements with that individual.
No. The beuaty of thes approach is that there is no specific agreement
between each pair of potential senders and recipients necessary.
A recipeint decides whether s/he wants to use this method of MAIL-FROM
is such an RR exists for the sender, and the sender simply published
it if they want their addresses protected from abuse (at least to those
sides that actually check for it).
>
> I was hit by this today... Some spammer used my address to send out a
> bunch of messages, and I was lucky enough to get all the bounces into
> my inbox. I certainly did not know any of the recipients whose mail
> bounced back to me. So, how would this have helped me (or them) in
> this case, especially if you're telling me not to use it?
You can't have it both ways. It will help you only if you use it, but
that means using list of predefined MX hosts. There are tradeoffs.
If you really want, you can list your laptop in the MAIL-FROM MX
list and use DDNS to update its IP address before sending mail.
There should not be any problems with the mail hanging around and
someone checking the MX after you lose that IP address, as it is the first
MTA after your sender that will have to perform this check.
> See, I'm not convinced it will make it much more difficult unless it's
> a upqiwuitous deployment, and I believe that the functionality that is
> destroyed by deploying this technology is not worth the perceived
> benefit.
I don's see any functionality being destroyed. You will have to make a
choice
which is more important to you, fast, shortest-hop delivery to the nearest
recipient MTAs or the protection of your address(es).
mk
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>