Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
In Cuba, web access is extremely censored, so I created a tool that allows more than 50,000 people to browse the Internet through email. Cubans send me an email with an URL in the subject line, and I email them back with the response. Read more at https://apretaste.com.
It was working like a charm, till the communist government of Cuba started blocking my emails. My solution was rotation.
I started with Amazon SES, and I was changing the domain each time it was blocked, but Amazon adds a header to all emails, and once they blocked the header no email from SES was able to reach Cuba any more. The same happened with Mailgun and others, they all add headers.
Currently I am creating Gmail accounts and sending via SMTP, but Google blocks me for no reason and only allows to send 100 emails a day per account. Also I can only create few emails using the same IP address/phone, so I was forced to use anonymous proxies and fake Chinese phones. Now I am fighting a war on two fronts.
An email can be blocked by three parameters: IP address, domain, and email address.
It will be terrific if I can set up my own Postfix server at a VPS that auto-rotates the IP address. Even better if I can simulate "gmail.com", to avoid purchasing a new domain every day.
All the intents to create what I call "the ultimate sender" just either reach the spam folder or add unwanted headers making it too easy to block. I feel exhausted. I hit a knowledge barrier here.
I know I am crossing to the dark side, but this is for a very good cause. Thousands count on this service as their only source of unbiased news, social network and to feel part of the 21st century.
Can you please help me implementing "the ultimate sender", or pointing to another solution that I may be missing?
I have a few suggestions for you.
The first one relies on The Onion Router also known as Tor.
Since you are crossing to the dark side, why not also take a look into the darknet?
Take a look at this list of Tor email providers. If you have your own email server that can be accessed through Tor, it becomes much harder for anybody to stop people from using this service. After all, Tor was developed to offer people uncensored access to the web.
You can read about Tor in detail here, it uses Onion Routing and this is how you would set up your server to use Tor.
Here is an example how you could use it:
The steps that involve the setup, receiving an URL request and sending back the reply are as follows:
Set up an email server.
Configure your email server to use Tor.
Publish the public service name. (e.g. "duskgytldkxiuqc6.onion")
Deploy a client that takes the service name and a URL, and let it send an email with a request to your server.
The client now waits for a reply.
You send a reply and the client receives it.
You can change your service name on a regular basis, but you need to make it accessible to those who will use this service.
Having an own email server means being able to control the email header.
Here is one example how you could make use of it:
Configure your email server so that it receives and recognizes
emails which contain the requested URLs.
Before you send a reply modify the email header so that it shows a random IP address and a random sender email address including a random domain name.
Send your reply.
Sending an email that way means that you cannot be replied back to. But since your reply already contains the requested information there is no need to.
I hope this helps.
Crowd source it.
Find a way that volunteers can send some emails for you. This is the only long term approach that I can think of. A simple web interface with mail to links would be be enough to get started although there are other potential problems with this approach too.
Because you are talking about low numbers of users, you could also use crowdsourcing to create the single email address per person approach. They can create an account on a specific set of email providers and give you the credentials. This would allow the single email per user approach or could be used to rotate through a large set of email accounts to send emails.
The simplest solution is perhaps to set up a local SMTP server on your own computer. You don't even need a server per se.
https://sourceforge.net/projects/winsmtpserver/
There are many other such applications. They are usually used to test SMTP functions during local development, but there is nothing against actually sending spam through them.
I know this would be quite a large task, but how about pairing the users with one or just a few emails so they always receive an email from that email.
I'd assume people wouldn't have more than 100 queries per day, if so they could start receiving them from a backup email
I'd imagine it would look less suspicious for them to appear to be in constant contact with one unique email rather than 50,000 being in contact with one
I know this would be a huge undertaking, but I feel like it solves your issue.
Since the users are willing to receive emails form you then your shouldn't be blocked.
When you mentioned you are getting block does it mean your mail is going in spam or is getting lost in between sending and receiving or it is getting bounced back??
My suggestion would be to setup your own mail server and follow as below:
-Get approx 25 or more ip to rotate. (IP is the most imp part which is tracked and is accountable for the reputation of your mail server)
Don't start sending emails in bulk from the word go it is better to gradullay increase the email volume so that mail server reputation nicely built
keep changing the format of the email often
encourage user to add yourself to there contact list
your best part is user are willing to receive emails from you and you would reply to revived email is the USP of yours but still i will recommend you to register for FBL so that you would know which user is reporting you as spam and you can remove him from your list and never send him email again.
using best practice to send emails like dkim, SPF, dmarc are also vital.
Hope my answer was of some help to you. If you need step by step guide to step up mail server let me know.
My friend, do you remember what made Hillary Clinton lose the last elections to Trump?
It was the "mail" affair. And what was it? People discovered she shared confidential information through a non-official, non-governmental email account (i.e., she used some Gmail, Yahoo or another of a kind). Until here, nothing new with direct relation to your matters. But there is an small particularity on this history, and this can put, maybe not a solution, but maybe a light on a new path you could follow: Clinton actually never sent those emails; the email account she used had the password shared and the communication between people (Clinton-someone) occurred only using the drafts of the account.
How? One side logs in and accesses the drafts folder. There he/she reads the last message and edits it, cutting and writing new data - then save the draft message. On the next turn, the other side of the communication line logs in and do the same. And so forth, so never really sending those messages, but instead just updating the drafts (this "Hillary" method does schooled people... Dilma Rousseff, impeached ex-president of Brazil, actually did this method down there in Brazil too).
So, maybe if you could establish a pact with your user that he/she doesn't delete the account's password, you could pass those information by this method - without "really" exchanging emails. Maybe a "parent" email account (some that could reset a lost password) could be useful too.
Alternative: aren't you able to contract a regular HTTP webserver? You could rely on FTP to publish data to your user, he/she asks for it and you publish a page with that content.
Salvi, have you tried something with Telnet? OK, we are talking here about a text-only environment, but if nothing more would rest in the future, this could be better than nothing. Maybe you could implement a podcast-like, or push-like service based on it. Look what people do with it with references to your walk on the dark side...
If in Windows, open your command prompt.
Type telnet and press Enter.
Type "o" without quotes and press Enter.
Type "towel.blinkenlights.nl" without the quotes and press Enter.
Related
I am build a tool that initiates an SMTP transaction with a domain to see if (a) that domain can receive emails and (b) the desired address exists on that domain. I will be batching large groups of email addresses (10,000+ at a time), but I don't want to bombard the server and get blacklisted. Are there guidelines for how often is it safe to communicate with an SMTP server?
I know about the VRFY command, but it is not implemented across the board. I plan to attempt to use the VRFY command and fall back to using,
MAIL From:<user#example.com>
RCPT To:<first.last#example.org>
QUIT
to see if the message will be deliverable. Again, are there guidelines on how often I can initiate an SMTP transaction like this on a domain?
Edit:
The purpose of this is to create a tool that my organization can use to (a) clean some bad emails from several largely inactive lists so that we do not have to pay our email delivery system to send potentially thousands of emails that will bounce, and (b) check an email when a user subscribes to a list so that we reject emails like aoghuifdgsiuvb#gmail.com.
First of all, spamming is bad. Always ask user wheter she wants to receive newsletters.
"Unsort" mail addresses by domain, leaving the "distance" between e-mail addresses with same domain as big possible.
I think it's not the programmer's decision. There should be a config value which tells a minimum amount of time between two mail sending to the same domain. You should set up a limit also for that config value, avoid setting it to zero or low value.
The only universal guideline I believe can be offered is "don't do this". If you behave like a spammer, you will be treated like a spammer. In the optimistic scenario, sites will already have controls in place, and silently throttle or block you. In less ideal scenarios, they will initiate actions against you on the (reasonable) assumption that you are collecting addresses for a spam list.
A better soluton would be to actually follow through the whole SMTP session, sending a user an email with a verification code/link. This has the advantage of showing that the user actually has control of the address in question and it keeps you from looking like a spam bot.
Volume is not as much the issue as reputation. Let the user know you're about to send them an email in your web flow. This means they're much less likely to mark it as spam.
some hosts have clear and defined guidelines as to how many emails can be sent per hour.
So i guess this would depned onyour hostng service provider, UNLESS your hosting your own mail server off course.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As per this question I asked previously on Google App Engine, if I have access to all the information in a standard email, not just the From, To, Subject, Body fields, but also all the headers and MIME information, how can I verify that two incoming emails with the same From address are actually from the same sender.
What I've considered thus far:
Check the IP address of the email's sending server
Check the DNS records of the email's sending server
Verify the sending agent of the email (i.e. web interface, Outlook, Thunderbird, etc)
Check the reply-to field
Etc.
I realize this is a complicated question (I'm sure companies like Posterous have spent tons of time on this problem). I'm just looking for a few criteria to get started preliminarily. Thanks!
Update:
The answers so far are really helping, but just to help them out, the context of my project is that I would be receiving tons and tons of email as a web app from my users. They would use their email as the primary way of inputting data into my system. This I why I made the Posterous analogy. The use case is very similar.
You're right that all of the headers together, and 'known good' email to compare to can help identify likely spoofed emails.
What you're developing would probably be at best a heuristic rather than an algorithm.
I'd consider weighting the fields by time-of-day and how close to 'known good' emails' time-of-day ...
Also, if the 'known good' emails are structured differently than the suspect; i.e. Inline images, html, shortened url's, etc.
Why not run the emails through spamassassin or some such filter that will attach a bayes score. You can then just read that score. It will save you reinventing the wheel.
You could bayes score the email against a database of all previous emails from the individual.
There is also looking up the Sender Permitted Framework and DomainKeys, which SpamAssassin can do for you.
Probably not practical but something that would work:
When an incoming mail arrives, have a "reply to sender" function and simply ask if they sent it. This could be in the form of a confirmation link that is automatically generated or something.
But since I don't know the specifics of the project this may not be practical... like if you had to do this multiple times for each user, no one would put up with it.
Just to compliment my brothers posting earlier:
Not knowing the context under which you want to analyse this, and being very general I would suggest your first port of call is SPF or DomainKeys in order to limit the possibility of email coming from a rogue source being accepted. I would also recommend using only one SMTP server with SSL security. I do this and travelling worldwide I have rarely been in a situation I couldn't send mail and in those cases the only thing that did work was webmail (no safe local SMTP).
Additionally to that: if you are verifying mail is really coming from yourself then you could also use PGP tools to sign your mail upon sending and then filter any mail that didn't have a valid signature. Enigmail in Thunderbird is a good source of automatic signing and there are plugins for Outlook as well.
After that if you really want to do a more forensic job on an email then you could use a Spam Bayes to score the email against a database of previous emails. You would build up a database of tokens around the non-unique data (excluding entries such as "To:") and then score the email for the probability that it is like the previous emails. In theory you should score very highly for any mail.
Obviously I don't know your situation, but I think that there are many techniques but sometimes it is easier to go to the root of the issue than try and fix it down the line.
Update
Based on the context supplied:
I would consider using "Address Extensions" this is where your user can send mail to an address which contains a reference using the email address: emailname+extension#domain.com
GMail and many other servers support delivery of email with a +extension# through to the correct emailname#domain.com without hi-jinx. You could get the user to deliver mail with a unique ID as the extension and that way you would know it had come from them and they would feel more special. Obviously someone could steal their unique code by sniffing their outgoing or your incoming mail but that is always possible and if someone can do that they can probably inject mail as well.
If you really just want to go down the analysis route then I would suggest just using the reverse of a SpamAssassin per-user Bayes match. Where you compare every mail to a database of mails from a sender (instead of the traditional matching of mails 'to' an account). Remembering that once your database is polluted with a false positive you will have to remove the false positive or risk the integrity of the matching for that sender.
Maybe look into using Sender Policy Framework. It might not be exactly what you are looking for but it might help.
Briefly, the design intent of the SPF record is to allow a receiving MTA (Message Transfer Agent) to interrogate the Name Server of the domain which appears in the email (the sender) and determine if the originating IP of the mail (the source) is authorized to send mail for the sender's domain.
Ripped from wikipedia:
Sender Policy Framework (SPF), as
defined in RFC 4408, is an e-mail
validation system designed to prevent
e-mail spam by addressing a common
vulnerability, source address
spoofing. SPF allows e-mail
administrators the ability to specify
which Internet hosts are allowed to
send e-mail claiming to originate from
that domain by creating a specific DNS
SPF record in the public DNS record.
Mail exchangers then use the DNS
record to verify the sender's identity
against the list published by the
e-mail administrator.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have my domain's email set up with Google Apps, and I am interested in sending automated emails (when users register, for example) with the From and/or Reply-To field being "no-reply#example.com". I have a few questions pertaining to how this is done:
Should I actually set up a user in Google Apps named "no-reply"?
If not setting up a "no-reply" user, should I log in with a real address (e.g.: "support#example.com") and send the email as being from "no-reply#example.com" instead? Or should I simply use the Reply-To email header?
If it's necessary to use the Reply-To header, is there a way to block the true From address (i.e.: the username I used to log into Google's SMTP server)?
Yes, you should setup a separate noreply address on your email server.
There are excellent reasons why you should set up a no-reply email address.
Why is it important to have a no-reply on bulk emails?
Many of the recipients of the email will try to hit 'reply' and they will have a multitude of reasons for doing so. Often, it is not sensible to have all of these going to a single representative at your company. Furthermore, many emails from bulk lists will be bounced back. You don't want to have to sift through these in order to find legitimate questions from your mail outs.
The best way to respond to questions rather than replying to bulk emails, is to have the recipients direct their questions to appropriate response emails either through their usual contact or via your company website.
What if recipients DO hit the reply button?
The email originator for the bulks should not just silently swallow the replies. Many companies do this and as a result, legitimate replies are ignored without any indication to your client or potential client and they, feeling neglected, go elsewhere for business.
The originating email account should be set up with an auto-responder explaining that the email was not processed and suggest alternative ways of contacting your company.
In gmail this can be done by setting up a Vacation responder with no last day. You can find the Vacation responder feature under the General tab of the account settings.
Avoid having extra accounts by setting up no-reply as a group that restricts users from outside your domain sending to it.
Unless you can think of a really good reason for it, I would suggest that you send your emails from support# rather than no-reply#.
The whole reason for a support# email address is to receive comments and feedback from your userbase, and if you're sending them emails why bother making it hard for them? If they can just reply to the email you'll receive way more feedback that way.
I suggest you set up a "Nickname" alias ( Manage Domain > Users > edit user > Add Nickname ). Then create a filter that sends any reply to that nickname straight to trash or spam.
Just set up a "no-reply" account. It won't hurt anything, people will still try to send stuff to it, and it will serve your purpose.
As for the latter two questions, it depends.
If you're sending these e-mails as a part of an automated script (i.e. forum registration) just use the "no-reply" accounts credentials. Log in periodically to make sure you aren't getting legit delivery errors (as opposed to the jokers that use fake e-mail addresses) or other odd behaviour.
If you're not sending these e-mails as a part of an automated script, it depends. If you also manage a support address (support#example.com, staff#example.com, etc.) you may want to send on behalf of, and use the reply-to. But this part is a little more subjective, and really depends on your setup.
I don't know if this will help or not, but IIRC, with gmail you can do something like
name+something_else_here#domain.com
Then, set up a filter so that emails with that "something_else_here" part go past the inbox to a label.
Does that help?
I think creating a user named no-reply is a bad approach. An alias or a restricted group is a much neater and functional solution IMHO. Also, google apps cost is based on user number.
A cool way to handle this would be using the vacation setting in GMail to send an automated response back on the no-reply email address. The vacation reminder would then remind users that this is an unmonitored email address.
I think the right thing to do is setup a filter that sorts your mailer-daemon messages into a special folder (Or trash if you so desire.) Or, like other comment have suggested, use a separate mail address.
noreply is good to indicate to people that this isn't an address you check, but it's not really the solution to dealing with bounce mail. In fact it's more likely your mail will end up in spam filters because your attempt at sender obfuscation will just look like spam to the receiving host.
You should create a noreply user. But use it as a spam mail (when registering unknown sites) and a mail for testing.
A number of applications have the handy feature of allowing users to respond to notification emails from the application. The responses are slurped back into the application.
For example, if you were building a customer support system the email would likely contain some token to link the response back to the correct service ticket.
What are some guidelines, hints and tips for implementing this type of system? What are some potential pitfalls to be aware of? Hopefully those who have implemented systems like this can share their wisdom.
Some guidelines and considerations:
The address question: The best thing to do is to use the "+" extension part of an email (myaddr**+custom**#gmail.com) address. This makes it easier to route, but most of all, easier to keep track of the address routing to your system. Other techniques might use a token in the subject
Spam: Do spam processing outside the app, and have the app filter based on a header.
Queuing failed messages: Don't, for the most part. The standard email behavior is to try for up to 3 days to deliver a message. For an application email server, all this does is create giant spool files of mail you'll most likely never process. Only queue messages if the failure reasons are out of your control (e.g., server is down).
Invalid message handling: There are a multiple of ways a message can be invalid. Some are limitations of the library (it can't parse the address, even though its an RFC valid one). Others are because of broken clients (e.g., omitting quotes around certain headers). Other's might be too large, or use an unknown encoding, be missing critical headers, have multiple values where there should only be one, violate some semantic specific to your application, etc, etc, etc. Basically, where ever the Java mail API could throw an exception is an error handling case you must determine how to appropriately handle.
Error responses: Not every error deserves a response. Some are generated because of spam, and you should avoid sending messages back to those addresses. Others are from automated systems (yourself, a vacation responder, another application mail system, etc), and if you reply, it'll send you another message, repeating the cycle.
Client-specific hacks: like above, each client has little differences that'll complicate your code. Keep this in mind anytime you traverse the structure of a message.
Senders, replies, and loops: Depending on your situation, you might receive mail from some of the following sources:
Real people, maybe from external sources
Mailing lists
Yourself, or one of your own recipient addresses
Other mail servers (bounces, failures, etc)
Entity in another system (my-ldap-group#company.com, system-monitor#localhost)
An automated system
An alias to one of the above
An alias to an alias
Now, your first instinct is probably "Only accept mail from correct sources!", but that'll cause you lots of headaches down the line because people will send the damnedest things to an application mail server. I find its better to accept everything and explicitly deny the exceptions.
Debugging: Save a copy of the headers of any message you receive. This will help out tremendously anytime you have a problem.
--Edit--
I bought the book, Building Scalable Web Sites, mentioned by rossfabricant. It -does- have a good email section. A couple of important points it has are about handling email from wireless carriers and authentication of emails.
You can set the address that the email is sent from, what will be put into the To: address if someone just presses 'Reply-to'. Make that unique, and you'll be able to tell where it came from, and to where it must be directed back to.
When it comes to putting a name beside it though '"something here" ' - put something inviting to have them just reply to the mail. I've seen one major web-app, with Email capturing that has 'do not reply', which turns people off from actually sending anything to it though.
Building Scalable Web sites has a nice section on handling email. It's written by a Flickr developer.
(source: lsl.com.au)
EDIT: I misunderstood your question.
You could configure your email server to catch-all, and generate a unique reply-to address. E.g. CST-2343434#example.com.
A polling process on the server could read the inbox and parse out the relevant part from the received email, CS-2343434 could mean Customer Support ticket ID no. 2343434.
I implemented something like this using JavaMail API.
Just a thought.
The best way to achieve this will be to write a window service that acts like a mail client [pop3 or imap]. This windows service should execute a timed action triggered by a timer, which connects to the mail server and polls the server for any unread message(s) available in the email inbox. The email ID to check for is the email ID on which the users will give their input on/to. If the windows service client finds that there exists any new mail(s) then it should download and filter the email body and push further for processing based on the user input in the email. You can host the input processing in the same windows service but it is not advisable to do so. The windows service can put the inputs in a special application directory or database from where your main appication can read the user inputs received in email and process them as needed.
You will be required to develop a high performance TCP/IP client for doing so. I advise you not to use the default .Net library due to performance issues, instead use one of the best availabel open source TCP/IP implementations for .Net like XF.Server from kodart. we have used this in our applications and achieved remarkably grear results.
Hope this helps..
Bose has a pretty great system where they embed a Queue and Ticket ID into the email itself.
My company has the traditional Case # on the subject line, but when CREATING a case, require a specific character string "New Case" "Tech Support Issue" on the subject line to get through the spam filters.
If the email doesn't match the create or update semantics, the autoresponder sends an email back to the recipient demonstrating how to properly send an email, or directs them to our forums or web support site.
It helps eliminate the spam issue, and yet is still accessible to a wide technical audience that is still heavily email dependent.
Spam is going to be a bit of a concern. However since you are initiating the conversation you can use the presence of your unique identifier (I prefer to use the subject line - "Trouble ticket: Unable to log into web...[artf123456]") to filter out spam. Be sure to check the filter on occasion since some folks mangle the subject when replying.
Email is a cesspool of bad standards and broken clients. You need to be prepared to accept almost anything as input. You will need to be very forgiving about what kinds of input are tolerated. Anything easy for you to program will likely be difficult for your users to use correctly. Consider the old mailing list programs that require you to issue commands in the subject line. Only hardcore nerds can use those effectively. And some of those trouble-ticket CRM things you mentioned have bizarre requirements, such as forcing the user to reply between two specific text markers in the text. That sort of thing is confusing to people.
You'll need to deal with email clients that send you formatted text instead of plain text. Some email clients still don't handle HTML properly (cough GMail) so your replies will also need to be designed appropriately. There are various ways in which photos might be "uploaded" via email as well, especially when mobile phones are involved. You will need to implement various hacks and heuristics to deal with these situations.
It's also entirely possible that you will get email that is valid but unusable by the email parsing library you are using. Whether or not this is important enough to roll your own will be a judgement call.
Finally, others have mentioned using specific email addresses to uniquely identify a "conversation". This is probably the easiest way to do this, as the content of the mail will often not survive a round trip to a client. Be prepared, however, to get mail to old IDs from old customers who, instead of opening a new ticket somehow, reply to an old ticket. Your application will probably need some way to push emails with an old ID into a new case, either manually or automatically. For a CRM system it's very likely that a user would reply to an old email even if you already sent him a new email with a new ID in it. As for whether you should use some.email.address+some.id#yourdomain.com or just some.id#yourdomain.com, I'd go with the latter because the plus-sign confuses some email clients. Make your IDs guids or something and have some way to validate them (such as a CRC or something) and you'll get less junk. Humans should never have to type in the GUIDs, just reply to them. The downside is spam filtering: a user's computer might view such email addresses as spam, and there wouldn't be an easy way to whitelist the addresses.
Which reminds me: sending email these days is full of pitfalls. There are many anti-spam technologies which make it extremely hard for you to send email to your customers. You will need to research all of these and you need to be careful, and do some testing, to ensure that you can reach the major email providers. A website like Campaign Monitor
can help you if you are sending email.
I have a program that, for the most part, operates in the background. Let's say it DoesWork(). Once a week, I want it to notify the user on some of the work it has completed over the past few days. It will be a basic status report, listing some files that have been downloaded.
Initially, I wanted to sent this status update via email, so I looked into that but there are a lot of problems. I need an SMTP server so I looked at GMail. It's okay but has a daily limit of 500 emails, so this wouldn't be suitable for release. Also, there would be issues with the same email account password being given out in each copy of the program, which as I understand it, is a risk even if the password is stored using encryption.
Then I thought maybe I could use the user's own email account to send email to his/her self. This has a couple of complications too: the user would need to specify all of the smtp information for his/her email account, which is too complicated for the target user. Also, I don't want to have to have people entering their email account password into my program just to send emails. I don't think that's a good habit to promote.
Is there any way I could do this via email? Email was my first choice because it's a system of notification that users will already be checking. It's fairly non-intrusive.
Is it necessary to setup my own smtp server? If so, how can I do that?
If email is a no-go, I was also thinking about just generating a local HTML file with the relevent information, and then having a notification popup from the program once a week to inform the user that a new update report is ready. I think this is totally doable, it's just overly instrusive and not my first choice. I want to piggyback on a system that the user is already using.
Thanks!
-greg
An alternative is to have the program generate an RSS feed and direct the user how to subscribe to it. Also, once a new update is generated, show the update toast for about a minute, then hide it automatically and change your systray icon to something different. In about a day change it back to the original icon. Also, give the user a setting to turn the toast off permanently.
Relying on email is not a good idea, as you would have to collect the user emails and deal with the privacy issues for that, you would be effectively DOSing any third party SMTP server or would have to invest in the infrastructure for your own.
If I've understood it correctly, the user is running this program on his pc, in the background.
The perfect way to notify something would be, IMHO, giving the program is minimized to the traybar, a small popup that clicked, would open a window with a weekly report.
Hope this helps.
If you do get them to specify their own smtp server, make sure you put a "Send Test Email" button on there so they can test it. I know from experience that users always enter the wrong details when specifying a smtp server, user name, password, which is made worse since some smtp servers require a user name/password and others don't.
If they do enter the wrong details (or they change) then you might need to have some way to send them older reports, or to have some other way of notifying them that you can't send email.
Email's great, but you might need an alternative method also.
Google for simple smtp server windows gives you this
To be honest if you are just sending things once a week email is your best bet, as it's not frequent enough to garantee that the user will be at his machine to accept some other sort of request, which would require you to write proprietory software.
You could alternatively post it to an irc channel, or write an MSN bot to message the user, the message would be sent as an offline message if the user was offline.
I'd still go for email, it's tried and tested.
For a simple SMTP server I use hmail. I configure it to accept all SMTP requests from the local machine, regardless of source and destination, and to deny any SMTP requests not coming from teh localhost. This will be fine if you have a centrally located application.
If you want to distribute the app you have a whole different situation; with a lot of ISPs putting restrictions on SMTP traffic your best option would be to allow users to put in their mail account details and then use that to send mail. This will ensure everyone can put in working settings. Then use whatever library or pre-made code exists for yoru language of choice to send an email using those settings.
Does it need to be a weekly digest? Instead, how about using Growl (or equivalent) to notify the user of the tasks being completed in real-time, in the background?