Is it a problem if 127.0.0.1 appears in email headers?
Example: Received: from baobabsmail.baobab.fi ([127.0.0.1])
I ask because emails sent from my server to #outlook.com addresses end up in the spam folder and this is the last thing I can think of. I have properly configured HELO, DKIM, Reverse DNS, SenderID, SPF and DMARC. I don't send out mass emails. My IP is from AWS, but it isn't on any publicly available blacklists. I have verified that everything is set up correctly using DKIMvalidator, MxToolBox and mail-tester.
Edit: for what it's worth, I finally got rid of the 127.0.0.1's in my headers and it did not resolve the issue for me.
Unfortunately, it depends...
Mail systems vary in how they are configured, and it is perfectly legitimate for an MUA (e.g. Thunderbird) to send outgoing mail to an MTA / mail server (e.g. exim) running on the same machine using the localhost address. Unusual, these days, but not "bad by definition".
When you say 'end up in the spam folder', what is it that puts it there: are you using a local mail server? if so is it that server that junks the mail (on send) or outlook.com itself (on receipt). Either way, what error messages or other failure information have you found?
Some random thoughts:
DKIM is a pain to set up correctly. Try disabling it entirely and see if that changes things in interesting ways.
Ditto DMARC.
Have you got SPF set up separately? If so, disable SPF and retry.
Is IPv6 involved in the mix at all? Various things are subtly different if so.
If outlook.com were to do sender verify callbacks (i.e. on receipt, check that mail from address was an acceptable recipient to your server) would it pass?
Is your email system sending RFC-conformant mail: that is, does it have a From: address, To: or Sender: address, Message-ID:, Date: headers and, if using MIME, Content-* headers (and probably a couple I forget!).
If changing DKIM / DMARC / SPF changes things (and remembering DNS timeouts, leave it a while between attempts), re-add SPF first - it is the simplest to get right.
127.0.0.1 can be flagged by Spam filters because it fails to provide an identity trace of the sender. Most common e-mail systems will show the IP address or the host name. The next item will be the recipient e-mail server.
For example:
Received: from [127.0.0.1] (81.27.148.196) by TAE1.agent.com.pk
What is funny about this one is that the top-level domain says it is received initially by a domain in Pakistan, but the IP address is registered to an entity in St. Petersburg, Russia.
Related
I host a domain for a client; the domain's A records point to my IP address. When email arrives addressed to someone in his domain, he just wants to forward it to his ISP (charter.net). This works about 90-99% of the time, but a few times a day charter.net rejects the message with 'Service not available'. We tried forwarding to his gmail account instead, and same thing -- it usually works but sometimes gmail returns 'Service not available'. When this happens, my sendmail apparently gives up.
My suspicion is it is not the recipient's server uptime that is at issue; it rejects email that it sees as suspicious.
I have recently added SPF and DKIM records for my server's canonical name but I still get 'Service not available' from charter.net. Now sendmail DKIM-signs any mail that originates on my server, but it is not signing email that it forwards. I have not found a way to configure opendkim to do that. But I have seen that mandrillapp.com resigns email that it forwards; the headers include a DKIM-signature with d=originaldomain.com, and a 2nd DKIM-signature with d=mandrillapp.com.
So I guess my questions are,
1) Does anyone really know why my server gets 'Service not available' from ultimate recipient?
2) Can I configure opendkim to sign email that my server forwards?
3) Might it do any good to set up SPF and/or DKIM records for my client's domain?
Thanks,
Bob
ADDENDUM:
For forwarding, I have entries like this in /etc/mail/virtusertable:
a#clientdomain.com a#charter.net
For DKIM, I have this in my sendmail.mc:
INPUT_MAIL_FILTER(`opendkim', `S=inet:8891#127.0.0.1')
I also have clientdomain.com in /etc/mail/local-host-names, and as I said above clientdomain.com's A records resolve to the same IP as mydomain.com.
Classic sendmail redirects via aliases, ~/.forward file and virtusertable keep unchanged original envelope address (It is used in MAIL FROM command during SMTP session). It may make your forwards break restrictions set by SPF record of the original sender domain.
Possible fixes for "many addresses" redirect:
SRS
custom sendmail.cf fixes
For more details ask at more suited siter site serverfault.com.
I'm having trouble understanding why SPF breaks forwarding.
Say my mail is me#domain.com, and I'm send an email to joe#mit.edu.
Assume that Joe configured his mit.edu account to forward mail to his personal account, joe#gmail.com.
Now I would expect the SMTP conversion between my domain's MTA and mit.edu's MTA to look something like that:
220 mit.edu.ac.il
HELO domain.com
250 OK
MAIL FROM: <me#domain.com>
250 OK
RCPT TO: <joe#mit.edu>
...
I have 2 questions:
1) Now when the mail is forwarded, what will be the MAIL FROM value? I assume it'll be the same, and therefore will fail the SPF because ns.domain.com doesn't allow mit.edu to send emails using its domain.
2) If I'm correct in 1, why not just set MAIL FROM to be the forwarder's identity (is this case, mit.edu)?
Classic email forwarding standards (e.g. ~/.forwward) had been created well before spam era. They keep envelope sender (MAIL FROM:) unchanged => it may cross restrictions imposed via SPF record.
Some forwarding methods (e.g. procmail, ~/.procmailrc) allow to forward with new/changed MAIL FROM:.
SO you should be very specific about MTA/SMTP server doing forwarding.
Relaying is handled by SRS, but that's not the same thing as forwarding. What you're asking for is essentially forgery, so SPF doesn't like it. The solution is not to attempt to preserve the from address, because it's a forward, not a relay.
We are trying to figure out how to reduce the amount of bounces for our email platform and, one of the solutions we've found on the internet is to, via telnet, verify if the email exists.
So, for this example, we connect to the MX:
telnet alt4.aspmx.l.google.com 25
We start the communication:
helo hi
And, for every email we try (valid and invalid ones), we always receive the same response:
mail from: <fsafsaffsf#FasgagaoaSFasfas.co>
250 2.1.0 OK d8si998940wrc.143 - gsmtp
Are they doing this to prevent maybe a possible listing of valid emails?
What is the best way to verify if an email is valid before sending an email to it? We need this because our clients often uploads a spreadsheet with customer emails and always one or two of them are mistyped.
Thanks.
For a given recipient email address, you can:
extract its domain name (everything after #)
query DNS for the MX record(s) of that domain
for each specified server, connect and issue a VRFY command (see RFC 5321 Section 3.5), asking the server to verify the email address.
stop when you get a success reply.
However, SMTP servers are not required to implement VRFY. The simpler solution would be to just send the email normally, and then handle any errors from the RCPT TO command, and also handle the possibility that you simply can't always detect delivery errors in real time. If the email has to be relayed across servers, it might not fail on the server you use for sending, it may not fail until it is relayed to another server after you have already ended your SMTP session. In which case, the only way to detect delivery errors is to monitor your inbound mailbox for delivery failure emails being sent back to you.
I am creating own mail server. I am using Haraka (http://haraka.github.io/). But I am little confused about the relay thing. How to make relay my mail server so that I can send mail using other domain(DKIM and SPF verified).
I want mail in receiver inbox not in Spam. Right now mail is received in spam. What is relay in particular ? Can anyone help ?
What I've got is that you're having a problem with sending mail on behalf of "other domain".
Given that "other domain" mail reaches its destination (even in SPAM folder) I assume that you've configured your relay right.
Key thing to notice is that DKIM and SPF records not only need to be validated but also need to be aligned with your "other domain". It's a common scenario when SPF/DKIM validations 'pass' but overall DMARC policy 'fails'.
Providing both your message headers (to check how it was processed) and your other domain name (to check how SPF/DKIM/DMARC records configured) would help a lot.
When developing an application that sends out notification email messages, what are the best practices for
not getting flagged as a spammer by your hosting company. (Cover any of:)
best technique for not flooding a mail server
best mail server products, if you were to set up your own
sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
any other lessons learned
not getting flagged as spam by the receiver's client? (Cover any of:)
configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
best SMTP header techniques to avoid getting flagged as spam when sending emails for users (for example, using Sender and From headers together)
any other lessons learned
An additional requirement: this application would be sending a single message to a single recipient based upon an event. So, techniques for sending the same messages to multiple recipients will not apply.
best technique for not flooding a mail server
not a lot you can do about this beyond checking with your mail server admin (if it's a shared hosting account / not in your control). but if the requirement is one email to a single recipient per event, that shouldn't be too much of an issue. the things that tend to clog mail systems are emails with hundreds (or more) of recipients.
if you have events firing off all the time, perhaps consider consolidating them and having an email sent that summarizes them periodically.
sending messages as if from a specific user but still clearly from your application (to ensure complaints, etc come back to you) without breaking good email etiquette
you can accomplish this by using the "Reply-To" header, which will then have clients use that address instead of the From address when an email message is being composed.
you should also set the "Return-Path" header of any email, as email without this will often get filtered off.
ex.
From: me#me.com
Return-Path: me#me.com
Reply-To: auto#myapp.com
configuring and using sender-id, domain-keys, SPF, reverse-dns, etc to make sure your emails are properly identified
this is all highly dependent on how much ownership you have of your mail and DNS servers. spf/sender-id etc... are all DNS issues, so you would need to have access to DNS.
in your example this could present quite the problem. as you are setting mail to be from a specific user, that user would have to have SPF (for example) set in their DNS to allow your mail server as a valid sender. you can imagine how messy (if not outright impossible) this would get with a number of users with various domain names.
as for reverse DNS and the like, it really depends. most client ISP's, etc... will just check to see that reverse DNS is set. (ie, 1.2.3.4 resolves to host.here.domain.com, even if host.here.domain.com doesn't resolve back to 1.2.3.4). this is due to the amount of shared hosting out there (where mail servers will often report themselves as the client's domain name, and not the real mail server).
there are a few stringent networks that require matching reverse DNS, but this requires that you have control over the mail server if it doesn't match in the first place.
if you can be a bit more specific i may be able to provide a bit more advice, but generally, for people who need to send application mail, and don't have a pile of control over their environment, i'd suggest the following:
make sure to set a "Return-Path"
it's nice to add your app and abuse info as well in headers ie: "X-Mailer" and "X-Abuse-To" (these are custom headers, for informational purposes only really)
make sure reverse DNS is set for the IP address of your outgoing mail server
first a quick correction to the previous
return-path: is a header added by recieving system based on the envelope-sender of the incomming message
for spf to work the return-path/envelope-sender needs to be yourapp#yourdomain.com
and ensure the spf record for yourdomain.com {or if per-user spf} for yourapp#yourdomain.com allows mails to originate on the server that hosts the app/sends the email
this envelope-sender is the address that will recieve all bounces/errors
now sender-id is different entirely it checks the return-path/envelope-sender
and the
from: address {stored inside the message}
if sending
from: hisname yourapp#yourdomain.com
reply-to: hisname hisaddres#hisdomain.com
this will be a non-issue
if sending
from: hisname hisaddres#hisdomain.com
it will be and you must add a
Resent-From: hisname yourapp#yourdomain.com
as this specifies to ignore the from: for sender-id checks use this instead as it has been sent by you on his behalf
now for the other bits that are worthwhile
ip's mentioned are your mailservers
a have your ip's ptr point to a name that also resolves to the same ip
FQDNS
b have your server helo/ehlo with whatever.domain.com where domain.com is the same as the domain of the name in step A {not the same name for resons below}
c have that helo/ehlo servername also resolve to the ip of your server
d add the following spf record to that helo/ehlo name "v=spf1 a -all"
{meaning allow helo/ehlo with this name from ip's this name points to only}
e add the following sender-id lines to the helo/ehlo name {purely for completeness
"spf2.0/mfrom,pra -all" {ie there are no users#this-domain}
f add the following spf to the FQDNS-name and any other hostnames for your server
"v=spf1 -all" {ie no machines will ever helo/ehlo as this name and no users#this-domain}
{as the fqdns name can be determined by bots/infections its better to never allow this name to be used in helo/ehlo greetings directly it is enough that it be from the same domain as the helo/ehlo identity to prove the validity of both}