Learn more about these different git repos.
Other Git URLs
Pagure sends emails that contain the text "To reply, visit the link below or just reply to this email". I sent an email reply. Two hours later it hasn't shown up in the web interface. I haven't received any kind of error message either. The words "or just reply to this email" should be removed because they are untrue.
It is supposed to work, but things have been wonky with the DC move...
Metadata Update from @ngompa: - Issue tagged with: bug, email
Replying by email, let's see :)
Is the email you're sending From configured in pagure.io? Otherwise pagure will discard any email it doesn't know about (I'll need to check the code again, but it may even ask that the email address used be the configured default email address).
Pierre-YvesChibon wrote:
Is the email you're sending From configured in pagure.io?
I was sending from the same address that Pagure uses to send to me, except for casing. This time I've changed my address to all lowercase, so it should match exactly.
OK, that apparently worked.
Although the local part of an email address is specified as case-sensitive, meaning that programs are not supposed to convert it between upper and lower case, I think you should use case-insensitive comparison for this purpose.
Otherwise pagure will discard any email it doesn't know about.
Rejected emails should be bounced, not discarded. Bouncing should be done in the SMTP session instead of accepting the message for delivery. That prevents turning spam into backscatter. The error message should state that the sender address wasn't recognized, so that the sender has a chance to fix the problem.
I don't understand what you mean with "Prevents turning spam into backscatter" and the definition of backscatter I'm finding on wikipedia doesn't help me either :(
I don't understand what you mean with "Prevents turning spam into backsca= tter" and the definition of backscatter I'm finding on wikipedia doesn't help me either :(
If a mail server first accepts a message for delivery, and later decides to reject it, then the only way to notify the sender is to generate a delivery failure report and send it to the purported sender address. If the rejected message was spam, then the sender address is probably fake, and the delivery failure report ends up in some innocent person's inbox. That is called backscatter.
To prevent backscatter, the decision to reject the message should be made while the SMTP client is still connected. The server should send an error code to the client instead of accepting the message. If the client is a spambot, then the spamming attempt fails and nobody is bothered. If the client is somebody's outgoing mail server, then that server is supposed to send a delivery failure report to the sender.
This can be done with a milter, which integrates with an MTA (Postfix or Sendmail), inspects selected data while the SMTP session is underway, and instructs the MTA to accept or reject the message. The milter also tells the MTA what status code and error message to send to the client. I recommend 550 5.7.1 "The sender address isn't recognized.".
Metadata Update from @pingou: - Issue assigned to pingou
Commit 82846cc fixes this issue
Login to comment on this ticket.