Norman: Can you clarify what you mean? Norman Maurer <[EMAIL PROTECTED]> wrote: It would not make any sence if the whould not accept the email..
Am Donnerstag, den 09.03.2006, 14:45 -0800 schrieb Ken Lin: > 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 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. --------------------------------- Yahoo! Mail Bring photos to life! New PhotoMail makes sharing a breeze.
