Ironport rejecting emails [closed] - networking

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Improve this question
I am looking for an answer from somebody who has experience with ironport. When an email is rejected by ironport (due to low reputation or whatever) does it write it someplace in a log? If so where.
I am on the sender's side. Unfortunately I don't have access to the smtp logs of my server to see what errors ironport throws back. Is there a way to capture those in some other way?
Is there a way to whitelist a sender domain in ironport? If so how (link to a documentation would be enough).
Thank you!

IronPort utilizes 4 Host Access groups which decide what policy will be applied to a sender based on their reputation on SBRS.
WHITELIST:
$TRUSTED (My trusted senders have no anti-spam scanning or rate limiting)
BLACKLIST:
sbrs[-10.0:-3.0]
$BLOCKED (Spammers are rejected)
SUSPECTLIST:
sbrs[-3.0:-1.0]
$THROTTLED (Suspicious senders are throttled)
UNKNOWNLIST:
sbrs[-1.0:10.0]
sbrs[none]
$ACCEPTED (Reviewed but undecided, continue normal acceptance)
ALL
$ACCEPTED (Everyone else)
When the initial SMTP connection is established there will be a new log event written depending on the HAT match
ICID 936657752 ACCEPT SG UNKNOWNLIST match sbrs[-1.0:10.0] SBRS 4.8
ICID 936594871 ACCEPT SG SUSPECTLIST match sbrs[-3.0:-1.0] SBRS -1.4
ICID 936620321 REJECT SG BLACKLIST match sbrs[-10.0:-3.0] SBRS -10.0
Looking at the log verbosely
Thu Nov 27 11:32:36 2014 Info: New SMTP ICID 936620321 interface address x.x.x.x reverse dns host unknown verified no
Thu Nov 27 11:32:36 2014 Info: ICID 936620321 REJECT SG BLACKLIST match sbrs[-10.0:-3.0] SBRS -10.0
Thu Nov 27 11:32:36 2014 Info: ICID 936620321 close
ICID: Incoming Connection ID
MID: Message ID
DCID: Delivery ID
On a rejection only an ICID will be created as the message will never enter the queue due to the SBRS rejection
To view these logs you can either SSH or telnet into your appliance and tail/grep the mail log based on the log name - to verify your log name you can view this under 'logconfig' The log labelled IronPort Text Mail Logs will be what you are looking for. You can also alternatively forward this to a syslog host - option is available under logconfig
Whitelisting can be completed 3 ways
Whitelisting the IP in the HAT table as per above
Whitelisting via a content filter and applying this to your relevant policy
Creating a policy with a content filter set to skip processing and just deliver - domains you would like to include in this policy can just be added as either a sender or recipient
Documentation for Cisco IronPort is available at http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa7-6/ESA_7-6_Configuration_Guide.pdf - version dependent

Related

FIN-ACK packet is sent from the server, but client sends HTTP request before client sends FIN-ACK packet [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
As expected behavior, when server sends FIN-ACK packet, client should also send FIN-ACK packet and the connection is terminated. But for some of my cases, when server sends FIN-ACK packet, immediately new http request is going from the client, before FIN-ACK is sent back from client. This is causing connection reset packet. What is the reason behind this and how to solve this issue.
... when server sends FIN-ACK packet, client should also send FIN-ACK packet ...
While common this is not actually required. FIN from a server signals only that the server will not send any more data - but it still might receive data. Similar a FIN from the client signals that the client will not send any more data - but it might also still receive data. Only when both sides have send a FIN and got the matching ACK, then it is clear that no more data will be send in both direction and thus the connection is closed.
... when server sends FIN-ACK packet, immediately new request is going from the client, before FIN-ACK is sent back from client.
There is no "request" at the TCP level. Request and response have only a meaning at the application level for some application protocols. It is unclear what application protocol is spoken here.
What is the reason behind this and how to solve this issue.
As said above, FIN from the server only means that the server will not send any more data. But it might still receive data. Nothing here forbids the client to send more data. There is no issue to solve here.

Rate Limiting an API based on public IP addresses [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I was studying the Github API and came across the following in their Rate Limiting section
For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the user making requests.
I was curious to see what HTTP headers are used to track the limits and what happens when they are exceeded, so I wrote a bit of Bash to quickly exceed the 60 requests/hour limit:
for i in `seq 1 200`;
do
curl https://api.github.com/users/diegomacario/repos
done
Pretty quickly I got the following response:
{
"message": "API rate limit exceeded for 104.222.122.245. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
"documentation_url": "https://developer.github.com/v3/#rate-limiting"
}
It seems like Github is counting the number of requests from the public IP mentioned in the response to determine when to throttle a client. From what I understand about LANs, there are many devices that share this public IP. Is every device in the LAN behind this IP rate limited because I exceeded the limit?. On a side note, what other ways exist of rate-limiting non-authenticated endpoints?

why not just ping? why ping/pong for websockets? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
TCP can detect whether a packet was sent successfully anyways so instead of waiting for the pong, why not just check if there's an error when the ping is sent? I just don't find the need for pong.
Having ping and pong creates an end-to-end test for both connectivity and a functional endpoint at the other end.
Using just TCP, only confirms that the TCP stack says the packet was delivered to the next stop in a potential connectivity chain and does not confirm that the other endpoint is actually functioning (only that the packet was delivered to the TCP stack).
This is particularly important when there are proxies or other intermediaries in the networking chain between endpoints which is very often the case in professionally hosted environments. Only a ping and pong confirms that the entire end-to-end chain, including both client and server are fully functioning.
Here's a related answer: WebSockets ping/pong, why not TCP keepalive?

Why does Unix command `ping` fail yet I can access the URL via all internet browsers? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
Currently I am accessing the Internet in a public library. Before using this access, one must accept the terms of use. After accepting these terms, my browser accesses any URL, e.g. cnn.com
In Unix, I enter the command ping URL, e.g. ping cnn.com, this command fails.
$ ping cnn.com
PING cnn.com (157.166.226.26): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
After ending this with Control + C, the output is
7 packets transmitted, 0 packets received, 100.0% packet loss
Why exactly is ping not working in this case? How can I use this command successfully?
It's a matter of network protocol. Ping uses ICMP and your browser HTTP to talk on the netork. It is highly like the network environment of your library filters network connexions by protocols for security reasons.

How to rewrite the username in addition to the email adress in postfix? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Following setup: Two servers, one with the (rails) web application and the other which actually sends the emails to the internet through postfix. Which means that any emails created by the web application get sent to the email server who processes them again.
Now, this means that emails got sent out with an email adress like "user#webserver.localdomain", which promptly led to the rejection of the emails by the target mail servers, due to the obviously missing mx record.
That one I fixed, though, with smtp_generic_maps, rewriting the sender adress to a valid one.
However, the sender name displayed in the email consists of two parts - and the first part seems to be automatically set by postfix by the username of the webserver creating the email. In this case "nginx".
So, how do I rewrite the displayed user name in addition to the email adress? Can anyone point me in the right direction, please?
To my defense: I did not setup this system myself, so I'm a bit of a beginner at all things sendmail.
Easy, connect via TCP/IP to 127.0.0.1 port 25, and submit the mail using SMTP. that way you can set the from address to whatever you want. Currently you are submitting mail via the sendmail command, which is picking up the from address from user.
ps. sendmail != postfix

Resources