I know there is a great function of Postfix which allows us to forward emails, so, for example, I have a Postfix service running at mydomain.com and I can send important notifications via email to my clients directly from info#mydomain.com. Also, thanks to forwarding functionality, I can RECEIVE letters back to info#mydomain.com and automatically get them forwarded to my full-featured "real" mailbox, for example, my#gmail.com.
It looks great, but there are two things that still need to be solved.
If I limit SMTP listener to 127.0.0.1:smtp, I still can send letters from the code, BUT I can not receive answers anymore. Not sure why. So I have to remove the limitation (but this will allow bad guys to use my Postfix as a spamming route point). Is there any possibility to allow email receive and still leaving SMTP limited to the localhost?
Postfix's forwarding does not work in the real life. Actually, the forwarded letters look like sent from the stranger's email (stranger#strangehost.com for example) and any "real" mail provider recognizes them as spam, because the SPF record in my domain says "allow to send only from mydomain.com" and stranger's emails does not pass this check.
So my big question is: Is it a way to implement a "redirection" of emails (not forwarding) so sender email will become "info#mydomain.com" and gmail.com (or other "real" mailbox) will not kick them?
Related
I am going through my first steps on VPS management and configuration; been able to install PHP, mySql, phpMyAdmin, postfix, etc ... and migrate a Wordpress from an existing shared server to this VPS.
Sorry for my question being naive, but when testing postfix with the php mail function, I purposely sent the email with a "From" header which was not my own email address (don't worry, nothing serious).
Question is: the email was sent and received in my inbox as if it was sent by somebody else! Is it this easy to send a fake email with php and postfix? (of course, checking email headers reveals the truth).
How can I restrict my VPS from being able to send emails from arbitrary addresses?
Thank you.
The answer is "yes and now": it is easy to "fake" emails, though that actually is not faking at all. Please understand that the "From" and "To" addresses shown inside an email message are part of the messages content. From a technical point of view these addresses have nothing to do with from whom (from which account) that messages has been sent or to whom it is addressed. Those addresses (accounts) are specified on a completely different level.
In addition it is not up to the sending software to decide what is a valid message and what not, in terms of a message being genuine. That obviously would not make sense if you think about it. That is something that either the receiving side or the transmitting side have to make sure, here the email servers, especially the smtp servers accepting and routing messages.
And indeed this is the case: it is a question of your local smtp servers configuration if such a message is accepted for delivery or not. Most likely the message in your test case has been accepted because it originated from within your local network, or what the smtp server considers as your local network. For such messages typically other rules exist compared to routes received "from the outside" and this does make sense.
Further it is a well known fact that it is part of the responsibility of the smtp server administrators to make sure that their servers cannot be missused. The rules used for this are called "relaying rules", all current smtp server implementations offer configuration opions dealing with that issue.
In general you can say that
really "faking" an email is not that easy if you look at the details. If a receiver only looks at superficial details then indeed he can easily be fooled.
email is not at all a secure means of communication, it never has been and it never was meant to be. It is built on trust in general.
the only secure way to make sure that an email has indeed been sent by the party that is claimed as sender inside the message is by using "signed messages", by using a digital signature.
This has been a massive headache. We use Ning as a our platform for an arts event project. We want to ask our audience to upload photos to our website via an email address. The only issue is that Ning only will give us ridiculous email addresses for this purpose... such as photos34628234896#ourwebsite.com That hardly sticks in the mind!
So I thought, lets just forward emails from an easy to remember email address to the Ning's crazy one... BUT Ning doesn't allow any emails to upload photos if they are detected as being forwarded or redirected. I guess that detection is done through the email header.
So that is why I need a way to redirect an email to another address without that being reflected in the header info in the email. I thought perhaps Outlook receiving the emails from the easy to remember email address, then somehow resending them with a fresh clean header may be the answer? I can code in PHP, and run a home headerless ubuntu server on a domestic internet connection too if that may provide a better answer?
Any thoughts how I could achieve this goal?
If you can forward the email to your server you can have it piped to PHP which can then resend the email for you with whatever email address you wish to be displayed. Just make sure you have things like DomainKeys and SPF records set up for that server or else your chances of the mail being seen as spam will increase.
If you are using an Exchange server, you can use Transport rules to redirect the message, which will pass most forwarding checks. If it does indeed change the headers or something else, you can use the same ruleset to remove or modify them. Most MTAs(Mail Transport) will allow the same sort of functions, but it really depends on which one you use. Postfix is quite flexible.
The changes will be made in
Exchange Management Console
Origanization Configuration
Hub Transport
Transport Rules
Also, and maybe easier, you could simply try to add a secondary delivery address, in the mail flow settings for the fictional user you assign to receive the emails. This would be done in the user properties. Server level forwarding amy not trigger the forwarding blocks that you are encountering, as client forwarding does not work the in entirely the same way. Many clients send the email again, but the server redirects it.
Exchange Management Console
Recipient Configuration
Mailbox
Properties, Mail Flow Settings.
You would enable forwarding in Delivery Options.
Sorry, just noticed that you are using ubuntu, you can simply have postfix redirect the email for you, you will use Postfix Virtual Alias Maps...
Here is a link that describes it perfectly...
http://www.cyberciti.biz/faq/linux-unix-bsd-postfix-forward-email-to-another-account/
I'm using PHP mailer to as part of an enquiry form that I'm building for a client. One thing I've noticed in testing is that when I use my yahoo account as the FROM and my gmail as the to it works fine for a while but then it starts rejecting, I'm assuming because gmail is smart enough to know that the email isn't actually coming from Yahoo.
What is the best solution to this? I could use the email from the person who has actually filled in the form to show as the FROM address but I'm worried that this may eventually cause the same problem anyway? I could also send it from an email on the domain that its sending from but will that stop it from appearing as spam or black listing that email?
Any help or guidance would be great?
You are getting tagged as a spammer because you are sending the same message over and over. Set up your own mail server without a spam filter while developing if this is a problem.
You are not Yahoo -- don't pretend to be them! Set the From field to an address at the domain that's sending the mail (e.g, if your domain was example.com, send from something like inquiries#example.com or noreply#example.com).
This is probably related to SPF records. mail() will most likely try and send the mail directly to the server(s) identified by the MX record of the recipient domain, and because you are not sending from an IP address that is recognised as one of Yahoo's, Google will reject the email. If you are on *nix, you may be able to configure your system's sendmail program to relay via Yahoo. This is not an option on Windows (I don't think) because Windows has no sendmail and PHP will send the mail itself.
If you want a cross-platform solution you can use something like PEAR::Mail to relay the message through Yahoo's SMTP servers - this should resolve the problem as long as the SPF record is the source of the problem.
If your email is getting flagged as spam because of the content of the message, the only solution is to change the content of the message.
I'm working on a website that allows you to send emails without registering, and without specifying a sender. You enter the recipient's address, subject, body and send. My problem is sending the message. What I'm trying to achieve:
User clicked send -> Subject,recipient,body sent to PHP -> Server validates the information -> Server creates a random email account -> Server sends the email through the random account created -> Server deletes the account
I'm stuck at the random email account creation step. How do I achieve this with PHP without having to pay for my own SMTP server and without having to use my own gmail/hotmail account.
I googl'd the hell out of this issue and I can't find an answer.
Thanks!
BTW
I'm using Apache to "host" on my own Ubuntu
How do I achieve this with PHP without having to pay for my own SMTP server and without having to use my own gmail/hotmail account.
The way to create E-Mail accounts varies wildly from server software to server software, and is usually not possible from within PHP.
Depending on your server's configuration, though, that might not be necessary: If you set up a catch all address for a domain, many server configurations will allow you to send out mails from any E-Mail on that domain (e.g. 123456789#example.com). Any responses will then go to that catch-all mailbox, the contents of which you will probably want to discard.
You have to realize, though, that this is exactly how spam providers operate. Extreme caution is advised if you don't want to end up on all sorts of spam blacklists.
I don't believe you can create accounts or email accounts on a server, using PHP, as this supersedes PHP's permission level. Sending emails this way is a good way to get your server banned, FYI. Also, if you insist on sending emails like this, why not just specify a dummy From: email address? It would essentially be the same thing as creating a dummy account anyhow.
You may also want to use the -f switch, for PHP's mail(). See php.net/manual/en/function.mail.php
I have set up an AJAX contact form on a client's website.
The problem is that the email is not getting through to the client's inbox.
I set up the client with Google Apps (in the same way I did for myself).
I used the same contact form with my email address and it works. But with any email addresses on their domain it doesn't!
All members of the domain are receiving 'ordinary' emails.
What could be the difference that's stopping mail() emails getting through?
UPDATE
Ok so I managed to solve it. Turns out that using a CNAME to point the domain to the correct server wasn't enough for sendmail so I had to change it to an A record pointing directly to the server. Strange but true. Thanks for the help folks, you pointed me in the right direction :)
It depends on the both settings on your server and the server on the receiving end.
hotmail for example requires the use of correctly configured SPF records.
many mail-receiving servers (including hotmail) require the email to originate from a Fully Qualified Domain Name. It is very possible that your e-mails send from PHP do not comply with this rule. (there is a good chance they originate from 'apache')
see hotmail self help and hotmail postmaster info
PHP's mail() function does not include a lot of headers with your mail, so you will need to supply them yourself.
The more hops your mail makes on it's way to it destination, the more likely it is to be tagged as spam.
So it might be a better option not to use PHP's mail function and instead use a mail library that connects to an SMTP server just like your desktop mail application does.
All in all, I would place my bets on an external library: Pear::Mail (documentation)
You could also read: how do you make sure email you send programmatically is not automatically marked as spam
UPDATE
Failing the SenderId or SPF check can get your message dropped before it even hits the users inbox. The message will not end up in the users junk folder, it will go directly to /dev/null.
I know this is at least true for hotmail and live mail. I see no reason for other hosts not to have implemented the same policy.
I recommend using PHPMailer (including their SMTP) library instead. It is reliable compared to mail and allows you to create fully customized emails.
http://phpmailer.worxware.com/