Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 4 down vote favorite

Recently I receive a request: users' emails are stored in the database, and as request of a user, the system will send an email on their behalves.

To add more context, it's like sending an email from the vendor, to their customers' email addresses. But it's not a fixed email (it depends on which vendor ask the system).

Using JavaMail, I can simply set the from field. But something doesn't seem right. When searching for this kind of work, I come across "Email spoofing" - which looks like what I'm going to do. There are some drawbacks for this approach, such as it may make the emails attractive to the spam filters, and so on...

Ofcourse I can just do as the client want, but I just wonder, is there any better alternative?

share|improve this question

4 Answers

up vote 7 down vote accepted

So long as it's at the user's request, there's nothing questionable about doing this. It's just like your system is the email client. Sending emails from an address without the address owner's approval is a different story, of course.

share|improve this answer
what I consider here is that if the emails sent is filtered as spam, it's no good to the vendors. Of-course I need to do it if the client insists on, but I feel responsible to warn him about things that may happens. – Hoàng Long Mar 1 '12 at 4:28
I can't imagine that a spam filter will be able to tell whether the email is sent from your program, or from a "standard" mail client such as Microsoft Outlook. So there's nothing to worry about, in this regard. Naturally, there may be other reasons why a spam filter would filter out your emails. – David Wallace Mar 1 '12 at 4:32
7  
A corporate level spam filter will be able to tell whether or not it's spam by doing a reverse DNS lookup on the server that sent the email, vs. the domain in the email address. What it chooses to do at that point depends a lot on the filter itself. So it is possible for a spam filter to kill your spoofed email. – Jordan Mar 1 '12 at 6:16
2  
@HoàngLong: you could send the mail via the same server that the user usually sends its mail, but that might require you to store the users email password. Then it is a legitimate email and no spam filter will block it (unless it also blocks other legitimate mails from that user or it blocks for other content-related reasons, of course). – Joachim Sauer Mar 1 '12 at 10:14
1  
@Jordan: Spam filters do all kinds of things, but many will not do the check you describe. Instead, they check if forward and reverse DNS match (weaker check, still catches botnets but is RFC-compliant) – MSalters Mar 1 '12 at 14:31
show 4 more comments
up vote 5 down vote

From an ethics standpoint, I propose that the question can be boiled down to a simple test:

If the recipient of the email presented a copy of the email to your user, would the user be surprised at either the contents of the email or that an email had been sent on their behalf?

While you may be doing nothing wrong per se, if the answer to any part of the question is “yes, the user would be surprised,” you may be falling short of ethical behavior.

From an email deliverability standpoint, using a From address with a domain that you do not control, has implications on a number of standards that have the potential to prevent delivery of your email: DKIM, Sender ID, and SPF. I will address each separately.

SPF

The From address actually has no direct bearing on whether the SPF check passes or not. Most MTAs and framework APIs, however, use the From address to determine the SMTP Envelope Sender or “MAIL FROM” address. The Envelope Sender is what is actually used for the SPF check. Consequently, for SPF to pass, you need to override the Envelope Sender to contain your email address (at a domain you control and publish the correct SPF record for).

For example, sendmail(1) offers the “-f” option to override the Envelope Sender. Specific instructions for accomplishing this with different technologies is (I believe) beyond the scope of this site; you might try asking on Stack Overflow or Server Fault (depending on the exact approach used).

In addition, the Envelope Sender address is used by the receiving MTA to determine the Return-Path address. The Return-Path address is where any bounce messages are sent, which is another reason why it is important to override the Envelope Sender so that bounce messages go to you and not to your user.

Sender ID

There are two separate mechanisms offered by Sender ID: spf2.0/mfrom and spf2.0/pra. The former functions the same as the SPF check, and shares the same implications.

The latter does not look at the Envelope Sender, instead it looks at the Purported Responsible Address (PRA). For this to pass, all you have to do is specify a Sender address in the header that contains your email address (at a domain you control and publish the correct Sender ID record for).

Specifying a Sender address can also make it clearer to the recipient that the email was sent by you on behalf of the user (of course, it all depends on the mail client / MUA that the recipient uses).

DKIM / DKIM-ADSP / Domain Keys

There is nothing to stop you from attaching a perfectly valid DKIM or Domain Keys signature to the email, however, you would have to set the "d=" parameter to your domain—not the From address domain. It is unclear to me whether or not this is a good idea, since the standards leave it completely open as to whether the "d=" domain should or shouldn’t match the From address, the Sender address, the Envelope Sender, or anything else; and I do not have specific knowledge of how people are filtering in practice.

The DKIM-ADSP standard, on the other hand, makes it quite clear that the “d=” domain is to be compared solely to the domain of the From address(es). Domains that publish the ADSP policy, dkim=discardable, (e.g. paypal.com), will outright prevent you from sending on behalf of users on that domain, at least when the recipient mail server is configured to filter according to the ADSP policy.

Final Considerations

Many other email deliverability concerns, such as iprev/FCrDNS, HELO/EHLO checks, etc. are neutral to the From address, so the standard advice applies. If the new DMARC standard ever gains traction, it may pose issues just as severe as DKIM-ADSP does, due to the aligned identifiers requirement.

Other than the limitations I have specified, you will in theory have no problem altering the From address, so long as you follow all my advice above. In practice, of course, there will always be issues, because email is a little like the wild west where everyone is free to implement the standards according to their personal interpretations.

share|improve this answer
up vote 1 down vote

Outlook knows when I sent mail from GMail using a different address than that of my GMail account. It shows them as From on Behalf of . Outlook can only know this if GMail sends more headers than just the "From". And indeed it does. In the headers of an e-mail I sent in this manner, I can see:

Return-Path: GMail account
Sender: GMail account
From: Marjan Venema <other account>

Don't know JavaMail so can't tell you how, but you could do the same so that all mail sent by the system will show in Outlook (and probably in most other e-mail clients) as From X on behalf of Y.

share|improve this answer
1  
This is an Outlook feature though, not a general property of SMTP. – David Wallace Mar 1 '12 at 7:43
@Marjan & David: thanks for your information. It looks like JavaMail doesn't support "On behalf" header, but I think I can figure out a way to set it manually. The thing I care about here is the common practice in this kind of situation. Does other mai/web-mail client do the same as Outlook? – Hoàng Long Mar 1 '12 at 7:51
1  
@HoàngLong: I don't think it matters what the (web)mail clients are doing with the information, especially as you are concerned with ethics. Therefore I feel it matters more that the messages you sent reflect the actual situation: you are sending something on behalf of someone else. So if you can manually add the "Sender" header, I'd do so and leave it up to the (web)clients on the receiving end to decide what to do with the information. Spam filters that are aware of this header might also use it instead of the From header to do the reverse DNS lookup. – Marjan Venema Mar 1 '12 at 8:00
up vote 1 down vote

And here is something that may come in help:

From: "YOUR CLIENTS NAME" <clients@email.com>
Sender: yourcompany@yourcomapny.com
To: destination.com
Date: 13 Jul 2009 15:39:42 -0400
Subject: Whatever subject you need
Return-Path: yourcompany@yourcomapny.com

These fields are valid and will allow the receiving server to identify you as the server. On top of that bounnced-emails will go back to you.

share|improve this answer
Part of your answer is slightly misleading: the receiving server should ignore any Return-Path header you have added to the email. If it exists, it will just be overwritten with whatever “MAIL FROM” address you specify during the SMTP connection to the receiving server. – Michael Kropat Mar 3 '12 at 4:40
@Michael Kropat just tried it and in Gmail respects return-path and does not replace it with From. Care to explain a bit more so I may be able to reproduce your comment? – Frankie Mar 3 '12 at 15:49
1  
Well, I tested it just now sending to a Gmail address, and it looks like we’re both a bit right: pastebin.com/8HCzLZv0. Notice that two Return-Path addresses are present, the first one being the MAIL FROM address. RFC 5321 makes it clear that only one Return-Path should be present, which is why I maintain that manually adding a Return-Path address is problematic. – Michael Kropat Mar 3 '12 at 17:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.