Re: [proposal] Doco
On 29.10.2003 00:00, Noel J. Bergman wrote: what mail client do you use that allows you to setup multiple outgoing servers like this? Outlook. I have a dozen different accounts, with different servers and/or identities (@apache, @devtech, @other-organizations). My brother uses Mozilla, and it supports similar AFAIK. Yes, it does: Edit > Mail & Newsgroups Account Settings > Outgoing Server (SMTP) > Advanced Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build process in maven?
Stephen McConnell wrote: Amusingly enough, I was just asking Dion that question last night. I do suggest that we make the effort to merge the branches before we re-do the build process, at this point. +1000 Really the biggest hurdle is a stable Avalon release. :) -- Serge Knystautas President Lokitech >>> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SMTP Verify - Opinions?
Hi all, I'm new to the list, but have been running James as my mail server for several weeks now. I ran across a problem today that would be fixed by implementing the SMTP VRFY functionality. I also read the rationale for "NoFastFail" in the wiki section, but didn't see my issue mentioned, so I'm soliciting opinions from anyone before I try to implement the VRFY command. The issue I discovered is one in which one or more spammers have probed my James server, determined that their is no verify implemented, and begun to send mail from their own server (or possibly an open relay) using phony usernames attributed to my domain. Since a fair number of emails being sent as spam go to addresses that have been abandoned, I have begun to receive a steady stream of postmaster emails (mostly from aol) informing me that the spammers email has bounced. If I were to enable verify functionality, the spam filters at aol (and other servers) could at least determine that the email address was invalid and not feel compelled to notify me. Since spammers are misusing my domain name, it seems that even though I am not running James as an open relay, my domain name is at risk of being blacklisted as a result of misuse by others. As it happens, the email addresses I have configured on my mail server are well known to spammers anyway, since they were long ago harvested from internic records and/or web pages. My questions then are: 1) How does this scenario fit in with the "NoFastFail" rationale? Is this a possible exception, or am I being too simple-minded? 2) Is this functionality already being built by anyone? (I didn't see it in the archives) 3) Is this something that the maintainers of James would like as an optional feature. In other words, if I implement it, should I contribute it? Thanks for any feedback/opinions you can offer... - Steve Robenalt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Doco
> what mail client do you use that allows you to setup > multiple outgoing servers like this? Outlook. I have a dozen different accounts, with different servers and/or identities (@apache, @devtech, @other-organizations). My brother uses Mozilla, and it supports similar AFAIK. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build process in maven?
Noel J. Bergman wrote: Amusingly enough, I was just asking Dion that question last night. I do suggest that we make the effort to merge the branches before we re-do the build process, at this point. +1000 --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build process in maven?
Serge Knystautas wrote: Any opinions on migrating to doing builds using maven? I have only cursory experience with it, but it's been generally positive, and it helps address the javamail.jar and activation.jar issues. Maven will not help you with the javamail.jar and activation.jar issues because these resources are licensed under the basis that they are packaged with an aplication (i.e. like what we do with a sar file or a bar file). As far as building is concernined - then you still need to request a manual download. Aside from that - moving to a maven build would be good - all of the cornerstone, excalibur, and avalon framework is already on maven and available via repote repositories. One other point - If you running James under Merlin - then Merlin can auto load James from a remote repository. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Build process in maven?
Amusingly enough, I was just asking Dion that question last night. I do suggest that we make the effort to merge the branches before we re-do the build process, at this point. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Hi Serge, I'm not familiar with what mozilla/thunderbird exactly is , but I use mozilla's stadard mail client and it allows multiple outgoing servers. I can create several outgoing servers and configure each of my incoming accounts to send outgoing mail through any one of them. I can't set it up so that 1 incoming account can choose between 2 outgoing on the fly or anything, but in the configuration I can define x number of mail servers and set my incoming accounts to use whichever. Kenny Serge Knystautas wrote: Out of curiosity, what mail client do you use that allows you to setup multiple outgoing servers like this? I use mozilla/thunderbird, and it can handle multiple incoming accounts, but all use the same outgoing SMTP server. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Noel J. Bergman wrote: I do agree it would help reducing the risk, but would all moderator's SMTP server support that? Ah :-) I was expecting that the moderator would connect *directly* to moof, in which case only their MUA would have to support SMTP AUTH and SSL. Out of curiosity, what mail client do you use that allows you to setup multiple outgoing servers like this? I use mozilla/thunderbird, and it can handle multiple incoming accounts, but all use the same outgoing SMTP server. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] Doco
> doco has a very precise editing access point. You can > *ONLY* modify xml content. > The unique and only security concern here is defacement. OK. So not the full site content, just the XML content and images? So then the exposure is "only" defacement, page hijacking through a REFRESH meta-tag, scripting exploits, etc. > I really appreciate your concerns and, please, keep in mind that I read > and send my email via SSH tunnels Same here. :-) > I think you proposed to use SMTP over SSL for mail relay, that would > reduce the ability of somebody to prevent sniffing the continuation-ID > and provide that attack. STMP AUTH over SSL. Moderators would have a password, and SSL would protect it. > I do agree it would help reducing the risk, but would all moderator's > SMTP server support that? Ah :-) I was expecting that the moderator would connect *directly* to moof, in which case only their MUA would have to support SMTP AUTH and SSL. > Another solution is to force moderators to digitally sign their email, > but this would require a much more intrusive setup. I wasn't suggesting such, no. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build process in maven?
Any opinions on migrating to doing builds using maven? I have only cursory experience with it, but it's been generally positive, and it helps address the javamail.jar and activation.jar issues. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug in RemoteDelivery mailet?
> This reminds me (again -- I wrote the same thing on October 11, in > response to a question) of something I've seen in the finally block > in org.apache.james.dnsserver.DNSServer.findMXRecords(hostname). > If the DNS lookup fails to find MX records, then findMXRecords() may > return simply the hostname from the email address. See RFC 2821, section 5: "If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host." --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Bug in RemoteDelivery mailet?
Long answer: The MX records are looked up using dnsjava, and should use the DNS servers that you should (must with James v2.1) configured in SAR-INF/config.xml. The code can be seen in http://cvs.apache.org/viewcvs/james-server/src/java/org/apache/james/transpo rt/mailets/RemoteDelivery.java?annotate=1.33.4.13 on line 288. That calls getMailServers on lines 609-618 in http://cvs.apache.org/viewcvs/james-server/src/java/org/apache/james/James.j ava?annotate=1.35.4.11. Finally, you'll be in http://cvs.apache.org/viewcvs/james-server/src/java/org/apache/james/dnsserv er/DNSServer.java, starting on line 210. Short answer: Set the DNS servers in SAR-INF/config.xml and/or try the latest test build, which will attempt to detect valid DNS servers. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
bogus attribution in license
the james license states that: Portions of this software are based upon public domain software originally written at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign. but this is not true. I suggest you to fix this. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in RemoteDelivery mailet?
Mike Morris wrote:
It seems that the RemoteDelivery mailet is trying to connect to the IP
address that the DNS returns for the domain, and NOT (one of) the
servers listed as the MX host. I am pretty sure of this, based on
watching netstat while James is making the connection.
Mike,
This reminds me (again -- I wrote the same thing on October 11, in
response to a question) of something I've seen in the finally block in
org.apache.james.dnsserver.DNSServer.findMXRecords(hostname). You can
see the code below. If the DNS lookup fails to find MX records, then
findMXRecords() may return simply the hostname from the email address.
So possibly your MX lookup is not working. I would check first to
confirm that you have the nameservers configured correctly.
Rich Hammer
} finally {
//If we found no results, we'll add the original domain
name if
//it's a valid DNS entry
if (servers.size () == 0) {
StringBuffer logBuffer =
new StringBuffer(128)
.append("Couldn't resolve MX records for
domain ")
.append(hostname)
.append(".");
getLogger().info(logBuffer.toString());
try {
InetAddress.getByName(hostname);
servers.add(hostname);
} catch (UnknownHostException uhe) {
// The original domain name is not a valid host,
// so we can't add it to the server list. In this
// case we return an empty list of servers
logBuffer = new StringBuffer(128)
.append("Couldn't resolve IP address
for host ")
.append(hostname)
.append(".");
getLogger().error(logBuffer.toString());
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Stefano Mazzocchi wrote: That is a *very good point* and I think you are perfectly right: we should put it into Doco. Any idea on how to do it? *blush* In my layman's thinking, I would envision this as some special Woody widget which generates a random image for display, makes it available across some session-specific URI and does validation of the associated verification field on submit. Housekeeping of these temporary resources will be the main burden, plus some Java2D hacking, which apparently has been explained in DrDobbs already. Maybe the continuation id can be used for the temporary URI. http://james.seng.cc/archives/000145.html seems to be a standalone Movable Type implementation. Sourceforge is down ATM so I can't check on the license and usability of the Sapience code. This doesn't help a lot of course, but as we seem to be converging into making rich-text editing "just another Woody widget" [1], we might as well add this one to the list of TODOs for cool Woody/cForms. [1] Spoiling Bruno's "lonesome hacking cowboy" thought train, I just want to confirm that he actually started working on this. He's still in a grumpy "friggin' stupid and unstable web browsers and Javascript as a development hosting environment" mood, though, so please light a candle for him. ;-) -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
On Tuesday, Oct 28, 2003, at 13:10 Europe/Rome, Steven Noels wrote: Stefano Mazzocchi wrote: Doco came to my mind when finding http://kokochi.com:8080/sapience/test.jsp in Hippo's blog. Can I be anal for a sec? LOL. Sure, as long as you wipe properly afterwards, no problem here. :-) cool, but what do we do with it? Well, since people had to come up with anti-spam measures for weblog comments, because of some nitwits which abuse the comment facility of modern weblog engines using automated tools, to raise Google rankings of spam-linked websites, I figure the same will start happening with any light-weight content contribution tool in the upcoming months. We have seen similar abuse on the Cocoon wiki as well. Rather than completely offload the burden of moderation to a bunch of people, we should come up with an upfront facility for blocking automated abuse. Similar to the facilities found in MSN Hotmail, Paypal and others who use some generated image to validate sign up for their system, having something like this Sapience thing might reduce the moderation burden in the long run. It's cool for sure, but it might be some good way to make sure only humans edit content, and not a bunch of malevolent bots. That is a *very good point* and I think you are perfectly right: we should put it into Doco. Any idea on how to do it? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
In order to get myself into the "Doco" discussion I have created a Wiki page at (I was busy moderating emails for lenya-dev ...) http://wiki.cocoondev.org/Wiki.jsp?page=Doco where I have compiled Stefano's original proposal and added issues from the various email threads. Would be nice if people could compile ideas into this page in order to find consensus. Hope this helps to get an overview and development started. Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Stefano Mazzocchi wrote: Doco came to my mind when finding http://kokochi.com:8080/sapience/test.jsp in Hippo's blog. Can I be anal for a sec? LOL. Sure, as long as you wipe properly afterwards, no problem here. :-) cool, but what do we do with it? Well, since people had to come up with anti-spam measures for weblog comments, because of some nitwits which abuse the comment facility of modern weblog engines using automated tools, to raise Google rankings of spam-linked websites, I figure the same will start happening with any light-weight content contribution tool in the upcoming months. We have seen similar abuse on the Cocoon wiki as well. Rather than completely offload the burden of moderation to a bunch of people, we should come up with an upfront facility for blocking automated abuse. Similar to the facilities found in MSN Hotmail, Paypal and others who use some generated image to validate sign up for their system, having something like this Sapience thing might reduce the moderation burden in the long run. It's cool for sure, but it might be some good way to make sure only humans edit content, and not a bunch of malevolent bots. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
On Tuesday, Oct 28, 2003, at 10:11 Europe/Rome, Steven Noels wrote: Stefano Mazzocchi wrote: 2) minimal, efficient and secure workflow (should satisfy board@ security concerns) FWIW: Doco came to my mind when finding http://kokochi.com:8080/sapience/test.jsp in Hippo's blog. Can I be anal for a sec? cool, but what do we do with it? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
On Tuesday, Oct 28, 2003, at 09:32 Europe/Rome, Danny Angus wrote: Stefan wrote: So, adding SSL relay wouldn't hurt, but wouldn't help much either since we can't force moderators to have a mail server that accepts that kind of relay (don't even know if mine does!) I think what should happen to ensure this level of integrity would be that moderators should connect to an account on the James instance managing the doco mail, in which case it means your client has to support ssl. hmmm, this means that we have to create james accounts for all moderators, then force them to connect thru POP3 over SSL? don't know, the more I think about this, the more it seems overkill to me: the current moderation system is done over the plain wire and nobody ever spoofed the IDs to inject spam into our mail lists. I say we go with plain text and, if something happens, we fix it the incremental way. For now, let's just do the simplest thing that can possibly work. Otherwise you're at the mercy of the ability of intermediate hops to preserve your security, and it becomes worthless again. yep An other suggestion might be to require moderators to sign and encrypt their messages with PGP. I know thats it's possible for James to cope with this, but AFAIK noone has shared any code with us. I wouldn't go down this path. it is too intrusive for the moderators's setup. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
On Tuesday, Oct 28, 2003, at 11:14 Europe/Rome, Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote: On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote: nah, dude, look: doco has a very precise editing access point. You can *ONLY* modify xml content. So, changes to .htaccess, CGI scripts, servlet upload, sql injection, cross-site-scripting, and you next favorite attack will NOT work because the system prevents it by design [not saying it cannot happen, but if it does it's a bug, not a faulty design] FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even better?, schema/dtd validation). If it fails, it doesn't even enter the approval process. Absolutely. This wasn't mentioned, but planned. I will do relaxng validation before allowing any xml data into the system. This should be enough for documentation. Forrest also uses other files as source formats: cwiki (wiki) ihtml (cleaned html) ehtml (passthrough html) txt(text files) Linotype will generates XHTML only and this is what forrest will have to process. Perhaps a notification email is sent describing that an invalid submittal was sent. Nah, it would just fail and log the failure. No need to spam further since it might well be a bug in the editing software ;-) [I have experienced a few of them as well] The user is returned an error page saying the post was rejected, in case it was just a mistake. On another note, can images/PDFs/other-binaries be uploaded? Damn, forgot about this! My suggestion would be to process the binary file and determine if it's an image or not. If not, reject it right away. [there should be *NO* need to upload any other binary file ] For uploads of binary resources, we can limit them to the ones we want to cater for as forrest content as images. For the other types of things that are to be rendered as "raw", like PDFs, tarballs, javadocs, etc, we will have to use the same method we use now. No. File upload will be limited to images for now. Too risky to allow anything else. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Stefano Mazzocchi wrote: On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote: nah, dude, look: doco has a very precise editing access point. You can *ONLY* modify xml content. So, changes to .htaccess, CGI scripts, servlet upload, sql injection, cross-site-scripting, and you next favorite attack will NOT work because the system prevents it by design [not saying it cannot happen, but if it does it's a bug, not a faulty design] FWIW, I agree. Perhaps the submit goes to a well-formedness check (or even better?, schema/dtd validation). If it fails, it doesn't even enter the approval process. Absolutely. This wasn't mentioned, but planned. I will do relaxng validation before allowing any xml data into the system. This should be enough for documentation. Forrest also uses other files as source formats: cwiki (wiki) ihtml (cleaned html) ehtml (passthrough html) txt(text files) Perhaps a notification email is sent describing that an invalid submittal was sent. Nah, it would just fail and log the failure. No need to spam further since it might well be a bug in the editing software ;-) [I have experienced a few of them as well] The user is returned an error page saying the post was rejected, in case it was just a mistake. On another note, can images/PDFs/other-binaries be uploaded? Damn, forgot about this! My suggestion would be to process the binary file and determine if it's an image or not. If not, reject it right away. [there should be *NO* need to upload any other binary file ] For uploads of binary resources, we can limit them to the ones we want to cater for as forrest content as images. For the other types of things that are to be rendered as "raw", like PDFs, tarballs, javadocs, etc, we will have to use the same method we use now. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug in RemoteDelivery mailet?
Hi all, I am trying to track down a possible bug in the RemoteDelivery mailet or its dependencies and could use a little help. (I am using James 2.1 from the binary distrib., but looking at source from CVS head, which may be a problem...) Symptoms: For some (usually big -- hotmail, bigfoot, netscape) sites, I end up with messages stuck in the outgoing queue, with retries every hour until the spooler gives-up. This is a big problem for me. As things are, my DNS server happens to be on the same machine as the James mailserver; DNS is well configured, and the sites in question are being correctly resolved, as are their MX records. It seems that the RemoteDelivery mailet is trying to connect to the IP address that the DNS returns for the domain, and NOT (one of) the servers listed as the MX host. I am pretty sure of this, based on watching netstat while James is making the connection. e.g. I am sending mail to a user at bigfoot.com (64.15.239.150). Their MX hosts are listed by dig as being at bigfoot.com.30531 IN MX 10 mail-kr.bigfoot.com. bigfoot.com.30531 IN MX 20 mail.bigfoot.com. (+ 6 more) to be found at mail.bigfoot.com. 29917 IN A 64.15.239.131 (etc.) When trying to deliver the message, the mailet connects to 64.15.239.150:25 instead of 64.15.239.131:25, and, of course, times out since there (presumably) is no SMTP server at 64.15.239.150 (confirmed by telnetting to it). Can anyone tell me where and how the MailetContext gets initialised so that I can take a look through that code to see if the error is there. Of course it may be all the way back in the com.sun.mail.smtp provider, since the stack trace provided my the mailet tells me java.net.ConnectException: Connection timed out at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:911) ... OH! I am using JDK1.4.2 on Linux fwiw... -- mike morris :: mike.morris (at) cocosoft . co . za cOcO software :: mike.morris (at) coco-technologies . co . za www . cocosoft . co . za - A day without chillies is a day wasted -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [proposal] Doco
Stefano Mazzocchi wrote: 2) minimal, efficient and secure workflow (should satisfy board@ security concerns) FWIW: Doco came to my mind when finding http://kokochi.com:8080/sapience/test.jsp in Hippo's blog. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Doco
Stefan wrote: > So, adding SSL relay wouldn't hurt, but wouldn't help much either since > we can't force moderators to have a mail server that accepts that kind > of relay (don't even know if mine does!) I think what should happen to ensure this level of integrity would be that moderators should connect to an account on the James instance managing the doco mail, in which case it means your client has to support ssl. Otherwise you're at the mercy of the ability of intermediate hops to preserve your security, and it becomes worthless again. An other suggestion might be to require moderators to sign and encrypt their messages with PGP. I know thats it's possible for James to cope with this, but AFAIK noone has shared any code with us. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
