I am running a proxy antispam in my mailserver (ASSP 2.4).
If a remote spammer email is blocked, the antispam permits to configure a reply with a
554 5.7.1 Message blocked due to spam content in the message
or
by sending a "false" '250 OK' instead of SMTP error code '554 5.7.1'.
Two questions please ;
a) If I use the '250 OK' solution , am I breaking some some rule in the
Simple Mail Transfer Protocol (RFC 821 and RFC 5321) ?
b) Which is better and recommended and why ; "554 5.7.1" or "250 OK" ?
Thank you, Graziano
According to section 3.3 of RFC 5321 once you, the receiver, send a 250 OK to the sender it means the reciever has successful stored the message. Further according to section 4.2.4 of RFC 532 responding to <CRLF>.<CRLF> with a positive code (2yx) you accept responsibility for delivery of the message. You can also find that a response of 5yz to the DATA verb is accepted (with a 354) is appropriate when "[...]the server determines that the message should be rejected for policy or other reasons."
So to follow RFC you should likely issue a 5yz response if you determine a message to be spam. But no one polices this. If you configure your mail server to go against RFC you will still receive emails (especailly since you are waiting until the DATA phase to break the protocol, the sender cannot unsend the message).
However if you are willing to classify a message as spam you have then identified someone abusing the SMTP protocol so who cares what you do they are a dirty spammer? What if it is a false positive and the sender thinks you got their email when you in fact did not because you discarded it for being spam? Spam filters are often wrong.
No one is going to come to you and report you for not following SMTP protocol, this is because the RFC's are written to be interpreted. However you should configure your mail server to be some what friendly to a sender who is legitimate but is falsely identified as having sent you spam, so they can communicate the issue to you.
Related
i'm wondering: after we received a boss-scam mail that was showing the faked From in the webinterface, i read a bit about how SPF is checked, and apparently it is checked against the Return-path and not the From header. (This reddit was good summary https://www.reddit.com/r/sysadmin/comments/20rnt6/smtp_question_does_spf_only_validate_the/ )
Whats the benefit of this? As far as i can see, this renders the whole idea almost useless, as it doesnt prevent spammers from sending spam with faked From headers at all. What am i missing here?
(This is just because i'm wondering, i'am aware that DKIM + DMARC will solve this spam problem :) )
SPF validates the envelope sender (AKA SMTP MAIL FROM, Return-Path,Bounce Address henceforth sender). it's purpose is to deny the use of forged senders, by disallowing the sender to be used from unauthorized servers. stopping the generation of mail with forged senders (where SPF is supported)
BATV, (and other types of VERP) can be used to reject backscatter from those systems that do not check SPF and reject forged senders.
SRS (another type of VERP) is required if you do a mailing list - you can't retain the original sender because the list server will (most likely) not be included in the originators SPF
DKIM is the one that deals with email headers. it allows you to cryptographically sign selected email headers and full or partial content (but don't do partial signatures on MIME Multipart-Alternative messages - that will end badly)
Don't try to make SPF responsible for something it's not. SPF simply lists which servers can send mail for your domain. It checks the envelope sender (MAIL FROM) at the SMTP level, which is the value that ends up in the return-path header, but only after it's passed SPF checks. What you're saying is that (assuming you have a strict SPF policy) you're allowing someone to send fake mail from one of your own mail servers, which is a problem much further up the chain than the From header, and one that would not be solved by DKIM. Perhaps your SPF record is not strict enough? We can't tell from the information you posted.
In the context of writing an MSA (of sorts) for our application I'm currently writing some code to test if it is possible to connect to a given address to send mail, including if authentication is required.
To test for the latter I pretend to be sending an email from the (fictional) address with the same address used for the recipient.
I use this approach, although I'd rather not have to, since I need to be able to send both a MAIL verb and an RCPT verb to the server. The reason for this is, as far as I can tell, no verb prior to sending MAIL (i.e. EHLO, STARTTLS, AUTH etc.) will elicit an error if authentication is missing. Some servers, such as Gmail, respond with an error on sending an unauthorized MAIL, but others only react once I try to add a recipient, hence the need for both verbs.
The reason I use an IP address instead of a domain name in the fictional mail is that I do not necessarily have access to a domain name at that point. I know it isn't pretty, but it is legal. Provided the IP address is specified according to RFC 5321.
The funny thing is that Gmail will accept the MAIL verb using the fictional mail address, but will throw a 553 error when the same address is used for the recipient complaining it isn't a valid RFC 5321 address.
SEND: "MAIL FROM:<test#[IPv6:fe80::105e:c040:c56c:b8bc]>"
RECV: "250 2.1.0 OK s82sm4688131lja.26 - gsmtp"
SEND: "RCPT TO:<test#[IPv6:fe80::105e:c040:c56c:b8bc]>"
RECV: "553-5.1.2 The recipient address <test#[ipv6:fe80::105e:c040:c56c:b8bc]> is not a"
"553 5.1.2 valid RFC-5321 address. s82sm4688131lja.26 - gsmtp"
I should note that I've tried this both with and without the IPv6 prefix. Without it, another SMTP server running on Postfix complains. The Postfix-based server is coincidentally one of those not throwing an error when sending the MAIL verb unauthenticated.
This issue with Gmail isn't limited to IPv6 addresses, by the way. Switching to an IPv4 address produces the same result. Neither does the issue seem to be linked to local addresses. The MAIL verb is accepted, the RCPT verb fails.
As far as I can tell what I provide is a proper RFC 5321 compliant address. What's going on? Where do I go wrong? At first glance the problem seems to be with GMail/GSMTP.
Well, yes, it is a "problem" with Gmail/SMTP in a loose sense of the word; a "problem" in the sense that they refuse to accept email addressed to an address-literal, as specified in RFC 5321.
Even though RFC 5321 allows an address literal in the RCPT TO, Gmail obviously chose not to support it, for whatever reasons they used. I'm confident that Gmail is not the only mail provider in the world that, for one reason or another, does not support some arcane part of the SMTP protocol.
And that's pretty much it. The answer here is, pretty much, "it is what it is". The command you're sending is compliant with RFC 5321. Gmail rejects it. The End.
If you want to be pedantic about this, section 3.3 of RFC 5321 also states:
Similarly, servers MAY decline to accept mail that is destined for
other hosts or systems.
So, pedantically, Gmail's mail servers are not technically required to accept mail for anyone else other than Gmail. So that's that.
Your options are:
Don't use address literals.
Use another mail server provider that supports destination addresses specified as address literals.
My application uses Simple E-mail Service from AWS + GoogleMail for sending mails to clients.
But I have a lot of complaints about mail never received, even after more than 24 hours.
In the logs, I see:
250 2.0.0 Ok: queued as XXXXXXX
reportingMTA: a9-82.smtp-out.amazonses.com
Can anyone tell me:
Is e-mail queued on Amazon OR on recipient server?
Where can I find rules to help me avoid that?
This means Amazon 'did their job' by delivering the message and having it accepted.
What implies that you shouldn't want to avoid this to happen.
The problem is, as Amazon says:
Amazon SES successfully delivers the email to the recipient's mail
server. This notification does not indicate that the actual recipient
received the email because Amazon SES cannot control what happens to
an email after the receiving mail server accepts it. Delivery
notifications are available only through Amazon SNS.
I was in the very situation you are, I had some complaints about never receiving the message. What I realized after a lot of analysis:
There was in fact emails that after being said as delivered, later on came back as 'marked as spam' messages -> I asked them to whitelist my domain
I myself had a flaw in my verification of whether to send email to a client or not ( I was blacklisting all recipients in a batch if any of them sent back a "Permanent Bounce" response)
There was even cases of people saying that didn't receive (because they heard that some other people weren't actually receiving) and investigating further I found out they had in fact received but were just too lazy to take a look to give me correct information (!)
I found many types of "Successfully delivered notifications" (such as "250 2.0.0 Ok: queued as XXXXXXX", "250 ok: Message XXXXXXX accepted", "250 2.6.0 Queued mail for delivery", etc) and I thought there could be a problem related to this "queued" responses, but in the end I found none.
My advice is that you investigate further other possible reasons just like I did.
In HTTP, you can tell the client who asks for example.com/foo/ that it should ask for something.else/instead.
Is there a way to do it in SMTP? That is, if the client sends a message to john#example.com, tell it to send it to jane#somewhere.else instead.
I know that I can receive the message and relay it to jane#somewhere.else. For many reasons I don't want to relay messages via my server. Instead, I want to tell the client that it should send it to another address.
The reasons include:
I cannot notify the client of a failure (well, perhaps this can be done).
My server will be blacklisted if the message was spam.
The destination server will consult blacklists with my IP and not with the original sender's IP, etc.
My motivation is:
If this were possible, perhaps it would be a better antispam measure than greylisting.
My institutional server has no antispam filters, while my personal server uses IP-based blacklists such as Spamcop. After the institutional server has received a message, I can scan the message at the client but it's too late to consult Spamcomp and to inform the sender that the message was filtered out (I consider it a must in any filtering). I wish the institutional server could simply redirect people to my personal server, which is a lot better protected and correctly informs the sender of the problem at the SMTP stage.
Sendmail provides FEATURE(redirect) to handle such cases.
It rejects recipient in reply to RCPT TO: with
551 5.1.1 User has moved; please try <newemail#example.com>
Your email server refuses to accept the recipient with hint, it is up to sending host to generate bounce message to the sender. Spammers may/will get the new email too. I do not know any email servers handling automatically such redirects.
I have not investigated how well it is handled by various email clients and level of details provided in bounce message by various email servers.
received an email from a spammer addressed to a non-existent user in my domain, let's call it example.com. obviously the headers had been spoofed but i must assume the 'rcpt to' field was legit for it to reach me. i have all messages forwarded to my gmail from my domain's sendmail.
trouble is nothing in the message source in gmail is showing which of my the legit email addresses the spammer specified to reach me. all i see in the message source is the bogus email. i can't reproduce this either. this is the first 'received from' part:
> Received: from SQSZJWGPY ([1.52.114.198])
> by example.com (8.14.4/8.14.4) with ESMTP id s5PEIUCI003583;
> Wed, 25 Jun 2014 10:18:31 -0400
in all other emails the last line looks something like this:
for me#example.com; Wed, 25 Jun 2014 10:32:11 -0400
so the legit email is revealed. i know the envelope is not included in the message source but there must be a way to find out what the 'rcpt to' value was without going into sendmail logging and what not. how did the spammer hide the email he specified?
The contents of an email message, specifically, the to, cc and from headers, don't necessarily correspond to the envelope mail from and rcpt to of the message. The SMTP protocol, specified in RFC 5321, is where the envelope data is sent.
The message contents, specified in RFC 5322, contain the message headers and message body. The headers are where you find the to, cc and from headers that we usually use to identify out who sent the message and who else received the message.
However, there is nothing requiring that the from, to and cc headers match to the envelope mail from or rcpt to, though well behaved mail software will often have the association made clear. I say "often" because, for example, when you blind carbon copy (BCC) somebody on your message, your mail client will not include these recipients in the to or cc headers.
In your case, the rcpt to specified to sendmail is not put into a header by default, so is probably lost. If you really don't want to look into the sendmail logs you are probably out of luck for this one message.
If you expect you will continue to receive similar messages you could instruct sendmail to add the envelope rcpt to into a header. Then, without looking at the sendmail logs, you will have the rcpt to in a X-Envelope-To header.
The spammer probably has a SMTP server where he has a email account configured as administrator, then he probably can send emails from different senders. The SMTP server probably doesn't have some filters to control the output and input emails, then if you are an administrator of this server, you can send emails from sender like "example#yahoo.com" even if your domain name isn't yahoo.com. Once, some partners and I did a test in a company (customer) to demonstrate that their SMTP server can be victim from a phishing attack, we could send emails from different senders with different domain name.
I hope this information to help you.
Good luck.
after much testing and trial and error i have found the answer to my own question. bear in mind that i use sendmail 8.14.4 (5 years old) and i haven't done much tweaking to the sendmail.mc file.
if during the smtp session the sender specifies a non-existent account in the 'rcpt to' line followed by a valid one, the recipient's address is masked in the headers. e.g.
mail from: spammer#example.com
250 2.1.0 spammer#example.com... Sender ok
rcpt to: bad
550 5.1.1 bad... User unknown
rcpt to: good
250 2.1.5 good... Recipient ok
data
354 Enter mail, end with "." on a line by itself
looks good?
.
250 2.0.0 s5UHeBOj004847 Message accepted for delivery
the message arrives to user 'good' and nowhere in the header (or elsewhere in the message) it is indicated that it was sent to 'good'.
maybe spammers are doing this accidentally or deliberately, but they are doing it and this can be reproduced every time using above method, at least with my sendmail version.
that's all