Re: global recipient verification from a host or network?
mouss
> How do I have the mail server check on delivery for all mail from a host
> before returning a status code? What is the overhead on this?
>
> I have an application using the javax mailer. I would like to be able to
> interact with the status of a mail. The call is asynchronous as it is
> brought about by an http request and has a requirement of a short life
> span. Using the listener in the mailer I am able to receive the response
> code but they are all 250 as my postfix server accepts them for
> delivery. Is it reasonable to do address verification globally for the
> connections from this machine so I can at least immediately catch 550
> results and return them to the application for processing or is this a
> job for a MLM, if so any advice on which ones are good? Apache James has
> my interest the most right now.
>
The problem is that you will be opening useless connections to servers.
people at the other end may not like this. I personally don't like
probes (connection without message), because there is no way to
distinguish these from attacks (dictionary attacks, ... etc).
Mail delivery is asynchronous. don't try to fight against this. the
simplest method is to use a specific envelope sender that will get the
bounces. deliver these via a program that does whatever your application
needs. it could for example mark the original recipient as "bounced" in
a database. After N bounces, the address is blocked. N will vary
depending on the "state" of the address and the business area (maybe
also on recipient preferences). For a mail to confirm subscription, N=1
(because the address may be forged). For an address that was validated
and successfully used before, care must be taken into account for
"transient" problems at remote sites (transient is not to be understood
in the smtp sense here).
Using an MLM will simplify this process as well as bringing other
benefits. if multiple applicatioons do similar things, an MLM is a good
investment.
mouss
> This is all exactly within my thinking. I wanted to make sure there was no "easy" solution before working on implementing a mailing application with access to my application's database.
>
> There are a lot of issues in providing mailing from an application while observing good ettiuite and avoiding "spamming" can you reccomend any good models and any further reading? These are problems I come up against freuently working for startup webapps and I do my best to or within them. I would love to confirm I am on the right side of things and possibly learn some improvements.
you will certainly need to fill in forms at big players. for hotmail,
you should create an SPF record (it is worth creating a reserved domain
to send mail from, so that you have a strict SPF record). at leats, take
a look at their "conditions" as they contain good recommendations.
Here are some points that I found important:
- people must be able to unsusbcribe their addresses as easily as
possible, and as quickly as possible. you can verify that this is not
forged, but legitimate users can't be asked to "try later" or to do
complex things. an error on the unsubscribe web page indicates that it
is a fake one unless you provide other simple methods. providing both
web and mail based methods is a good thing.
- make sure you don't get abused by robots. see if you need CAPTCHAs or
whatever. the solution depends on your target audience.
- require confirmation when subscribing a user. even if the address of
your brother! keep the confirmation mail as evidence in case of a
complaint. Also, people do mistype addresses. so as long as an adress
was not confirmed, don't send too much email (in general, one message is
enough, but if your business requires it, a reminder may be sent after
few days. but not more). Make sure the confirmation message cannot be
confused with a marketing campaign (few or no marketing inside). Plain
text is appreciated (keep html and fancy stuff for future mail, if the
user wants that).
- the above applies to all addresses to which you will send mail. For
example, in case of a merger, you should ask the subscribers to confirm
that they want to stay in (you can find ways to do this "smoothly". you
won't lose customers. Being honest and rigourous will help you keep
customers).
- understand that people sometimes quit their company. many times, their
mail is redirected to someone else's mailbox. this someone else has no
idea what password was used to subscribe at your site (nor does he know
that the address was really subscribed. they may report you as a
spammer... in which case, the evidence that you kept can help). anyway,
when thinking about the "unsubscribe process", keep this in mind.
- remove undeliverable addresses. I have found that implementing a
recipient BL on the MTA is effective, in case marketing/business/...
don't cleanup their lists. I've done this because I still see mail
coming from "honest" organizations to old addresses (and I told them and
I told them, and they fix it, and then it starts again... probably a
borked application. which gave me the idea of implementing the BL on the
MTA, so that even if a borked application gets crazy, the problems is
local and doesn't disturb external people).
- and of course, don't use anybody else's list. This may be hard for new
businesses, but business is not supposed to be easy. use your
imagination and creativity to find ways to attract your target audience.
mouss
>
> Always. Also along with SPF its best to make sure your RDNS is correct as many people overlook that.
>
> Though to my knowledge gmail does not offer any whitelisting and hotmail/msn uses a pay service that requires a volume of mail out of the scope of alpha and beta stages of many companies. Yahoo AOL and earthlink are pretty easy to work with as long as you are compliant. AOL offers their feedback loops which are helpful in maintaining a good status.
>
well, if it was easy to get whitelisted, you understand that they will
soon be inundated...
> [snip]
> Any thoughts on allowing a user to remove their address form a suppression list? I like to use confirmation key sent to the address but always wonder if this might be considered by some to be violating their wish to unsubscribe. Its kind of hard when there is no list persay.
>
what's a suppression list?
I see no problem verifiying that the user who wants to get removed is he
who claims. but propose a human contact for people who don't understand
what it's all about.
> I always try and keep these as plain as possible but insist on a standardized footer on all site mailings that includes the unsub link. Which makes them html. Making sure the correct Mime-types are set is good for spam filtering.
there is no need for html. most "basic users" use MUAs that will make
URLs clickable even in plain text.
>
> This is exactly why I am looking to track the response codes on the mails. After reaching a threshold supported by business needs accounts returning perpetual 400 errors or 550s can be marked as invalid and cut down on clogging up my and others mail servers. That and so I can display to our users the status of messages used to introduce their peers to our application. Typos are of course the most common problem and should be easy to remedy if the user knows.
>
> How would you implement this tracking and blocking within the mail system? If I could do this without the need to integrate into my application and wait on the developers to have time, as well as the security implications of having a mailing server with database access, I would be ecstatic.
>
by periodically parsing logs and adding addresses to a map called with
check_recipient_access (if sendmail is used, then transport_maps should
be used instead).
>> - and of course, don't use anybody else's list. This may be hard for
>> new
>> businesses, but business is not supposed to be easy. use your
>> imagination and creativity to find ways to attract your target
>> audience.
>
> Any advice on dealing with the need to allow users to send an invitation through our site to an account we have no relationship with?
Ask the user to provide the first and last name and use these in the To
field. This helps a bit because many filters will "be happy" if the
first and last name match the user address (unlike random first/last
names found in spam).
Use a reserved display and address for the From header. Don't forgte
that MUAs "collect" addresses and will use them for address completion.
An alternative is to use the "member" address in the From header, but
this may be risky (LinkedIn do that, but they are whitelisted in many
places).
consider providing a mailto button for those who can use their mailer
(won't work for webmailers). Chances are they are whitelisted at the
recipient site.
PS. Be ready to get your share of Challenge/Response scatter...
>
> Our registered and confirmed users are the ones initiating the mail but it of course is sourced with us. (This has been a personal issue for me at many of my jobs as it borders on spamming. But thats part of "Social Networking") I ensure that the from headers and reply-to are always clear and do not impersonate the email address of my registered users as many sites seem to do. All mail coming out of my mail server is from my mail domain and is used solely for my applications.
>
I don't think it's at the border of spam. Fighting spam doesn't mean
eliminating email.
Anyway, let's stop here to avoid annoying other members. if you need
more infos, contact me offlist.