Danny Angus wrote:
>>Have you read RFC 1939? The mailbox name is "a string
>>identifying a mailbox
>>(required), which is of significance ONLY to the server."
I read it and I agree with below. As far as a security risk I don't see
how it's any more of a risk.... If someone is sniffing traffic, they
know where you connected to and what username you sent anyhow (Unless
the entire transmission is secure, which also doesn't create any higher
security risk). I'm truly open for discussion on this, I just currently
don't see it.
> But that doesn't prevent the use of the whole address, however doing so
> would require changes to local delivery.
Could you setup user inboxes to include the domain on multidomain
systems? Another cleaner, but more involved change would be to map
domains in user repositories either in subdirs or in naming conventions
for the file. I freely admit I don't understand the system near enough
to know all the implications, but I'm slowly getting there.
>>Honestly, I'd love to can file system user
> There is consensus, I believe, in extending choice.
Precisely. Just because one person looks at it as a burdensome method
does not mean it should be excluded as an option.
>>>otherwise the mail server returns a User Unknown
>>>message of some type.
>>Ah! Gotcha. You want to return a 550, but I believe that you
> it is better anti-spam practice not to indicate invalidity in a 550 message,
> James doesn't validate addresses at all, [FAQ reference]
I understand that portion, what I'm looking for is another option to the
"black-hole" method. By accepting spam, spammers will continue to send
(although the lucky user doesn't have to see it). Granted, for the
alternate method I bring up, there will be more overhead for each
individual message (although I wouldn't imagine it's going to be much
more than the overall black-hole method), but, by reporting back that
the user doesn't exist, the spammer will stop trying to send AND given
that the mappings are compared to sender address as well, I believe it
becomes MUCH harder for spammers to emulate and bypass.
If To and From don't match they receive a 550 as Noel stated. I also
have a second motive for doing the comparison - tracking who is either
selling names or has a security loophole in their site. All the items I
listed, used together, make for an excellent tracking system for users
and admins alike. Admin@trackedDomain can send to Admin@breachedDomain
and say many of my users are complaining about receiving spam from the
email they used on your site.
Me personally, I hate spam so much, I plan on creating a site to report
sites that refuse to address the problem (pardon the pun 8).
> In fact James performs no pre-processing of mail during the SMTP transaction
> apart from checking the basic syntax of the SMTP conversation itself.
I'm not saying make it default behavior, just an optional processing step.
> The possibility of adding more complex behaviour to this element, and of
> adding virtual hosting to the whole mail system have been under discussion
> for at least a year but keep failing to reach concensus on any specific
> scheme, and in the meantime no commiter has taken the bull by the horns and
> implemented any stop-gap measures.
I'm studying the system now, I'm going to try to get a proposal/proof of
concept coding done (not sure exactly when though 8).
David Jenkins
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
