Stefano:
Great to hear from your experience. It sounds a lot of effort to become a
committer.
Here is the open relay testing site that I used:
http://www.abuse.net/relay.html
This appears to be pretty popular as it showed up as the top link on google
for "mail relay test". My james server failed the test case I mentioned
earlier in email (spoofing [EMAIL PROTECTED] to [EMAIL PROTECTED]).
I went ahead and tested a few other ISP and corporation's email. It seems
when SMTP authentication is not established, many directly reject any mail
with sender containing the designated domain name. Here are the servers I
tested that rejected all spoof:
Mail ISP:
Gmail: gsmtp183.google.com
Hotmail: mf4100beta1.solinus.com
Corporation email:
Google.com: smtp1.google.com
Amazon.com: smtp-fw-0101.amazon.com
Microsoft.com: mailb.microsoft.com
The test on Yahoo seems to have failed that it accepts a "fake" email from
[EMAIL PROTECTED] to [EMAIL PROTECTED] However, it is possible that yahoo
"drops" spoofed mails in spooling queue (like using the configuration similar
to what you posted earlier). I need to confirm this later. (I can't do the
spoofing testing at work at the moment because our corporate firewall blocks
all outgoing port 25 access)
Just to make sure that the code change won't violate the RFC, can you let me
know the RFC number and section number that mandates any email from @xyz.com
can be sent to [EMAIL PROTECTED] without SMTP authentication? I looked at the
following two RFCs from the IETF site and couldn't find this mandate:
SMTP RFC (821): http://www.ietf.org/rfc/rfc0821.txt
SMTP authentication RFC (2554): http://www.ietf.org/rfc/rfc2554.txt
Ken
Stefano Bagnara <[EMAIL PROTECTED]> wrote: Ken Lin wrote:
> Maybe this method of "spoofing" users has been overlooked. Even if James
> has SMTP turned on, I can impersonate any user of the server and send
> another user an email without any authentication. In a way, it seems to be a
> security hole open by default unless people apply your section of
> configuration.
You, anyway, will never stop people from using your email as sender
address and send messages around the world. There are solutions to stop
this behaviour (e.g. SPF) but not supported by all the SMTP server so I
don't think that we can consider this thing a "security hole" in james.
I'm not 100% sure, but I bet that most mail servers will not block
messages with a "from:" containing a local domain to be relayd (even
with authentication on).
> Well we check for recipient address in the first place. This checking is
> not explicitly mentioned in the RFC either, but is just implicitly allowed.
> By the same token, checking the sender address should be allowed too.
You'd be not RFC compliant because you MUST accept a mail "from:
[EMAIL PROTECTED]" "to: [EMAIL PROTECTED]" even without authentication.
I think that this is not specified in the RFC and is not even common
practice for SMTP servers and we should not make it the default.
Btw, if you want to write a patch to provide an option to enable this
behaviour I'll try to review it.
> What do you think? Actually, are you a software developer on the James team?
> How do I become one?
I'm a James committer. I've been "proposed" by other James committers
one year ago after many months of support here in the list and after
having submitted many patches to the issue tracker.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
