On Mon, Mar 03, 2003 at 02:49:28PM +0000, Roland wrote:
The real problem will be with forwarding accounts, the envelope-
sender should be replaced with the address of the forwarder.
Maybe you want to include a note about this in your proposal.
Yup, thanks. Same problem with some mailing list processors, which
leave the envelope sender intact.
Let's assume you're working somewhere in california with ISP1,
but sometimes you're in New York and working with ISP2.
Then your RMX record could look like this:
jmason.org IN RMX (california.isp1.com newyork.isp2.com)
Wildcards would be nice too, and could solve the problem with
dynamically assigned hostnames.
At least at a first glance, wildcards don't work.
If the RMX contains *.isp.com, what are you looking for in the
next resolving step?
You could, of course, try to match the hostname found by reverse
lookup, e.g. do a reverse lookup of address a.b.c.d , and see
if the hostname matches e.g. northpole.isp.com. But that opens
the door for spammers again, since if they have access to their
reverse DNS entry, they can give themselves any name. So you had
to doublecheck this again.
I'd rather avoid making PTR records part of the chain, since they
are a little bit vulnerable to some nonsense, and usually under
someone else's control.
(d) need to use an "allow all" 0/0 mask for mydomain.org.
That's also possible. That's a statement like "I don't want to
restrict origins for my domain". If you want to do so, that's fine.
But it might be my decision to not accept mails from such a domain
anymore.
I dont think that should be a part of the proposal.
There are enough domains which will use RMX anyway, and this will
put quite some pressure on the others.
The acceptance would be much better if you not trying to force the
usage of RMX to anybody. And of course everybody is still free
to block whatever he wants on the own server.
Ah, sorry, my statement was misleading. With "my decision" I didn't
mean the draft, I was speaking as mail admin. I was talking about
the local policy, not a general rule.
This actually does not stop the spew at the side of the sender
since the whole message has to be received and parsed for the
cryptographic bits.
I'm currently preparing another draft for a successor of SMTP
which also addresses this issue. But this is a different story
since it is a new protocol requiring new software.
The solution probably would need an extended MAIL FROM where the
key of the sender gets appended (like the SIZE extension) to allow
rejection at the RCPT TO (per receipient) without actually receive
and parse the whole content.
Yes, that's a design criterion of my draft. If this is considered
to be within the scope of this working group, I can present a
first, rough version soon.
The solution should probably also allow for an additional token
to be appended to the RCPT TO, for various reasons.
Yep, already contained in my draft.
There is also another problem: if RMX gets widely used spammers
will use empty envelopes which can not be protected by RMX.
How could an RMX-compatible DSN be composed ?
That's a pretty good question. Introducing empty envelopes
was a pretty bad idea, especially in context of SMTP which presents
envelop addresses only before transmission of the message.
That's a diffent problem we'll have to discuss. Unfortunately,
it will be difficult to disestablish empty envelopes in
common SMTP.
regards
Hadmut
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg